Android Genetic Programming Framework

Alban Cotillon

Philip Valencia

Raja JurdakCSIRO ICT Centre, Brisbane,

Australia

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

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

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

The AGP Framework

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

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

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

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.

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

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

Accuracy Fitness

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

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

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

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

Thank you

Dr. Raja Jurdak

CSIRO ICT CentrePrincipal Research Scientist

Research Group Leader

Phone: +61 (0)7 3327 4059

Email: raja.jurdak@csiro.au

Web: http://jurdak.com

University of QueenslandAdjunct Associate Professor