The proposed solution was implemented as a middleware for the Android platform, which provides fine-grained control for sensing operations and a flexible development environment. Nevertheless, the underlying principles of our middleware still are valid for other mobile platforms that also follow an asynchronous access to sensors. Specific actions were taken for ensuring the actual execution of the middleware in the smartphone, as described in next paragraphs.
4.2. Event-Driven Middleware for On-Device Stay Points Detection
Figure 3 illustrates the architecture of the proposed middleware. We highlight the different Android API components used in our design, and particularly the deployment on the Android software stack. The modules of the architecture are activated upon the reception of message notifications from components of upper/lower layers. The event-driven design allow us to deploy a loose coupling architecture, implying that each module is agnostic about the processing details that originated the incoming message notification and instead, focus on processing the input event and producing the corresponding output that must also be notified as a message to other components.
Our middleware abstracts the complexity of the different layers and technical mechanisms that must be addressed for enabling continuous GPS access, like reacting to changes in power-level modes and energy management of Android OS. Its architecture provides significant enhancements of our previous work (described in [
20]), improving the way on which mobile LBSs register within the middleware, adding support for flexible definition of policies through Dependency Injection [
52], proper adaptations due to changes in Android platform, and most importantly, the possibility of performing the stay points detection entirely on the mobile device. Since the event-driven approach is based on message passing, we employed the
Observer pattern throughout our middleware to register subscribers for receiving notification about changes in the platform [
53], specifically the reception of location updates and the detection of stay points.
A detailed description of how the middleware employs such Android low-level components and the interaction between its modules is as follows. Initially, at the top of the Android software stack (i.e., the Applications layer), the
Running location-based mobile application requests the detection of stay points to the
Background service component, using an implementation of a Java interface that describes the policy to follow for subsequent GPS accesses. As shown in
Figure 3, the interface defines the method
scheduleNextReading(long lastPeriod, List<Location> previousLocations), where the
lastPeriod parameter refers to the last time interval employed for scheduling GPS readings, while
previousLocations contains a list of the last location fixes reported by the GPS receiver. The interface implementation is evaluated by the
Policy executor once a new location update is received, allowing the middleware to define the moment on which next reading must be scheduled.
By using the interface, the hosted mobile app is able to inject this functionality according to its own needs. For instance, it could study the distance and time changes of last obtained locations, generating speed-based policies (as in [
54]), or simply return a fixed value, so that a static sampling period would be employed for accessing GPS. Technically, the request for stay points notifications is performed by an
Activity of the hosted mobile app, which establishes a connection with a
Service (the
Background service component) using an
Intent when calling the
bindService() method. After such method call, the
Background service is started in foreground mode, marking it with high priority so that Android OS does not kill it under low memory scenarios.
The Background service component includes several modules built from different Android API Framework elements, in particular the alarm, power, and location system services. After the Policy executor evaluates the interface implementation, the next GPS reading is scheduled by registering alarms into the mobile OS using the AlarmManager system service of the Android software stack. Among the different task scheduling strategies provided by Android, the AlarmManager approach is the only control point for addressing the aggressive power-saving mechanisms aimed at extending battery life. In this way, the smartphone could be on its active mode, even reactivating it from sleep mode (also known as doze) if needed. The scheduling of alarms is followed by the registration of a BroadcastReceiver component that will receive event notifications of alarms going off, so that the middleware is reactivated for continuing location data collection.
Although scheduled alarms are guaranteed to be triggered, the smartphone still can return to sleep mode while collecting and processing GPS data. The Android OS’s
POWER_SERVICE system service provides a specific token denominated partial
WakeLock for explicitly controlling the power state of the mobile device. When acquired, a
WakeLock forces the CPU and low-level hardware components to be kept in active power mode. We employed a specific type of
WakeLock denominated
PartialWakeLock, as it is able to turn off the screen while kee** the CPU and sensors awake. In this way, the
WakeLock manager component ensures that the smartphone will be kept awake when accessing to GPS and processing location data [
55].
The
Background service also embeds the
Stay points detection algorithm module, which executes the event-driven
buffered and
sigma algorithm variants for on-line detection of stay points. This module is aware of the limitations of smartphone’s battery, so that after notifying the detected stay point to the subscribed mobile app, it also notifies to the
Policy executor the end of location processing for the immediate release of the active
WakeLock. The proper management of
WakeLocks is essential for the continuous operation of mobile apps, and their unexpected retention and missuses are common causes of a poor management of energy resources [
55]. Another critical aspect, described later on, is that location updates might not be obtained under specific circumstances. Here, it is important to state that the event-driven variants of Li’s algorithm employed as proof-of-concept are able to deal with intermittent acquisition of location updates. More specifically, these algorithms are able to generate a stay point even if only the initial and last location fixes at the entrance of a stay point are acquired. Nevertheless, other algorithms and further analysis processes are encouraged to handle the issue.
The GPS administrator and listener layers control the registration - unregistration with the GPS hardware. The GPS Administrator module employs the LocationManager Android API component for accessing to the native GPS location provider, using the sampling scheme instructed by the Policy executor. The GPS Listener module, upon GPS Administrator request, registers for location updates with the Android HAL (Hardware Abstraction Layer) using a LocationListener implementation. Upon location update reception, the GPS Listener unregisters from HAL so that GPS receiver could be turned off, and notifies the location update to subscribers in upper layers of the middleware. It is important to recall that the acquisition of a GPS location fix is highly dependent on the visibility of GPS satellite infrastructure, which is affected in indoors locations, and by other external factors like meteorological phenomena. As a consequence, it is possible that location updates could not be retrieved. For this issue, the GPS Administrator includes a TimerTask mechanism that provides a time interval on which the location update must be obtained. In the case a time out is reached, the GPS Listener is unregistered from the native location provider and a notification of not found location is delivered to upper layers. The subscribers of location updates, i.e. the Policy executor and the Stay points detection algorithm modules, must be aware of this issue and prepared to react accordingly.
Despite the fact Android offers a mock event-driven API for sensors access, its actual implementation instructs layers to pull data from underneath layers [
46,
56]. Unlike this, the proposed middleware is powered up by an event-driven approach, on which each of its layers pushes data to above layers by using message notifications. In addition, it includes the mechanism for trying to obtain a location update within a strict time interval, which avoids a prolonged use of GPS when the connection to satellites is unlikely to be successful. These characteristics provide an improved management of sensors, computing, and energy resources of the mobile device, which aims to fill the lack of continuous sensing support exposed by Android.
Figure 4 shows a pragmatic vision of the tasks performed by the middleware upon request of location and stay points updates. After specifying the sampling policy to use (in the step denoted as
*), the
Running location-based mobile app requests the notification of location and stay point updates to the
Background service in step 0. Then, the
Policy executor evaluates the specified policy (Step 1) for scheduling the time at which the mobile device must be woken up (Step 2) to perform location updates. After the location update (or a time out) is obtained from the event source components (
GPS Administrator and
GPS Listener), it is notified to upper layers (Step 3), including the hosted mobile App (Step 4). The location update is received by the
Background service, for launching the event processing in the
Stay points detection algorithm module (Step 5), which would notify the detection of a stay point to the hosted mobile App (Step 6). The location update is also processed by the
Policy executor, which after storing it inside the
previousLocations list, will trigger the
Evaluation of the specified policy, restarting the sampling process.
Thus, the
Policy executor block could analyze a historical window of GPS data to infer context information about user mobility and generate an adequate schedule for the next GPS access. Although in this article the analysis of the
previousLocations list is discarded and only fixed sampling periods are explored, such scheduling could be based on more complex mechanisms that employ information learned from multi-sources of context data [
2,
29]. It is important to remark that the processing of any data collected from smartphone’s sensors, especially from location providers, is affected by security and privacy concerns of users in regard to exposing personal information. Although we recognize this issue, we focus on the technical and power aspects of the challenges imposed by power efficient stay points detection in mobile platforms.