v2: Fixed Szymon's comments (response: app_id will be returned
in response to HAL_OP_HEALTH_REG_APP ipc command).
v1: Fixed Szymon's comments(copy terminating character null
also from HAL data(names, descriptions).
RFC: Due to limited IPC_MTU and variable length of
fields from 'bthl_reg_param_t *', it is difficult to put them
in single command and send though IPC. So we split this command
to multiple calls. First command will be called with opcode of
HAL_OP_HEALTH_REG_APP with 'struct hal_cmd_health_reg_app' data.
Later command will be called with opcode of
HAL_OP_HEALTH_MDEP with 'struct hal_cmd_health_mdep' data for
number_of_mdeps times. Daemon (android/health) side it will
process after it received all data and response will be sent
along with last call of HAL_OP_HEALTH_MDEP.
This avoids increasing value of IPC_MTU and mainly because of
optional parameters in 'bthl_reg_param_t'. Incase of unfilled
optional parameters, fixed size arrays in hal commands will be
empty.
Ravi kumar Veeramally (3):
android/hal-ipc-api: Add extra command to Health HAL api document
android/hal-msg: Add extra struct for mdep data
android/hal-health: Add HDP .register_application method
android/hal-health.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++-
android/hal-ipc-api.txt | 35 +++++++++++++--------
android/hal-msg.h | 37 +++++++++++-----------
3 files changed, 122 insertions(+), 33 deletions(-)
--
1.8.3.2
Hi Ravi,
On Monday 31 of March 2014 16:13:32 Ravi kumar Veeramally wrote:
> v2: Fixed Szymon's comments (response: app_id will be returned
> in response to HAL_OP_HEALTH_REG_APP ipc command).
> v1: Fixed Szymon's comments(copy terminating character null
> also from HAL data(names, descriptions).
>
> RFC: Due to limited IPC_MTU and variable length of
> fields from 'bthl_reg_param_t *', it is difficult to put them
> in single command and send though IPC. So we split this command
> to multiple calls. First command will be called with opcode of
> HAL_OP_HEALTH_REG_APP with 'struct hal_cmd_health_reg_app' data.
> Later command will be called with opcode of
> HAL_OP_HEALTH_MDEP with 'struct hal_cmd_health_mdep' data for
> number_of_mdeps times. Daemon (android/health) side it will
> process after it received all data and response will be sent
> along with last call of HAL_OP_HEALTH_MDEP.
>
> This avoids increasing value of IPC_MTU and mainly because of
> optional parameters in 'bthl_reg_param_t'. Incase of unfilled
> optional parameters, fixed size arrays in hal commands will be
> empty.
>
> Ravi kumar Veeramally (3):
> android/hal-ipc-api: Add extra command to Health HAL api document
> android/hal-msg: Add extra struct for mdep data
> android/hal-health: Add HDP .register_application method
>
> android/hal-health.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++-
> android/hal-ipc-api.txt | 35 +++++++++++++--------
> android/hal-msg.h | 37 +++++++++++-----------
> 3 files changed, 122 insertions(+), 33 deletions(-)
>
All three patches are now upstream, thanks.
--
Best regards,
Szymon Janc
Implementation of register_application is different compared
to other apis. Due to limited IPC_MTU and variable length of
fields from 'bthl_reg_param_t *', it is difficult to put them
in single command and send though IPC. So we split this command
multiple calls. First command will be called with opcode of
HAL_OP_HEALTH_REG_APP with 'struct hal_cmd_health_reg_app' data.
Later command will be called with opcode of
HAL_OP_HEALTH_MDEP with 'struct hal_cmd_health_mdep' data for
number_of_mdeps times. App id will be sent in response to
HAL_OP_HEALTH_REG_APP command.
This avoids increasing value of IPC_MTU and mainly because of
optional parameters in 'bthl_reg_param_t'. Incase of unfilled
optional parameters, fixed size arrays in hal commands will be
empty.
---
android/hal-health.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/android/hal-health.c b/android/hal-health.c
index e6fe65a..8d12107 100644
--- a/android/hal-health.c
+++ b/android/hal-health.c
@@ -38,6 +38,87 @@ static bool interface_ready(void)
static const struct hal_ipc_handler ev_handlers[] = {
};
+static bt_status_t register_application(bthl_reg_param_t *reg, int *app_id)
+{
+ uint8_t buf[IPC_MTU];
+ struct hal_cmd_health_reg_app *cmd = (void *) buf;
+ struct hal_cmd_health_mdep *mdep = (void *) buf;
+ struct hal_rsp_health_reg_app rsp;
+ size_t rsp_len = sizeof(rsp);
+ bt_status_t status;
+ uint16_t off, len;
+ int i;
+
+ DBG("");
+
+ if (!interface_ready())
+ return BT_STATUS_NOT_READY;
+
+ if (!reg || !app_id || !reg->application_name)
+ return BT_STATUS_PARM_INVALID;
+
+ memset(buf, 0, IPC_MTU);
+
+ cmd->num_of_mdep = reg->number_of_mdeps;
+
+ off = 0;
+ cmd->app_name_off = off;
+ len = strlen(reg->application_name) + 1;
+ memcpy(cmd->data, reg->application_name, len);
+ off += len;
+
+ if (reg->provider_name) {
+ len = strlen(reg->provider_name) + 1;
+ cmd->provider_name_off = off;
+ memcpy(cmd->data + off, reg->provider_name, len);
+ off += len;
+ }
+
+ if (reg->srv_name) {
+ len = strlen(reg->srv_name) + 1;
+ cmd->service_name_off = off;
+ memcpy(cmd->data + off, reg->srv_name, len);
+ off += len;
+ }
+
+ if (reg->srv_desp) {
+ len = strlen(reg->srv_desp) + 1;
+ cmd->service_descr_off = off;
+ memcpy(cmd->data + off, reg->srv_desp, len);
+ off += len;
+ }
+
+ cmd->len = off;
+ status = hal_ipc_cmd(HAL_SERVICE_ID_HEALTH, HAL_OP_HEALTH_REG_APP,
+ sizeof(*cmd) + cmd->len, &cmd,
+ &rsp_len, &rsp, NULL);
+
+ if (status != HAL_STATUS_SUCCESS)
+ return status;
+
+ for (i = 0; i < reg->number_of_mdeps; i++) {
+ memset(buf, 0, IPC_MTU);
+ mdep->role = reg->mdep_cfg[i].mdep_role;
+ mdep->data_type = reg->mdep_cfg[i].data_type;
+ mdep->channel_type = reg->mdep_cfg[i].channel_type;
+ mdep->descr_len = strlen(reg->mdep_cfg[i].mdep_description) + 1;
+ memcpy(mdep->descr, reg->mdep_cfg[i].mdep_description,
+ mdep->descr_len);
+
+ status = hal_ipc_cmd(HAL_SERVICE_ID_HEALTH, HAL_OP_HEALTH_MDEP,
+ sizeof(*mdep) + mdep->descr_len,
+ buf, 0, NULL, NULL);
+
+ if (status != HAL_STATUS_SUCCESS)
+ return status;
+
+ }
+
+ *app_id = rsp.app_id;
+
+ return status;
+}
+
static bt_status_t unregister_application(int app_id)
{
struct hal_cmd_health_unreg_app cmd;
@@ -149,7 +230,7 @@ static void cleanup(void)
static bthl_interface_t health_if = {
.size = sizeof(health_if),
.init = init,
- .register_application = NULL,
+ .register_application = register_application,
.unregister_application = unregister_application,
.connect_channel = connect_channel,
.destroy_channel = destroy_channel,
--
1.8.3.2
Defined extra structure for MDEP data which is required for Register
Application. Also updated Opcodes for rest.
---
android/hal-msg.h | 37 ++++++++++++++++++-------------------
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/android/hal-msg.h b/android/hal-msg.h
index b7fa8fc..44a72b0 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -383,37 +383,36 @@ struct hal_cmd_pan_disconnect {
uint8_t bdaddr[6];
} __attribute__((packed));
-struct hal_string {
- uint8_t len;
- uint8_t data[0];
-};
-
#define HAL_OP_HEALTH_REG_APP 0x01
struct hal_cmd_health_reg_app {
- struct hal_string app_name;
- struct hal_string provider_name;
- struct hal_string service_name;
- struct hal_string service_descr;
- uint8_t num_of_mdep;
+ uint8_t num_of_mdep;
+ uint16_t app_name_off;
+ uint16_t provider_name_off;
+ uint16_t service_name_off;
+ uint16_t service_descr_off;
+ uint16_t len;
+ uint8_t data[0];
+} __attribute__((packed));
- struct {
- uint8_t role;
- uint8_t data_type;
- uint8_t channel_type;
- struct hal_string descr;
- } mdep_cfg[0];
+#define HAL_OP_HEALTH_MDEP 0x02
+struct hal_cmd_health_mdep {
+ uint8_t role;
+ uint8_t data_type;
+ uint8_t channel_type;
+ uint16_t descr_len;
+ uint8_t descr[0];
} __attribute__((packed));
struct hal_rsp_health_reg_app {
uint16_t app_id;
} __attribute__((packed));
-#define HAL_OP_HEALTH_UNREG_APP 0x02
+#define HAL_OP_HEALTH_UNREG_APP 0x03
struct hal_cmd_health_unreg_app {
uint16_t app_id;
} __attribute__((packed));
-#define HAL_OP_HEALTH_CONNECT_CHANNEL 0x03
+#define HAL_OP_HEALTH_CONNECT_CHANNEL 0x04
struct hal_cmd_health_connect_channel {
uint16_t app_id;
uint8_t bdaddr[6];
@@ -424,7 +423,7 @@ struct hal_rsp_health_connect_channel {
uint16_t channel_id;
} __attribute__((packed));
-#define HAL_OP_HEALTH_DESTROY_CHANNEL 0x04
+#define HAL_OP_HEALTH_DESTROY_CHANNEL 0x05
struct hal_cmd_health_destroy_channel {
uint16_t channel_id;
} __attribute__((packed));
--
1.8.3.2
Defined extra command for MDEP data which is required for Register
Application command. Also updated Opcode for rest of the commands.
---
android/hal-ipc-api.txt | 35 ++++++++++++++++++++++-------------
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 5613e85..3cf8c16 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1125,28 +1125,37 @@ Commands and responses:
Opcode 0x01 - Register Application command/response
- Command parameters: Application name (string)
- Provider name (string)
- Service name (string)
- Service description (string)
- Number of MDEP (1 octet)
- MDEP Role # (1 octet)
- Data type # (1 octet)
- Channel type # (1 octet)
- MDEP description # (string)
- ...
+ Command parameters: Number of MDEP (1 octet)
+ Application name offset (2 octets)
+ Provider name offset (2 octets)
+ Service name offset (2 octets)
+ Service description offset (2 octets)
+ Data length (2 octets)
+ Data (data length)
Response parameters: Application ID (2 octets)
+ Strings are null terminated.
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Register Application MDEP data command/response
+
+ Command parameters: MDEP Role (1 octet)
+ Data type (1 octet)
+ Channel type (1 octet)
+ MDEP description length (2 octets)
+ MDEP description (MDEP desciption length)
+ Response parameters: <none>
+
In case of an error, the error response will be returned.
- Opcode 0x02 - Unregister Application command/response
+ Opcode 0x03 - Unregister Application command/response
Command parameters: Application ID (2 octets)
Response parameters: <none>
In case of an error, the error response will be returned.
- Opcode 0x03 - Connect Channel command/response
+ Opcode 0x04 - Connect Channel command/response
Command parameters: Application ID (2 octets)
Remote address (6 octets)
@@ -1155,7 +1164,7 @@ Commands and responses:
In case of an error, the error response will be returned.
- Opcode 0x04 - Destroy Channel command/response
+ Opcode 0x05 - Destroy Channel command/response
Command parameters: Channel ID (2 octets)
Response parameters: <none>
--
1.8.3.2