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