xref: /aosp_15_r20/system/chre/platform/shared/idl/host_messages.fbs (revision 84e339476a462649f82315436d70fd732297a399)
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
587table VendorHubInfo {
588  /// The name of the hub. Nominally a UTF-8 string, but note that we're not
589  /// using the built-in "string" data type from FlatBuffers here, because the
590  /// generated C++ uses std::string which is not well-supported in CHRE.
591  name:[byte];
592
593  /// Hub version
594  version:uint;
595
596  /// Additional vendor-defined data
597  extended_info:[ubyte];
598}
599
600union MessageHubDetails {
601  HubInfoResponse,
602  VendorHubInfo,
603}
604
605table MessageHub {
606  /// The hub id. -1 is reserved and 0 is invalid. 0x416e64726f696400 represents
607  /// the ContextHub service.
608  id:long;
609
610  /// Details of the message hub.
611  details:MessageHubDetails;
612}
613
614table RegisterMessageHub {
615  hub:MessageHub;
616}
617
618table UnregisterMessageHub {
619  id:long;
620}
621
622table EndpointId {
623  /// Id of the hub hosting the endpoint
624  hubId:long;
625
626  /// The id of the endpoint scoped to the hub
627  id:long;
628}
629
630/// An enum describing the type of an endpoint.
631enum EndpointType : ubyte {
632  INVALID = 0,
633  /// The endpoint is part of the Android Framework
634  FRAMEWORK = 1,
635  /// The endpoint is an Android app
636  APP,
637  /// The endpoint is a native Android program
638  NATIVE,
639  /// The endpoint is a nanoapp
640  NANOAPP,
641  /// A generic, non-nanoapp endpoint
642  GENERIC,
643}
644
645enum RpcFormat : ubyte {
646  /// Fully custom format
647  CUSTOM = 0,
648  /// Stable AIDL defined interface using Binder marshalling
649  AIDL,
650  /// Pigweed RPC defined interface using Protobuf marshalling
651  PW_RPC,
652}
653
654table Service {
655  format:RpcFormat;
656
657  /// Service descriptor. Nominally a UTF-8 string, but note that we're not
658  /// using the built-in "string" data type from FlatBuffers here, because the
659  /// generated C++ uses std::string which is not well-supported in CHRE.
660  descriptor:[byte];
661
662  /// Breaking changes should bump the major version.
663  major_version:uint;
664  /// Monotonically increasing minor version.
665  minor_version:uint;
666}
667
668table EndpointInfo {
669  id:EndpointId;
670  type:EndpointType;
671
672  /// Endpoing name. Nominally a UTF-8 string, but note that we're not using
673  /// the built-in "string" data type from FlatBuffers here, because the
674  /// generated C++ uses std::string which is not well-supported in CHRE.
675  name:[byte];
676  version:uint;
677
678  /// Values from CHRE_MESSAGE_PERMISSION_*
679  required_permissions:uint;
680  services:[Service];
681}
682
683table RegisterEndpoint {
684  endpoint:EndpointInfo;
685}
686
687table UnregisterEndpoint {
688  endpoint:EndpointId;
689}
690
691/// HAL->CHRE, indicates the HAL is coming up
692table GetMessageHubsAndEndpointsRequest {}
693table GetMessageHubsAndEndpointsResponse {
694  hubs:[MessageHub];
695  endpoints:[EndpointInfo];
696}
697
698table OpenEndpointSessionRequest {
699  id:ushort;
700  fromEndpoint:EndpointId;
701  toEndpoint:EndpointId;
702
703  /// If present, describes the service definition used over the session
704  serviceDescriptor:[byte];
705}
706
707table EndpointSessionOpened {
708  id:ushort;
709}
710
711/// "Reason"s for stopping an endpoint or session over an endpoint.
712enum Reason : ubyte {
713  /// Unspecified reason.
714  UNSPECIFIED = 0,
715  /// Out of memory. There's not enough memory to perform this operation.
716  OUT_OF_MEMORY,
717  /// Timeout. This operation timed out.
718  TIMEOUT,
719  /// Endpoint rejected this openEndpointSession request.
720  OPEN_ENDPOINT_SESSION_REQUEST_REJECTED,
721  /// Endpoint requested closeEndpointSession.
722  CLOSE_ENDPOINT_SESSION_REQUESTED,
723  /// Invalid endpoint.
724  ENDPOINT_INVALID,
725  /// Endpoint is now stopped.
726  ENDPOINT_GONE,
727  /// Endpoint crashed.
728  ENDPOINT_CRASHED,
729  /// Hub was reset or is resetting.
730  HUB_RESET,
731}
732
733table EndpointSessionClosed {
734  id:ushort;
735  reason:Reason;
736}
737
738table EndpointSessionMessage {
739  /// Id of session this message is being sent within
740  session_id:ushort;
741
742  /// Type of the message, specific to the Session protocol
743  type:uint;
744
745  /// Values from CHRE_MESSAGE_PERMISSION_*. Permissions required to read the
746  /// message.
747  permissions:uint;
748  data:[ubyte];
749
750  /// Bitmask of additional flags applied to the message:
751  /// - 0x1: Message delivery status required within 1s
752  flags:uint;
753  sequence_number:uint;
754}
755
756table EndpointSessionMessageDeliveryStatus {
757  /// Id of session the message was sent within
758  session_id:ushort;
759  status:MessageDeliveryStatus;
760}
761
762/// A union that joins together all possible messages. Note that in FlatBuffers,
763/// unions have an implicit type
764union ChreMessage {
765  NanoappMessage,
766
767  HubInfoRequest,
768  HubInfoResponse,
769
770  NanoappListRequest,
771  NanoappListResponse,
772
773  LoadNanoappRequest,
774  LoadNanoappResponse,
775
776  UnloadNanoappRequest,
777  UnloadNanoappResponse,
778
779  LogMessage,
780
781  TimeSyncMessage,
782
783  DebugDumpRequest,
784  DebugDumpData,
785  DebugDumpResponse,
786
787  TimeSyncRequest,
788
789  LowPowerMicAccessRequest,
790  LowPowerMicAccessRelease,
791
792  SettingChangeMessage,
793
794  LogMessageV2,
795
796  SelfTestRequest,
797  SelfTestResponse,
798
799  HostEndpointConnected,
800  HostEndpointDisconnected,
801
802  MetricLog,
803  BatchedMetricLog,
804
805  NanConfigurationRequest,
806  NanConfigurationUpdate,
807
808  DebugConfiguration,
809
810  PulseRequest,
811  PulseResponse,
812
813  NanoappTokenDatabaseInfo,
814
815  MessageDeliveryStatus,
816
817  BtSocketOpen,
818  BtSocketOpenResponse,
819  BtSocketClose,
820  BtSocketCloseResponse,
821
822  GetMessageHubsAndEndpointsRequest,
823  GetMessageHubsAndEndpointsResponse,
824
825  RegisterMessageHub,
826  UnregisterMessageHub,
827
828  RegisterEndpoint,
829  UnregisterEndpoint,
830
831  OpenEndpointSessionRequest,
832  EndpointSessionOpened,
833  EndpointSessionClosed,
834
835  EndpointSessionMessage,
836  EndpointSessionMessageDeliveryStatus,
837}
838
839struct HostAddress {
840  client_id:ushort;
841}
842
843/// The top-level container that encapsulates all possible messages. Note that
844/// per FlatBuffers requirements, we can't use a union as the top-level
845/// structure (root type), so we must wrap it in a table.
846table MessageContainer {
847  message:ChreMessage (required);
848
849  /// The originating or destination client ID on the host side, used to direct
850  /// responses only to the client that sent the request. Although initially
851  /// populated by the requesting client, this is enforced to be the correct
852  /// value by the entity guarding access to CHRE.
853  /// This is wrapped in a struct to ensure that it is always included when
854  /// encoding the message, so it can be mutated by the host daemon.
855  host_addr:HostAddress (required);
856}
857
858root_type MessageContainer;
859