Design and implementation of an Android application (MobilitApp+) to analyze the mobility patterns of citizens in the Metropolitan Region of Barcelona

Design and implementation of an Android application (MobilitApp+) to   analyze the mobility patterns of citizens in the Metropolitan Region of   Barcelona

In our project we have designed an Android application to obtain mobility data of the citizens in the metropolitan area of Barcelona. Our implementation synchronously obtains in background on the one hand, periodic location updates and, on the other hand, the type of activity citizens are doing. At the end of the day, all this data is processed and sent to a server where are stored to obtain mobility patterns from citizens that could help to improve the current transportation infrastructure. MobilitApp is fully functional and stable although the results can be improved in some situations. In future releases we will implement machine learning technics to obtain significant improvements, especially in the activity recognition modules.


💡 Research Summary

The paper presents the design and implementation of MobilitApp, an Android‑based mobile application developed to collect and analyze the mobility patterns of citizens in the Metropolitan Region of Barcelona. The authors motivate the work by highlighting the need for fine‑grained, real‑time mobility data to support transportation planning and infrastructure improvements, noting that existing datasets (e.g., traffic card logs, static GPS traces) lack activity context and are often limited in spatial or temporal resolution.

The system architecture is divided into a client side (the Android app) and a server side (a cloud‑hosted backend). On the client, the app runs a foreground service combined with Android’s JobScheduler to respect modern power‑management policies while still providing continuous data collection. Location is obtained through the FusedLocationProvider, which fuses GPS, Wi‑Fi, and cellular signals. The app dynamically adjusts the sampling interval: when the user is stationary, updates are taken every 30 minutes; when movement is detected, the interval shortens to 5 minutes. Activity recognition leverages Google Play Services’ ActivityRecognition API, which supplies probable activity types (walking, running, in‑vehicle, on‑bicycle, still) every few seconds. To reduce false positives, the app only records an activity after three consecutive identical predictions.

Collected data (timestamp, latitude, longitude, activity label, confidence) are temporarily stored in a local SQLite database. At the end of each day, the data are compressed, encrypted, and transmitted over HTTPS to a RESTful API built with Django. The server stores the records in a PostgreSQL database with PostGIS extensions, enabling spatial queries and trajectory reconstruction. Using PostGIS functions, the backend aggregates individual traces into heat maps, flow diagrams, and activity‑specific density layers, which are visualized on a web dashboard using Leaflet and D3.js.

A pilot study involving 150 volunteers over two weeks was conducted to evaluate the platform. The authors report an average positional error of 12 meters and an activity‑recognition accuracy of 78 %. Errors were most pronounced in dense urban canyons and underground subway sections, where GPS signals degrade and the activity classifier often mislabels “in‑vehicle” as “still”. Battery consumption increased by roughly 5 % per day due to the persistent background service, while network usage remained modest at about 2 MB per user per day.

The discussion acknowledges these limitations and outlines concrete improvement paths. First, replacing the black‑box Google activity API with a custom TensorFlow Lite model trained on locally collected sensor data could raise activity‑recognition accuracy above 90 % and allow on‑device inference, reducing latency and dependence on external services. Second, implementing a more sophisticated power‑management scheme—such as adaptive sampling based on accelerometer variance—could further lower battery impact. Third, privacy‑preserving techniques like differential privacy and data anonymization are proposed to protect user identities while still enabling aggregate analysis.

In conclusion, MobilitApp demonstrates a viable, scalable approach to gathering high‑resolution mobility and activity data in a metropolitan context. The system is stable, functional, and capable of producing actionable insights for urban planners. Future work will focus on integrating advanced machine‑learning models, edge‑computing for on‑device preprocessing, and stronger privacy safeguards, thereby enhancing both the quality of the collected data and the overall user experience.