Distributed Android Apps. Web-Enabled HTTP-addressible Android Software Components

1)What if android application development entails, not the integration of various libraries and programming software components into a complete single executable (at the design and implementation stages as with traditional app development) where the internal structure of which stays static throughout lifetime, but instead the composition of various services at runtime to provide a specific application experience to the user? i.e., application experiences are constructed through combining and interconnecting one or more independent services (app sub-components that are independently managed). This transfers the concerns of design and (some aspects of) realization of an application experience from design-time to run-time. And therefore, the service developers only cencenered of the development of much smaller (micro) services, while the application developers concerned of the management of various (micro) servcies for constructing application experiences at runtime.

2) What if any Android software component (Activities, Services) and any resource could be HTTP addressable, and the execution and storage of those components could be distributed among multiple Android devices at runtime? It will allow for (mobile versions of) the wide range of services that are usually accessed through the internet to be integrated into locally executed apps (for improved latency) and for dynamically switch between those versions of the component executing at various tiers of the network (Cloud, Edge, IoT/End-User devices [fog]), for adapting to changing contextual changes (e.g., energy utilisation, user location). Or what if you could distribute various Android components just among your other Android devices (smart home, TV) towards improving the overall user experience? e.g., offloading a game processing component to a more powerful Android gaming console may improve the performance, while offloading the display capability to a larger UHDTV seamlessly may improve the user experience.

Currently, mobile applications are monolithically structured and packed into executables. Therefore, changing the execution and configurations of the internal components at runtime becomes a complex and a difficult task. But adapting applications dynamically at runtime to improve user experiences and to optimise resource consumption requires them to be much more flexible. Providing mechanisms for dynamically restructuring application code as well as improving the flexiblity and dynamicity of local and distributed execution of application components could be done through adopting the protocols of the World Wide Web and the principles of Cloud Computing. This changes the definition of a mobile application from a statically packaged collection of libraries and software components, to a collection of microservices that are dynamically interconnected to satisfy a set of application requirements. Such applications are transient in nature, loosening the constraints/coupling and the consideration of locality of said microservices from application development.

For android devices, that’d mean creating a web of services within the Android device. Any application will be able to make their services available to intra-app components as well as other application within android, by providing means to expose their names/addresses (dynamically at runtime) at intra-app and intra-app scales and means for those components to communicate (inter-component connectivity). This requires mechanisms to discover and resolve service names at runtime and to transport messages between services, within the mobile device. A service framework across apps and resources, will allow service requests to be routed among android application components. Moreover, it will allow one application components to share data/information/service without having to go through the persistent storage. It will allow one application to provide access to its local memory space to another application

This brings us to the issue of transmission of HTTP requests. On the internet, HTTP relies primarily on TCP/IP or TLS-encrypted TCP for transmitting HTTP messages. Using HTTP for service communication will allow the service framework runtime to dynamically offload those requests to be served by services in other devices or the nodes in the network/internet. Creating a web of microservices in mobile devices, requires you to replace TCP/IP within the mobile device. Just as network sockets provides interconnectivity between networked nodes, Operating systems provide inter-process communication mechanisms (Unix domain sockets being one IPC type in Unix-like operating systems) for communicating among processes within an operating system.

Android provides a number of IPC mechanisms, each providing different benefits. However, using Android IPC for continuous HTTP communication, especially with large payloads, has shown to be very inefficient. You can find more on it here. Therefore, it is crucial for providing android applications and services with more efficient IPC mechanisms, either by Android or by service frameworks, if such service-based application developing/structuring methods to be adopted widely.

The paper REACT: Distributed Mobile Microservice Execution Enabled by Efficient Inter-Process Communication, expands on this discussion, provides a solution to intra-app android IPC issue, and proposes an API for creating microservices within mobile devices. It introduces a runtime framework (as seen on Figure 1) for managing locally executing application functions (AF) which are turned into microservices, and for offloading them for improving user experience and optimising local resources on the mobile device. The API also allows for Service Function Chaining (SFC), where chains of interconnected services are created for providing application experiences.

Although the figure depicts the REACT runtime being within an android application, its services (e.g., service name resolution, function discovery) may be implemented as an android service for inter-app service communication. It addresses the limitations imposed by Android IPC, by introducing an app-layer heap mechanism, which allows application components to communicate large payloads (as seen in Figure 2). It also enables dynamic and seamless offloading of those components to other devices and nodes in the network.

The proposed framework and the techniques in the paper only scratch the surface of the issues discussed at the beginning of this article. It's still limited in terms of programming models in can support, inter-app IPC, IPC and HTTP request communication efficiency, options for methods for creating microservices within the mobile device… and the list goes on!. However, it addresses a subset of issues and, demonstrates the applicability and feasibility of following such an application structuring and development model.