Performance evaluation of android IPC for continuous sensing applications

Abstract

Sensor-rich smartphones are enabling a new class of applications and systems with significant potential to improve users’ daily lives. These applications, referred to as continuous sensing applications, continuously collect sensor data from on-board and external sensors and apply machine learning techniques to extract meaningful information about users’ behaviour and environment[1, 2, 6]. To collect the required sensor data, a continuous sensing application needs to communicate with different software entities on the phone including a) system services that interface with on-board sensors; b) drivers of off-board sensors, which are often proprietary applications developed by sensor manufacturers; and c) other sensing applications to obtain relevant user and context information. For enhanced security and privacy on modern smartphone platforms, each application runs within its own process. Therefore, Inter-Process Communication (IPC) mechanisms are crucial to continuous sensing applications. Current sensing sampling rates range from 32 bytes/sec for accelerometer and location data [5]; 63 bytes/sec for user and system context information, such as CPU, memory, and phone call, SMS records[3]; 88 KB/sec for acoustic data; and 232 KB/sec for image documentation [4]. Different sensing applications require IPC that can support a transfer of few bytes to hundreds of kilobytes, and frequencies of 0.1Hz to 1Hz. Ideal inter-process communication for continuous sensing applications must therefore meet the following performance requirements: 1) Low latency since the IPC transactions are on the critical path of the data collecting process; 2) Resource efficiency to minimize interference with device interactivity, performance, and availability; 3) Variable Bandwidth to accommodate a wide range of application demands from a few bytes to several hundreds of kilobytes per second as described earlier. We study the performance of three Android IPC mechanisms: 1) Binder, a remote-procedure-call (RPC) mechanism that enables a process to remotely invoke functions running on another process; Binder adopts a direct-message-copy scheme to transfer the IPC payload with only single data copy. 2) Intent, a flexible message passing system, implemented using two Binder RPC calls, allowing applications to send messages to each other; and 3) Content Provider, a data storehouse mechanism that implements various SQL-like IPC interfaces, in which the query operation uniquely incorporates a shared memory region to facilitate the transmission of possibly large query results.