# Safe and Policy Oriented Secure Android-Based Industrial Embedded Control System
## 2 Android-based Industrial Controller for Safety-Critical Applications
### Integration of Android Applications and Real-Time Xenomai Tasks  
In the dual-kernel configuration presented in the previous section, the entire system consists of two parts. The non-real-time part includes Android running on top of the Linux kernel and the real-time part, which is Xenomai. Accordingly, user space tasks can be divided into non-real-time Android applications, standard Linux tasks, and the Xenomai RT tasks. Each part has its own private memory address space and software abstractions, due to the hardware abstraction of the ADEOS-IPIPE. This means that direct communication between Android applications and Xenomai real-time Xenomai tasks is restricted. Moreover, using non real-time libraries or system calls within RT tasks results to an event called mode switching. This results in a chaotic scenario where RT tasks lose their hard real-time capabilities, causing the entire system to become unstable and non-deterministic. In our previous work, we implemented a cross-domain datagram protocol (XDDP) to address the communication issue between standard Linux and Xenomai [23]. Although XDDP provides communication between non real-time and real-time tasks, the same approach cannot be applied to Android due to its architecture, which does not allow direct device access to regular applications. However, Android provides an interface definition language that allows users to define a programming interface between applications to communicate through inter-process communication mechanisms. In this work, we have selected the anonymous shared memory mechanism (ashmem) as the communication channel between Android applications and standard Linux tasks. Figure 2 shows the thread model of integrating Android applications with Xenomai RT tasks, leveraging both XDDP and ashmem mechanisms. All the operations and components of the non-real-time part are represented by the white blocks, while the shaded blocks represent the real-time ones. For the purpose of simplification, we assume a single connection between an Android application (App Looper) and a standard Linux task (Message Handler) via ashmem. The App Looper acts as a server, which creates a file descriptor for the shared memory and includes the message-passing  
Figure 2: Thread model of integrating Android applications with real-time Xenomai tasks. activity. Implementing the interface requires the developer to create a user-defined Android library to map the ashmem and pass file objects between processes through the Java native interface. We have created an Android library consisting of two message-passing functions to access the shared memory called jGetMsg() and jSetMsg(), which are responsible for reading and writing messages, respectively. The processing logic for these message passing functions is highly dependent on the application, which is specifically defined by the developer. In our case, we have developed the library to pass the string datatype of messages. For the Linux side, the Message Handler is a non-real-time task that accesses the shared memory through the device file, /dev/ashmem, using the standard Linux open() function. Accordingly, we have developed getMsg() and setMsg() functions as the respective counterparts of jGetMsg() and jSetMsg() in the Linux domain. To date, communication between the App Looper and the Message Handler is successfully realized. Given that the Message Handler task should act as a bridge between Android applications and Xenomai real-time tasks, we employ the XDDP mechanism [23]. XDDP serves as the communication interface between Linux and Xenomai tasks. Herein, the Message Handler is linked to an XDDP port by accessing the real-time inter-process communication (RTIPC) driver through the /dev/rtp* character device (* represents the minor number of the device file). XDDP ports are identified by this minor number and, by default, there are 32 useable XDDP ports. After opening the respective device file, the standard Linux read() and write() functions are used to access the stored message in the XDDP port.