Proposal for context management

From Openmoko

Revision as of 11:40, 1 June 2008 by Kombipom (Talk | contribs)

Jump to: navigation, search

The Context section of the new framework could be used to choose between a number of profiles that determine which services are running, the settings for outputs and what events will interrupt the current in-focus application and deliver outputs. These profiles could be overridden by individual rules selected by the user.

If 'context sensitive profiling' is turned on the phone checks the context regularly and changes the profile in use if required. All profiles can of course be edited by the user and new profiles defined. The profiles will have to be prioritised.

Defining Context

Each profile would have a defined set of criteria in which it will become active. The system checks through each set of criteria in priority order and assigns the first which matches.

Possible criteria:

Within X meters of GPS co-ordinates YY:ZZ.

Gesture or position reported by accelerometers

Current time and/or date

Power status

A particular application has focus


A profile can define:

Which services are active; GSM, BT, WiFi, GPS

What events will interrupt the current application; Call, Message, Alarm

Output settings; Volume, vibration, screen brightness


A "profile rule" can be set to override a particular aspect of the currently active profile.

If no context rules are defined the profile can only be activated manually and will remain in force until context awareness turned back on or another profile is selected.


Some examples of context choosing a profile:

Phone face down at rest for >5 seconds -> SLEEP

Battery power below 20% -> LOW-POWER

GPS registers position as within 100m of "home" -> HOME

GPS registers position as within 500m of "work" -> WORK

Time between 1900-2330 -> PUB

Time between 2330-0500 and within 5km of "city centre" -> CLUB

No context match -> DEFAULT


"home", "work" and "city centre" all defined by GPS co-ords by user.

These profiles are in priority order so if the phone is face down battery power, GPS position and time will make no difference. If you are at home the PUB and CLUB profiles will not be engaged.


Examples of profile definition

Services= GSM,BT,WiFi,GPS.

Interrupts= Call, Message, Alarm.

Outputs= Volume, Vibration and Screen Brightness.


SLEEP: All service off, call & message interupts off, volume & vibration normal, screen off

LOW-PWR: GSM on BT,WiFi,GPS off, all interupts on, volume & vibration normal, screen max 50%

HOME: All service on, call & message interupts on, volume & vibration normal, screen normal

WORK: All service on, call & message interupts on, volume silent, vibration normal, screen normal

PUB: All service on except BT, call & message interupts on, volume silent, vibration normal, screen normal

CLUB: GSM GPS on BT,WiFi off, call & message interupts on, volume loud, vibration normal, screen 50%

DEFAULT: All service on except BT, call & message interupts on, volume & vibration normal, screen normal

D.N.I.: All service on, call & message interupts off, volume & vibration normal, screen normal


D.N.I (do not interrupt) is an example of a non-context driven profile.

No context driven system will be fool-proof but I think in this way we can build a relatively simple system that can have quite complex behaviour and importantly can be overridden and turned off quite simply.

GUIs needed:

Profile selector with "Context On" button (context awareness switched off by selecting any profile) and list of current profiles and ability to change priority of profiles and go to profile editor.

Profile editor

Context editor to define events and match them to profiles


Also needed (will be needed for other apps too I think):

Method of defining and tagging gestures eg "face-down"

Method of tagging GPS co-ords to define "home" etc.


I hope that this makes some kind of sense.

Personal tools

The Context section of the new framework could be used to choose between a number of profiles that determine which services are running, the settings for outputs and what events will interrupt the current in-focus application and deliver outputs. These profiles could be overridden by individual rules selected by the user.

If 'context sensitive profiling' is turned on the phone checks the context regularly and changes the profile in use if required. All profiles can of course be edited by the user and new profiles defined. The profiles will have to be prioritised.

Defining Context

Each profile would have a defined set of criteria in which it will become active. The system checks through each set of criteria in priority order and assigns the first which matches.

Possible criteria:

Within X meters of GPS co-ordinates YY:ZZ.

Gesture or position reported by accelerometers

Current time and/or date

Power status

A particular application has focus


A profile can define:

Which services are active; GSM, BT, WiFi, GPS

What events will interrupt the current application; Call, Message, Alarm

Output settings; Volume, vibration, screen brightness


A "profile rule" can be set to override a particular aspect of the currently active profile.

If no context rules are defined the profile can only be activated manually and will remain in force until context awareness turned back on or another profile is selected.


Some examples of context choosing a profile:

Phone face down at rest for >5 seconds -> SLEEP

Battery power below 20% -> LOW-POWER

GPS registers position as within 100m of "home" -> HOME

GPS registers position as within 500m of "work" -> WORK

Time between 1900-2330 -> PUB

Time between 2330-0500 and within 5km of "city centre" -> CLUB

No context match -> DEFAULT


"home", "work" and "city centre" all defined by GPS co-ords by user.

These profiles are in priority order so if the phone is face down battery power, GPS position and time will make no difference. If you are at home the PUB and CLUB profiles will not be engaged.


Examples of profile definition

Services= GSM,BT,WiFi,GPS.

Interrupts= Call, Message, Alarm.

Outputs= Volume, Vibration and Screen Brightness.


SLEEP: All service off, call & message interupts off, volume & vibration normal, screen off

LOW-PWR: GSM on BT,WiFi,GPS off, all interupts on, volume & vibration normal, screen max 50%

HOME: All service on, call & message interupts on, volume & vibration normal, screen normal

WORK: All service on, call & message interupts on, volume silent, vibration normal, screen normal

PUB: All service on except BT, call & message interupts on, volume silent, vibration normal, screen normal

CLUB: GSM GPS on BT,WiFi off, call & message interupts on, volume loud, vibration normal, screen 50%

DEFAULT: All service on except BT, call & message interupts on, volume & vibration normal, screen normal

D.N.I.: All service on, call & message interupts off, volume & vibration normal, screen normal


D.N.I (do not interrupt) is an example of a non-context driven profile.

No context driven system will be fool-proof but I think in this way we can build a relatively simple system that can have quite complex behaviour and importantly can be overridden and turned off quite simply.

GUIs needed:

Profile selector with "Context On" button (context awareness switched off by selecting any profile) and list of current profiles and ability to change priority of profiles and go to profile editor.

Profile editor

Context editor to define events and match them to profiles


Also needed (will be needed for other apps too I think):

Method of defining and tagging gestures eg "face-down"

Method of tagging GPS co-ords to define "home" etc.


I hope that this makes some kind of sense.