Capturing context is challenging. In fact, context is produced anytime, anywhere, by everything and anyone: it is extremely volatile and subjective. Instead of trying to define what context is, here is how AWARE captures it:

1On your daily life, your phone uses its internal sensors to collect data. We have automated the data collection process from most sensors available on modern Android smartphones. As new sensors become available and Android evolves, the more AWARE will grow. Being open-source, any AWARE developer can extend the framework at any time.

2Most of previous mobile research has been restricted to a few number of users, and very little of the work is reusable: frequently research studies build software and logging tools from scratch, over and over again. We support  reusability of research results, data and tools. More importantly, we enable cooperation between scientists, regardless of their discipline. AWARE is designed as a plugin architecture which allows anyone to contribute and extend AWARE’s capabilities.

The AWARE plugins’ primary goal is to collect and abstract sensors’  data to generate context. They may reuse other plugins’ context data to create new higher-level contexts. Data mining and machine learning techniques are built-in so you do not need to re-implement them. They might not have an interface for the user and be unobtrusive to the mobile device and the user.

Secondly, AWARE plugins may also present and explain context. They allow AWARE users to benefit from the added context capabilities and provide a user interface for interaction with or presentation of context information.




3The context produced by AWARE is shared through three different strategies: broadcasts, observers and providers. Each offer pro and cons, and they are available for both AWARE’s sensor, plugins and any installed application.

Used to quickly update other sensors, plugins and applications of the user’s context. It is the lightest way to get notified of context and an application does not necessarily need to have AWARE embedded: all you need to do is listen using Android’s BroadcastReceivers. You should use broadcasts to be notified of what is the current context, regardless of the data captured with it. You may capture one or more broadcasts simultaneously.

private static ContextReceiver contextReceiver = new ContextReceiver();
public static class ContextReceiver extends BroadcastReceiver {
public void onReceive(Context context, Intent intent) {
//Action for context here.

Be sure to keep the work short inside onReceive(). Broadcasts need to return under 15 seconds, otherwise Android will interrupt it with ANR (Android Not Responding) messages.

Then, you’ll need to register the BroadcastReceiver on your application or plugin. Android allows two methods to do so: on the manifest (for applications) or runtime (for plugins). The manifest ensures your application receives the broadcast, regardless of whether your application is actually active:

<receiver android:name=".Your_Receiver_Class" android:exported="true">
 <action android:name="ACTION_AWARE_PLUGIN_YOUR_RECEIVER_TRIGGER"></action>

For AWARE plugins, registering the BroadcastReceiver in runtime, will ensure your plugin will only receive the broadcast if it is active. If needed and similarly to the applications, you can also register it in the plugin’s manifest. For runtime registration, simply add the following code to the onCreate() method:

protected void onCreate(...) {
IntentFilter contextFilter = new IntentFilter();
//Check the sensor/plugin documentation for specific context broadcasts.
registerReceiver(contextReceiver, contextFilter);


aware-providersUsed to store sensors raw and plugins context data, implemented as Android’s ContentProviders. The data is stored locally on the device, and if required, remotely on a MySQL server using the AWARE dashboard.

Providers allow primarily passive access to the data. In other words, it is the sensor’s and plugin’s responsibility to request (i.e., pull) the data, using Android’s Cursor:

//CONTENT_URI is the sensor's or plugin's table URI
Cursor sensorData = getContentResolver().query(CONTENT_URI, tableColumns, whereCondition, whereArguments, orderBy);

Each provider has unique content URIs (i.e., path), one per each table it stores. Providers are SQLite database files, where each database has their own table(s) columns and schema. Check the specific sensor’s or plugin’s documentation for more details on the provider’s database information. Common to all are three table columns: _id, timestamp and device_id, which hold the database entry ID (automatically assigned at each insert), the time instance of the event and the mobile device’s AWARE’s Device ID.


aware-observersUsed to keep track of changes of context and sensor data in real-time, implemented as Android’s ContentObservers. Observers provide active (i.e., push) and event-driven access to context. Observers are energy efficient and allow real-time context labeling.

When you create an observer, you decide what happens when new data is available, like this:

public class ContextObserver extends ContentObserver {
public ContextObserver(Handler handler) {
public void onChange(boolean selfChange) {
//Update or query the data from the provider's URI.

Now that we have an observer, we need to specify what table you are tracking. Add the following to your application’s or plugin’s onCreate() method:

protected void onCreate(...) {
ContextObserver contextObserver = new ContextObserver(new Handler());
//CONTENT_URI is the sensor's or plugin's table URI you are interested in
getContentResolver().registerContentObserver(CONTENT_URI, true, contextObserver);

4You can download directly from the client additional functionality. Any additional sensor, application or plugin may be shared publicly or be study-specific. If needed, the AWARE client automatically notifies the user of an update or requests the user to install any plugin-dependency. The AWARE dashboard allows you to deploy large-scale, distributed studies, or personal studies:

  • AWARE-hosted or self-hosted databases
  • Concurrent studies
  • Study-specific or public plugins
  • Specify study’s active sensors
  • Enroll participants via a QRCode or a direct URL
  • Collaborate with other registered co-researchers
  • Monitor the study’s status (e.g., amount of data, participation)
  • Label and group sets of participants
  • Remotely design and trigger mobile questionnaires (ESMs)
  • Remotely request or clear the study data