Personalisation in smart phones requires adaptability to dy- namic context based on application usage and sensor inputs. Current personalisation approaches do not provide sucient adaptability to dy- namic and unexpected context. This paper introduces the Android Ge- netic Programming Framework (AGP) as a personalisation method for smart phones. AGP considers the specic design challenges of smart phones, such as resource limitation, and the Android programming envi- ronment. We demonstrate AGP's utility through empirical experiments on two applications: a news reader application and an energy ecient localisation application. Results show that AGP successful adapts appli- cation behaviour to user context.

1. Android Genetic Programming Framework
Alban Cotillon
Philip Valencia
Raja Jurdak
CSIRO ICT Centre, Brisbane,
Australia

2. Why GP for Smart Phone Personalisation
Why personalize smart phones?
• Exponential market growth in recent years
• Diverse user preferences and contexts
• Broad range of embedded sensors
• Access to huge Internet data base
• High* computation power
Why use online GP?
• Limitations of rule-based approaches
• Need adaptation to new contexts
• Need to continuously evolve
Why Android?
• Open-source
• Support Java development
• Quick prototyping
Paper goal
• To demonstrate AGP’s ability to solve multi-
objective problems in dynamic environments

3. Design Considerations – Interaction and
Resources
• User interaction
• Direct access to Android API (no scripting
language)
• Developer-specified permissions
• Limited resources
• Computation
• Energy
• Android API battery level
• System file to track consumption
• Key idea
Learn more when there is more slack

4. Design Considerations – Services and Intent
• Services
• Long running background operations through Android services
• Interpreter Shell
• Processes generated programs
• Runs in separate thread from main application
• Avoid ANR errors for buggy programs
• No direct access to sensors
• Interpreter context keeps track of which sensors have been used
for this application
• Avoids powering off sensors needed by other applications

5. The AGP Framework

6. AGP Data Structures and Populations
• Functions and Terminals
• AGP-specific interfaces
• FunctionInterface and TerminalInterface
• Specify primitive arity, string serialization representation, estimated
time cost
• Use Strategy Pattern for flexibility
• FunctionSet and TerminalSet
• Store available functions and terminals for application
• Developer can add, remove or search primitives
• Populations and Programs
• Use Builder Pattern
• Implemented as trees Access to function and
terminal sets, and helper

7. Selectors, Genetic Operators, and State
• Selectors
• Evaluation thread ranks running programs in execution thread
• Top-ranked programs chosen to breed next generation
• Use wheel selectors by default
• Currently supports two genetic operators
• Crossover
• Mutation
• Saving program and population state
• Needed for undesired reboots, crashes, battery depletion
• Use serializable classes
• Specialised builders to reconstruct populations and programs from
serialized form saved in a file
• UnserializePopulationBuilder
• UnserializeProgramBuilder

8. Injecting Expert Knowledge
• Constrain evolution landscape
• Needed to avoid resource overutilization
• AGP supports two components
• Helper
• Called during program generation process
• One or more per application using HelperInterface
• Use evaluate() function to specify correctness conditions for application
• E.g.: discard program for geolocalization that do not call a location
service
• Supervisor
• Runs during program interpretation
• Check constraints on-the-fly
• Can kill Interpreter Shell if constraints exceeded
• E.g.: enforce limits on program execution time

9. Case Study: Google Reader Application
• Provides selected news feeds to users
• Preferred content is context-specific for Smart Phones
• Less text
• More photos
• Whenever the user wants to get news, she asks for a news
report which executes a GP program and returns the latest and
unread news from feeds selected by the program.

10. Experiments and Results
• 7 news sources
• 4 technology news
websites
• 1 infographics
• Break Videos
• Business Green for
latest green products
• User has entered
interest for all sites
• Preference for
technology news
sites on smart
phone
• Desired story count
set to 10
• Pool size is 5
programs

11. Case Study: Context-aware Localization
• Smart Phones provide several location
data sources
• GPS
• Cell-tower
• Wifi
• Context-specific cost benefit for each
technology
• Position
• Signal quality
• Device energy profile

12. Accuracy Fitness
• During learning
• Evaluation thread keeps all location providers on
• Uses provider with best accuracy as best position

13. Energy Fitness
• Assumptions
• Assume day-long operation
• Use 1400mAh battery capacity
• Target average current draw of 63 mA for 22 hours
• Implementation
• Use Android PowerProfile class
• Assess energy cost based on selected location provider and CPU
usage
• Energy fitness is a linear function between 0 and 1
• 0 means the program energy cost will not meet the daily operation
target
• 1 means the program costs no energy

14. Experiments and Results
• 12 programs/population
• Evaluation time is 1 minute
• Function set provides arithmetic functions and
location provider selection functions
• Two sets of experiments with and without Helper

15. Discussion and Conclusions
• Android Genetic Programming Framework
• Smart phone personalization through online GP
• Demonstrated on two case study applications
• Diversity/usability considerations
• Future work
• Cooperative evolution through the Island Model

16. Thank you
Dr. Raja Jurdak
CSIRO ICT Centre
Principal Research Scientist
Research Group Leader
Phone: +61 (0)7 3327 4059
Email: raja.jurdak@csiro.au
Web: http://jurdak.com
University of Queensland
Adjunct Associate Professor