• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1// Copyright (C) 2017 The Android Open Source Project
2//
3// Licensed under the Apache License, Version 2.0 (the "License");
4// you may not use this file except in compliance with the License.
5// You may obtain a copy of the License at
6//
7//     http://www.apache.org/licenses/LICENSE-2.0
8//
9// Unless required by applicable law or agreed to in writing, software
10// distributed under the License is distributed on an "AS IS" BASIS,
11// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
12// See the License for the specific language governing permissions and
13// limitations under the License.
14
15/// CHRE flat buffers declaration.
16///
17/// New fields declaration should be added at the end.
18/// See https://flatbuffers.dev/md__schemas.html for details.
19
20namespace chre.fbs;
21
22/// Represents a message sent to/from a nanoapp from/to a client on the host
23table NanoappMessage {
24  app_id:ulong = 0;
25  message_type:uint = 0;
26
27  /// Identifies the host-side endpoint on the host that sent or should receive
28  /// this message. The default value is a special value defined in the HAL and
29  /// elsewhere that indicates that the endpoint is unspecified.
30  host_endpoint:ushort = 0xfffe;
31
32  /// Vector containing arbitrary application-specific message data
33  message:[ubyte] (required);
34
35  /// List of Android permissions that cover the contents of a message from a
36  /// nanoapp to the host.
37  /// These permissions are used to record and attribute access to
38  /// permissions-controlled resources.
39  message_permissions:uint;
40
41  /// List of Android permissions declared by the nanoapp / granted to the host.
42  /// For messages from a nanoaapp to the host, this must be a superset of
43  /// message_permissions.
44  permissions:uint;
45
46  // If true, the message has awakened the host AP (i.e. the AP has transitioned
47  // from suspend to awake as a result of this message transfer). This field is
48  // only valid for messages originating from a nanoapp.
49  woke_host:bool = false;
50
51  // Whether the message is reliable.
52  // The receiver acknowledges reliable messages by sending a status back.
53  // The status contains the message delivery status.
54  is_reliable:bool;
55
56  // The message sequence number used for reliable messages.
57  message_sequence_number:uint;
58}
59
60// Status of sending a reliable message.
61table MessageDeliveryStatus {
62  // The message sequence number.
63  message_sequence_number:uint;
64
65  // Error code.
66  error_code:byte;
67}
68
69table HubInfoRequest {}
70table HubInfoResponse {
71  /// The name of the hub. Nominally a UTF-8 string, but note that we're not
72  /// using the built-in "string" data type from FlatBuffers here, because the
73  /// generated C++ uses std::string which is not well-supported in CHRE. This
74  /// applies for vendor and toolchain as well.
75  name:[byte];
76  vendor:[byte];
77  toolchain:[byte];
78
79  /// Legacy platform version reported in the HAL; semantics not strictly
80  /// defined
81  platform_version:uint;
82
83  /// Toolchain version reported in the HAL; semantics not strictly defined
84  toolchain_version:uint;
85
86  peak_mips:float;
87  stopped_power:float;
88  sleep_power:float;
89  peak_power:float;
90
91  /// Maximum size regular message that can be sent to a nanoapp
92  max_msg_len:uint;
93
94  /// @see chreGetPlatformId()
95  platform_id:ulong;
96
97  /// @see chreGetVersion()
98  chre_platform_version:uint;
99
100  /// Whether reliable messages are supported
101  supports_reliable_messages:bool = false;
102
103  // TODO: list of connected sensors
104}
105
106table NanoappListRequest {}
107
108/// Metadata regarding a Nanoapp RPC service. See the Android API
109/// core/java/android/hardware/location/NanoAppRpcService.java for more details
110/// on how this value is used by the Android application.
111table NanoappRpcService {
112  id: ulong;
113  version: uint;
114}
115
116table NanoappListEntry {
117  app_id:ulong;
118  version:uint;
119  enabled:bool = true;
120
121  /// Whether the nanoapp is a pre-loaded "system" nanoapp, i.e. one that should
122  /// not show up in the list of nanoapps in the context hub HAL. System
123  /// nanoapps are typically used to leverage CHRE for some device functionality
124  /// and do not interact via the context hub HAL.
125  is_system:bool = false;
126
127  /// Nanoapp permissions, if supported. Nanoapp permissions are required on
128  /// CHRE API v1.5+, and are defined in chre/util/system/napp_permissions.h
129  permissions:uint;
130
131  /// The list of RPC services supported by this nanoapp.
132  rpc_services:[NanoappRpcService];
133
134  // TODO: memory usage
135}
136
137table NanoappListResponse {
138  nanoapps:[NanoappListEntry] (required);
139}
140
141/// Represents a request for loading a nanoapp.
142/// The nanaopp can either be requested to be loaded via a file or via a buffer.
143/// For loading via a file, the following steps will be taken:
144/// 1. The loader sends a LoadNanoappRequest message to CHRE. app_binary must
145///    be set for legacy purposes, but should be empty. Additionally,
146///    fragment_id and total_app_size are unused in this request. The loading
147///    that happens as part of this request is serialized, but asynchronous
148///    meaning that load requests will be processed in the order they are sent
149///    but multiple requests can be outstanding at any given time.
150/// 2. CHRE stores the filename and waits until its event loop is able to
151///    process the request.
152/// 3. Once ready, the nanoapp will be loaded from the file specified in the
153///    original request and will send a callback indicating the
154///    completion/failure of the request.
155/// For loading via a buffer, loading may optionally be fragmented into multiple
156/// sequential requests, which will follow the following steps:
157/// 1. The loader sends a LoadNanoappRequest message to CHRE. If the request
158///    is fragmented, then the fields fragment_id and total_app_size must
159///    be defined. Once the first fragment is sent to CHRE, all subsequent
160///    fragments must be delivered before a new LoadNanoappRequest can be
161///    issued. If a new request is received while a current request has
162///    outstanding fragments, the current request will be overridden with the
163///    new one.
164/// 2. CHRE preallocates the required amount of memory, and loads app_binary,
165///    appending to already loaded fragments as appropriate.
166/// 3. If the request is fragmented, then the requestor must sequentially send
167///    multiple LoadNanoappRequest with incremental nanoapp binary fragments.
168///    CHRE will respond with LoadNanoappResponse for each request. For
169///    requests starting from the second fragment, all fields except
170///    fragment_id and app_binary should be ignored by CHRE.
171///
172///    Once the LoadNanoappRepsonse for the last fragment is received
173///    by the HAL, the HAL client will receive a callback indicating the
174///    completion/failure of a load request.
175///
176/// If any request fragment is lost, then the entire load request will be
177/// considered to have failed. If the request times out (e.g. the requestor
178/// process crashes), then the load request will be cancelled at CHRE and fail.
179table LoadNanoappRequest {
180  transaction_id:uint;
181
182  app_id:ulong;
183  app_version:uint;
184  target_api_version:uint;
185
186  app_binary:[ubyte] (required);
187
188  /// Fields that are relevant for fragmented loading
189  /// The framgent count starts at 1 and should end at the total number of
190  /// fragments. For clients that do not support fragmented loading, the
191  /// default behavior should be to assume one fragment.
192  fragment_id:uint = 0;
193  total_app_size:uint;
194
195  /// Null-terminated ASCII string containing the file name that contains the
196  /// app binary to be loaded.
197  app_binary_file_name:[byte];
198
199  /// The nanoapp flag values from the nanoapp header defined in
200  /// build/build_template.mk. Refer to that file for more details.
201  app_flags:uint;
202
203  /// If true and fragmented loading is requested, the LoadNanoappResponse
204  /// for the last fragment will be sent after the fragment was confirmed
205  /// to be placed in memory and no additional response will be sent after
206  /// the nanoapp is linked and started in the framework.
207  respond_before_start:bool;
208}
209
210table LoadNanoappResponse {
211  transaction_id:uint;
212
213  /// Denotes whether a load request succeeded or failed.
214  /// If any fragment of a load request fails, the entire load request for
215  /// the same transaction will fail.
216  success:bool;
217
218  /// The fragment count of the load reponse is for.
219  fragment_id:uint = 0;
220
221  // TODO: detailed error code?
222}
223
224/// Contains information needed for the host to load the token database for the
225/// nanoapp. This message is only sent if a token database section is found in
226/// the nanoapp elf binary.
227table NanoappTokenDatabaseInfo {
228  instance_id:uint;
229
230  app_id:ulong;
231
232  /// The size offset of the token database from the start of the address of
233  /// the ELF binary in bytes.
234  database_offset_bytes:uint;
235
236  /// The size of the token database section in the ELF binary in bytes.
237  database_size_bytes:uint;
238}
239
240table UnloadNanoappRequest {
241  transaction_id:uint;
242
243  app_id:ulong;
244
245  /// Set to true to allow this request to unload nanoapps identified as "system
246  /// nanoapps", i.e. ones with is_system set to true in NanoappListResponse.
247  allow_system_nanoapp_unload:bool;
248}
249
250table UnloadNanoappResponse {
251  transaction_id:uint;
252  success:bool;
253}
254
255/// Represents log messages from CHRE.
256table LogMessage {
257  /// A buffer containing formatted log data. A flat array is used here to avoid
258  /// overhead in serializing and deserializing. The format is as follows:
259  ///
260  /// uint8_t                 - log level (1 = error, 2 = warning,
261  ///                                      3 = info, 4 = debug)
262  /// uint64_t, little-endian - timestamp in nanoseconds
263  /// char[]                  - message to log
264  /// char, \0                - null-terminator
265  ///
266  /// This pattern repeats until the end of the buffer for multiple log
267  /// messages. The last byte will always be a null-terminator. There are no
268  /// padding bytes between these fields. Treat this like a packed struct and be
269  /// cautious with unaligned access when reading/writing this buffer.
270  buffer:[byte];
271}
272
273/// Represents a message sent to CHRE to indicate AP timestamp for time sync
274table TimeSyncMessage {
275  /// Offset between AP and CHRE timestamp
276  offset:long;
277}
278
279/// A request to gather and return debugging information. Only one debug dump
280/// session can be active at a time. Upon accepting a request, zero or more
281/// DebugDumpData messages are generated, followed by a DebugDumpResponse
282/// indicating the completion of the operation.
283table DebugDumpRequest {}
284
285table DebugDumpData {
286  /// Null-terminated ASCII string containing debugging information
287  debug_str:[byte];
288}
289
290table DebugDumpResponse {
291  /// true if the request was accepted and a dump was performed, false if it was
292  /// rejected or failed to complete for some reason
293  success:bool;
294
295  /// The number of DebugDumpData messages sent in this session
296  data_count:uint;
297}
298
299/// A request from CHRE for host to initiate a time sync message
300/// (system feature, platform-specific - not all platforms necessarily use this)
301table TimeSyncRequest {}
302
303/// Request from CHRE to enable direct access to data from the low-power
304/// microphone. On some systems, coordination via the AP (e.g. with
305/// SoundTrigger HAL) is needed to ensure this capability is powered up when
306/// CHRE needs it. The host does not send a response.
307table LowPowerMicAccessRequest {}
308
309/// Notification from CHRE that it no longer needs direct access to low-power
310/// microphone data.
311table LowPowerMicAccessRelease {}
312
313/// An enum describing the setting type.
314enum Setting : byte {
315  LOCATION = 0,
316  WIFI_AVAILABLE,
317  AIRPLANE_MODE,
318  MICROPHONE,
319  BLE_AVAILABLE,
320}
321
322/// An enum describing the state of a setting.
323enum SettingState : byte {
324  DISABLED = 0,
325  ENABLED,
326}
327
328/// Notification from the host that a system setting has changed
329table SettingChangeMessage {
330  /// The setting that has changed
331  setting:Setting = LOCATION;
332
333  /// The new setting value
334  state:SettingState = DISABLED;
335}
336
337// An enum describing the level of a log.
338enum LogLevel : byte {
339  ERROR = 1,
340  WARNING = 2,
341  INFO = 3,
342  DEBUG = 4,
343  VERBOSE = 5,
344}
345
346// An enum describing the type of a log.
347enum LogType : byte {
348  STRING = 0,
349  TOKENIZED = 1,
350  BLUETOOTH = 2,
351  NANOAPP_TOKENIZED = 3,
352}
353
354// An enum indicating the direction of a BT snoop log.
355enum BtSnoopDirection : byte {
356  INCOMING_FROM_BT_CONTROLLER = 0,
357  OUTGOING_TO_ARBITER = 1,
358}
359
360/// Represents V2 log messages from CHRE.
361table LogMessageV2 {
362  /// A buffer containing formatted log data. A flat array is used here to avoid
363  /// overhead in serializing and deserializing. The format is as follows:
364  ///
365  /// uint8_t                 - Log metadata, encoded as follows:
366  ///                           [EI(Upper nibble) | Level(Lower nibble)]
367  ///                            * Log Type
368  ///                              (0 = No encoding, 1 = Tokenized log,
369  ///                               2 = BT snoop log, 3 = Nanoapp Tokenized log)
370  ///                            * LogBuffer log level (1 = error, 2 = warn,
371  ///                                                   3 = info,  4 = debug,
372  ///                                                   5 = verbose)
373  /// uint32_t, little-endian - timestamp in milliseconds
374  /// char[]                  - Log data buffer
375  ///
376  /// The log data buffer format is as follows:
377  /// * Unencoded (string) logs: The log buffer can be interpreted as a NULL
378  ///   terminated string (eg: pass to string manipulation functions, get its
379  ///   size via strlen(), etc.).
380  ///
381  /// * Tokenized logs: The first byte of the log buffer indicates the size of
382  ///   the actual encoded data to follow. For example, if a tokenized log of
383  ///   size 24 bytes were to be represented, a buffer of size 25 bytes would
384  ///   be needed to encode this as: [Size(1B) | Data(24B)]. A decoder would
385  ///   then have to decode this starting from a 1 byte offset from the
386  ///   received buffer.
387  ///
388  /// * Bt Snoop logs: The first byte of the log buffer indicates the direction
389  ///   of the bt snoop log, depending on whether it is incoming for the BT
390  ///   controller or outgoing to the arbiter. The second byte indicates the size
391  ///   of the actual BT payload followed. For example, if a bt snoop log of
392  ///   size 24 bytes were to be represented, a buffer of size 26 bytes would
393  ///   be needed to encode this as: [Direction(1B) | Size(1B) | Data(24B)].
394  ///
395  /// * Tokenized nanoapp logs: This log type is specifically for nanoapps with
396  ///   tokenized logs enabled. The first two bytes is the instance ID of the
397  ///   nanoapp which sends this tokenized log message. This instance ID will be
398  ///   used to map to the corresponding detokenizer in the log message parser.
399  ///   The rest is similar to tokenized logs with one byte of the size followed
400  ///   by the payload. For example, if a nanoapp tokenized log of size 24 bytes
401  ///   were to be sent, a buffer of size 27 bytes would be to encoded as:
402  ///   [InstanceId (2B) | Size(1B) | Data(24B)].
403  ///
404  /// This pattern repeats until the end of the buffer for multiple log
405  /// messages. The last byte will always be a null-terminator. There are no
406  /// padding bytes between these fields. Treat this like a packed struct and be
407  /// cautious with unaligned access when reading/writing this buffer.
408  /// Note that the log message might not be null-terminated if an encoding is
409  /// used.
410  buffer:[byte];
411
412  /// The number of logs dropped since CHRE started
413  num_logs_dropped:uint;
414}
415
416// A request to perform basic internal self-test in CHRE. The test to be performed
417// is platform-dependent, and can be used to check if the system is functioning
418// properly. This message should be used for debugging/testing.
419table SelfTestRequest {}
420table SelfTestResponse {
421  // True if the self-test succeeded.
422  success:bool;
423}
424
425// Message sent whenever a host endpoint has connected with the Context Hub.
426// CHRE may receive messages from this host afterwards.
427table HostEndpointConnected {
428  /// The host-side endpoint that has connected to the framework.
429  host_endpoint:ushort;
430
431  /// The type of host endpoint, which should be any of the CHRE_HOST_ENDPOINT_TYPE_*
432  /// values defined in the chre_api/chre/event.h.
433  type:ubyte;
434
435  /// The (optional) package name associated with the host endpoint.
436  package_name:[byte];
437
438  /// The (optional) attribution tag associated with this host.
439  attribution_tag:[byte];
440}
441
442// Message sent whenever a host endpoint has disconnected from the Context Hub.
443table HostEndpointDisconnected {
444  /// The host-side endpoint that has disconnected from the framework.
445  host_endpoint:ushort;
446}
447
448// Represents metric messages from CHRE
449table MetricLog {
450  // A unique identifier for the encoded metric message.
451  id:uint;
452
453  // The metric data, which is encoded using a custom-defined protocol. This
454  // same protocol must be used to decode the data at the host side for consumption.
455  encoded_metric:[byte];
456}
457
458// A container to store batched metrics messages
459table BatchedMetricLog {
460  // The batched metrics
461  metrics: [MetricLog];
462}
463
464// NAN enable request sent from CHRE to the host.
465table NanConfigurationRequest {
466  enable:bool;
467}
468
469// NAN status message sent from the host to CHRE whenever a change in the NAN
470// enabled state is detected. Note that this update can be sent to CHRE either
471// as a response to a configuration request, or from out of band if NAN was
472// disabled by an external agent.
473table NanConfigurationUpdate {
474  enabled:bool;
475}
476
477// Debug configurastion that will be send from Android AP to CHRE during boot time
478table DebugConfiguration {
479  // Should HealthMonitor::onFailure crash when receiving a false condition
480  health_monitor_failure_crash:bool;
481}
482
483// Pulse messages are used to check if CHRE is up running.
484table PulseRequest {}
485table PulseResponse {}
486
487// LE L2CAP COC channel information.
488table LeCocChannelInfo {
489  // Local Channel Identifier.
490  localCid:int;
491
492  // Remote Channel Identifier.
493  remoteCid:int;
494
495  // Protocol Service Multiplexer.
496  psm:int;
497
498  // Maximum Transmission Unit (MTU, max Rx SDU size) that the local device
499  // will accept for packets received on this channel.
500  localMtu:int;
501
502  // Maximum Transmission Unit (MTU, max Tx SDU size) that the remote device
503  // will accept for packets sent on this channel.
504  remoteMtu:int;
505
506  // Maximum PDU Payload Size (MPS) that the local device will accept for
507  // packets received on this channel.
508  localMps:int;
509
510  // Maximum PDU Payload Size (MPS) that the remote device will accept for
511  // packets sent on this channel.
512  remoteMps:int;
513
514  // The amount of PDUs that the local device will accept from this channel.
515  initialRxCredits:int;
516
517  // The amount of PDUs that the remote device will accept from this channel.
518  initialTxCredits:int;
519}
520
521// Used to specify the channel information of different protocol.
522union ChannelInfo {
523  LeCocChannelInfo
524}
525
526// Request from the host to the offload domain to open a BT socket.
527table BtSocketOpen {
528  // Unique identifier for this socket connection. This ID in the offload
529  // domain matches the ID used on the host side. It is valid only while the
530  // socket is connected.
531  socketId:long;
532
533  // The name of the socket. Nominally a UTF-8 string, but note that we're not
534  // using the built-in "string" data type from FlatBuffers here, because the
535  // generated C++ uses std::string which is not well-supported in the offload
536  // domain. This applies for vendor and toolchain as well.
537  name:[byte];
538
539  // ACL connection handle for the socket.
540  aclConnectionHandle:int;
541
542  // Channel information of the socket protocol.
543  channelInfo:ChannelInfo;
544
545  // The ID of the Hub to which the end point belongs for hardware offload
546  // data path.
547  hubId:long;
548
549  // The ID of the Hub endpoint for hardware offload data path.
550  endpointId:long;
551}
552
553// Status of BT socket open request.
554enum BtSocketOpenStatus : byte {
555  SUCCESS = 0,
556  FAILURE,
557}
558
559// Callback from the offload domain to the host to acknowledge that a BT socket
560// has been opened successfully or has failed to be opened.
561table BtSocketOpenResponse {
562  // Unique identifier for this socket connection.
563  socketId:long;
564
565  // Status indicating success or failure.
566  status:BtSocketOpenStatus;
567
568  // Reason string of the operation failure for debugging purposes.
569  reason:[byte];
570}
571
572// Request from offload domain to host to close a BT socket.
573table BtSocketClose {
574  // Unique identifier for this socket connection.
575  socketId:long;
576
577  // Reason string for closing the socket for debugging purposes
578  reason:[byte];
579}
580
581// Host callback to acknowledge that a BT socket has been closed.
582table BtSocketCloseResponse {
583  // Unique identifier for this socket connection.
584  socketId:long;
585}
586
587// Request from the host to the offload domain to get the capabilities of the
588// offload stack for BT sockets.
589table BtSocketCapabilitiesRequest {}
590
591//Capabilities for LE L2CAP COC that the offload stack supports.
592table BtSocketLeCocCapabilities {
593  // Maximum number of LE COC sockets supported. If not supported, the value
594  // must be zero.
595  numberOfSupportedSockets :int;
596
597  // Local Maximum Transmission Unit size in octets. The MTU size must be in
598  // range 23 to 65535.
599  mtu:int;
600}
601
602// Capabilities for RFCOMM that the offload stack supports.
603table BtSocketRfcommCapabilities {
604  // Maximum number of RFCOMM sockets supported. If not supported, the value
605  // must be zero.
606  numberOfSupportedSockets :int;
607
608  // Maximum frame size in octets negotiated during DLCI establishment. The
609  // frame size must be in range 23 to 32767.
610  maxFrameSize :int;
611}
612
613// Response from the offload domain to the host with the capabilities of the
614// offload stack for BT sockets.
615table BtSocketCapabilitiesResponse {
616  // Capabilities for LE COC sockets.
617  leCocCapabilities:BtSocketLeCocCapabilities;
618
619  // Capabilities for RFCOMM sockets.
620  rfcommCapabilities:BtSocketRfcommCapabilities;
621}
622
623table VendorHubInfo {
624  /// The name of the hub. Nominally a UTF-8 string, but note that we're not
625  /// using the built-in "string" data type from FlatBuffers here, because the
626  /// generated C++ uses std::string which is not well-supported in CHRE.
627  name:[byte];
628
629  /// Hub version
630  version:uint;
631
632  /// Additional vendor-defined data
633  extended_info:[ubyte];
634}
635
636union MessageHubDetails {
637  HubInfoResponse,
638  VendorHubInfo,
639}
640
641table MessageHub {
642  /// The hub id. -1 is reserved and 0 is invalid. 0x416e64726f696400 represents
643  /// the ContextHub service.
644  id:long;
645
646  /// Details of the message hub.
647  details:MessageHubDetails;
648}
649
650table RegisterMessageHub {
651  hub:MessageHub;
652}
653
654table UnregisterMessageHub {
655  id:long;
656}
657
658table EndpointId {
659  /// Id of the hub hosting the endpoint
660  hubId:long;
661
662  /// The id of the endpoint scoped to the hub
663  id:long;
664}
665
666/// An enum describing the type of an endpoint.
667enum EndpointType : ubyte {
668  INVALID = 0,
669  /// The endpoint is part of the Android Framework
670  FRAMEWORK = 1,
671  /// The endpoint is an Android app
672  APP,
673  /// The endpoint is a native Android program
674  NATIVE,
675  /// The endpoint is a nanoapp
676  NANOAPP,
677  /// A generic, non-nanoapp endpoint
678  GENERIC,
679}
680
681enum RpcFormat : ubyte {
682  /// Fully custom format
683  CUSTOM = 0,
684  /// Stable AIDL defined interface using Binder marshalling
685  AIDL,
686  /// Pigweed RPC defined interface using Protobuf marshalling
687  PW_RPC,
688}
689
690table Service {
691  format:RpcFormat;
692
693  /// Service descriptor. Nominally a UTF-8 string, but note that we're not
694  /// using the built-in "string" data type from FlatBuffers here, because the
695  /// generated C++ uses std::string which is not well-supported in CHRE.
696  descriptor:[byte];
697
698  /// Breaking changes should bump the major version.
699  major_version:uint;
700  /// Monotonically increasing minor version.
701  minor_version:uint;
702}
703
704table EndpointInfo {
705  id:EndpointId;
706  type:EndpointType;
707
708  /// Endpoing name. Nominally a UTF-8 string, but note that we're not using
709  /// the built-in "string" data type from FlatBuffers here, because the
710  /// generated C++ uses std::string which is not well-supported in CHRE.
711  name:[byte];
712  version:uint;
713
714  /// Values from CHRE_MESSAGE_PERMISSION_*
715  required_permissions:uint;
716  services:[Service];
717}
718
719table RegisterEndpoint {
720  endpoint:EndpointInfo;
721}
722
723/// MessageRouter handles service inspection separately from endpoint inspection
724/// so these messages are required to send embedded endpoint information in
725/// pieces to the host. After RegisterEndpoint, the endpoint is only ready once
726/// an EndpointReady message is sent. After EndpointReady, AddServiceToEndpoint
727/// will be rejected.
728table AddServiceToEndpoint {
729  endpoint:EndpointId;
730  service:Service;
731}
732table EndpointReady {
733  endpoint:EndpointId;
734}
735
736table UnregisterEndpoint {
737  endpoint:EndpointId;
738}
739
740/// HAL->CHRE, indicates the HAL is coming up
741table GetMessageHubsAndEndpointsRequest {}
742table GetMessageHubsAndEndpointsResponse {
743  hubs:[MessageHub];
744  endpoints:[EndpointInfo];
745}
746
747table OpenEndpointSessionRequest {
748  host_hub_id:long;
749  session_id:ushort;
750  fromEndpoint:EndpointId;
751  toEndpoint:EndpointId;
752
753  /// If present, describes the service definition used over the session
754  serviceDescriptor:[byte];
755}
756
757table EndpointSessionOpened {
758  host_hub_id:long;
759  session_id:ushort;
760}
761
762/// "Reason"s for stopping an endpoint or session over an endpoint.
763enum Reason : ubyte {
764  /// Unspecified reason.
765  UNSPECIFIED = 0,
766  /// Out of memory. There's not enough memory to perform this operation.
767  OUT_OF_MEMORY,
768  /// Timeout. This operation timed out.
769  TIMEOUT,
770  /// Endpoint rejected this openEndpointSession request.
771  OPEN_ENDPOINT_SESSION_REQUEST_REJECTED,
772  /// Endpoint requested closeEndpointSession.
773  CLOSE_ENDPOINT_SESSION_REQUESTED,
774  /// Invalid endpoint.
775  ENDPOINT_INVALID,
776  /// Endpoint is now stopped.
777  ENDPOINT_GONE,
778  /// Endpoint crashed.
779  ENDPOINT_CRASHED,
780  /// Hub was reset or is resetting.
781  HUB_RESET,
782}
783
784table EndpointSessionClosed {
785  host_hub_id:long;
786  session_id:ushort;
787  reason:Reason;
788}
789
790table EndpointSessionMessage {
791  host_hub_id:long;
792
793  /// Id of session this message is being sent within
794  session_id:ushort;
795
796  /// Type of the message, specific to the Session protocol
797  type:uint;
798
799  /// Values from CHRE_MESSAGE_PERMISSION_*. Permissions required to read the
800  /// message.
801  permissions:uint;
802  data:[ubyte];
803
804  /// Bitmask of additional flags applied to the message:
805  /// - 0x1: Message delivery status required within 1s
806  flags:uint;
807  sequence_number:uint;
808}
809
810table EndpointSessionMessageDeliveryStatus {
811  host_hub_id:long;
812
813  /// Id of session the message was sent within
814  session_id:ushort;
815  status:MessageDeliveryStatus;
816}
817
818/// A union that joins together all possible messages. Note that in FlatBuffers,
819/// unions have an implicit type
820union ChreMessage {
821  NanoappMessage,
822
823  HubInfoRequest,
824  HubInfoResponse,
825
826  NanoappListRequest,
827  NanoappListResponse,
828
829  LoadNanoappRequest,
830  LoadNanoappResponse,
831
832  UnloadNanoappRequest,
833  UnloadNanoappResponse,
834
835  LogMessage,
836
837  TimeSyncMessage,
838
839  DebugDumpRequest,
840  DebugDumpData,
841  DebugDumpResponse,
842
843  TimeSyncRequest,
844
845  LowPowerMicAccessRequest,
846  LowPowerMicAccessRelease,
847
848  SettingChangeMessage,
849
850  LogMessageV2,
851
852  SelfTestRequest,
853  SelfTestResponse,
854
855  HostEndpointConnected,
856  HostEndpointDisconnected,
857
858  MetricLog,
859  BatchedMetricLog,
860
861  NanConfigurationRequest,
862  NanConfigurationUpdate,
863
864  DebugConfiguration,
865
866  PulseRequest,
867  PulseResponse,
868
869  NanoappTokenDatabaseInfo,
870
871  MessageDeliveryStatus,
872
873  BtSocketOpen,
874  BtSocketOpenResponse,
875  BtSocketClose,
876  BtSocketCloseResponse,
877
878  GetMessageHubsAndEndpointsRequest,
879  GetMessageHubsAndEndpointsResponse,
880
881  RegisterMessageHub,
882  UnregisterMessageHub,
883
884  RegisterEndpoint,
885  UnregisterEndpoint,
886
887  OpenEndpointSessionRequest,
888  EndpointSessionOpened,
889  EndpointSessionClosed,
890
891  EndpointSessionMessage,
892  EndpointSessionMessageDeliveryStatus,
893
894  BtSocketCapabilitiesRequest,
895  BtSocketCapabilitiesResponse,
896
897  AddServiceToEndpoint,
898  EndpointReady,
899}
900
901struct HostAddress {
902  client_id:ushort;
903}
904
905/// The top-level container that encapsulates all possible messages. Note that
906/// per FlatBuffers requirements, we can't use a union as the top-level
907/// structure (root type), so we must wrap it in a table.
908table MessageContainer {
909  message:ChreMessage (required);
910
911  /// The originating or destination client ID on the host side, used to direct
912  /// responses only to the client that sent the request. Although initially
913  /// populated by the requesting client, this is enforced to be the correct
914  /// value by the entity guarding access to CHRE.
915  /// This is wrapped in a struct to ensure that it is always included when
916  /// encoding the message, so it can be mutated by the host daemon.
917  host_addr:HostAddress (required);
918}
919
920root_type MessageContainer;
921