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