Lab 5 Periodic Task Scheduling

Transcription

1 Lab 5 Periodic Task Scheduling Scheduling a periodic task in Android is difficult as it goes against the philosophy of keeping an application active only while the user is interacting with it. You are generally discouraged for keeping your application active in the background, as it can have a harmful effect on (battery) resources of the phone, and Android will try to kill your app when resources are scarce. However, periodic background processing is sometimes necessary, especially for context sensitive mobile apps. In this lab we are going to look into AlarmManager, the main class for scheduling periodic wake ups, and connect it with accelerometer sensing. Periodic task scheduling The most reliable way for scheduling periodic tasks is to use the AlarmManager class. The class allows scheduling of alarms that can be captured with a BroadcastReceiver. First, let s create a new class that extends BroadcastReceiver, and call it SensingAlarmReceiver. Create a static synchronized method called startalarm : public static synchronized void startalarm(context context) We are going to use this method to test a few different ways to schedule a task. AlarmManager is a system s service, so we can access it using: AlarmManager am = (AlarmManager) context.getsystemservice(context.alarm_service); Now, we are going to schedule an Intent with a predefined action string for some time in the future. To create an intent that we are going to broadcast use: Intent intent = new Intent(ALARM_ACTION); PendingIntent pi = PendingIntent.getBroadcast(context, 1, intent, 0); ALARM_ACTION should be your unique string identifying the action. I used "si.uni_lj.fri.lrss.periodicsensing.alarm_action" We can schedule a periodic task using setrepeating function of AlarmManager : am.setrepeating(type,firetime,periodmillis,pi); Where type represents an integer determining how to consider time. There are a few possible options, such as: ELAPSED_REALTIME, ELAPSED_REALTIME_WAKEUP, RTC. Check the AlarmManager documentation to figure out which one works best in this case: The second argument, firetime, represents time in milliseconds when the first alarm is going to be fired. Set it to SystemClock.elapsedRealtime() plus the periodmillis, which is a period in milliseconds at which the alarm will be repeated. Set periodmillis to 30 seconds.

2 We have to capture the intent once it is fired. We are going to override onreceive method, and show a Toast message Alarm received every time it is called: Toast.makeText(context, "Alarm received", Toast.LENGTH_LONG).show(); But where do we get the context from? Since our SensingAlarmReceiver class is not tied to an Activity, we are going to extend the Application class and obtain a static context when needed. Let s create a new file called ApplicationContext that extends Application, and let s implement getcontext() method returning the static Application context: public class ApplicationContext extends Application { private static Context public void oncreate() { super.oncreate(); instance = getapplicationcontext(); public static Context getcontext() { return instance; * Note: there are some drawbacks of using the above method of obtaining context. Read about possible adverse effects, before using this approach. Back in SensingAlarmReceiver use ApplicationContext.getContext() when you need to access the context object. We are almost ready to test the periodic alarms. We just have to register our broadcast receiver SensingAlarmReceiver with ALARM_ACTION. Let s do that in AndroidManifest.xml : <receiver android:name="your_package_name.sensingalarmreceiver"> <intent filter> <action android:name=your_alarm_action /> </intent filter> </receiver> You can now go to MainActivity and add SensingAlarmReceiver.startAlarm(ApplicationContext.getContext()); to oncreate. Go ahead and test the code now. Do you get a toast message every 30 seconds? What if the app is in the background?

3 Periodic tasks drain battery quickly, so Android tries to bundle all the alarms together, and sacrifice some of the accuracy for energy efficiency. This is even more pronounced in newer APIs. We are going to force Android to fire an alarm exactly every 30 seconds by using setexact() method (if you are running API 19 or greater) or set() method (if you are running API less than 19. However, this method does not allow periodic scheduling. Instead, we are going to schedule a single alarm, then once it is trigger, we are going to handle it and instantiate a new alarm for periodmillis in the future. In startalarm check what is the API version and schedule a single alarm: if (Build.VERSION.SDK_INT >= 19) am.setexact(type,firetime,pi); else am.set(type,firetime,pi); In onreceive, after showing the Toast, recreate an alarm, by simply calling startalarm : startalarm(applicationcontext.getcontext()); Go ahead and test the code again. Do you get a toast message every 30 seconds? What if the app is in the background? Accelerometer sensing Context aware applications often rely on periodic alarms to schedule sensing tasks. In this way, an application can, for example, suggest walking routes once you get up and start walking. We are going to keep SensingAlarmReceiver, but instead of showing a Toast message, have it start sampling the accelerometer. This should be a background task performed in IntentService. Create a new class AccSenseService and have it extend IntentService. Accelerometer (and a few other sensors) sampling is controlled through SensorManager. Create a private field msensormanager, and set it in oncreate method: msensormanager = (SensorManager) getsystemservice(sensor_service); In onhandleintent method sample the accelerometer, if available: if (msensormanager.getdefaultsensor(sensor.type_accelerometer)!= null) { msensormanager.registerlistener(this, msensormanager.getdefaultsensor(sensor.type_accelerometer), SensorManager.SENSOR_DELAY_NORMAL); To be able to get the data once it is ready, we need to implement a SensorEventListener. Our AccSenseService can serve that purpose. Make it implement SensorEventListener, you will need to override public void onsensorchanged(sensorevent event). A single accelerometer sample is a triplet of acceleration along the x, y and z coordinate. If you observe the figure below, taken from the CenceMe paper, you will see that a single value is seldom useful. What we want are number of values taken a short period apart. This train of values is more likely to tell us if a user is sitting, walking, etc.

4 Create msensorreadings ArrayList, in which we are going to keep accelerometer samples, and a parameter mreqnumreadings that will define the number of readings we need. Set it to 50 for now. In onsensorchanged event.values gives you a raw accelerometer sample. Add it to msensorreadings, check if you have reached mreqnumreadings and if so, calculate mean, variance and mean crossing rate MCR ( crossing_rate ) of those mreqnumreadings samples. This is the information we are going to broadcast back to MainActivity using LocalBroadcast : Intent localintent = new Intent(BROADCAST_RESULT); localintent.putextra("mean", mean); localintent.putextra("variance", variance); localintent.putextra("mcr", MCR); LocalBroadcastManager.getInstance(this).sendBroadcast(localIntent); where BROADCAST_RESULT is a unique string describing your broadcast. I set it to "si.uni_lj.fri.lrss.periodicsensing.broadcast_result" GUI and Data Management We are about to create a GUI where a user will report if she is sitting or walking, so that the accelerometer sampling results are properly labelled. These results can later be used for classifier training. Open activity_main.xml layout and modify it to include a radio button group with two options: sitting and walking. Create a button Clear that allows the user to deselect both options. Finally, create buttons Start sampling and Stop sampling. Connect these buttons to SensingAlarmReceiver.startAlarm() and SensingAlarmReceiver.stopAlarm() respectively. Alarm stopping function in SensingAlarmReceiver cancels any pending alarms: public static void stopalarm(context a_context) { Intent intent = new Intent(ALARM_ACTION); PendingIntent pi = PendingIntent.getBroadcast(ApplicationContext.getContext(), 1, intent, 0); AlarmManager alarmmanager = (AlarmManager) a_context.getsystemservice(context.alarm_service); alarmmanager.cancel(pi);

5 Don t forget to remove startalarm from the activity s oncreate method. We want to receive the data in the activity and label it as sitting or standing depending on the radio button that the user s selected. Create an inner class AccBroadcastReceiver in MainActivity public class AccBroadcastReceiver extends BroadcastReceiver public void onreceive(context context, Intent intent) { float mean = intent.getfloatextra("mean",0); float variance = intent.getfloatextra("var",0); float MCR = intent.getfloatextra("mcr", 0); recordaccdata(mean, variance, MCR); recordaccdata() needs to be within MainActivity, check which (if any) radio button the user has selected, and record accelerometer mean, variance, and MCR to a local SQLite database. To create a database use SQLiteOpenHelper. Create a new class AccSQLiteOpenHelper extending SQLiteOpenHelper and create a new database acceleration_db, and a new schema with a table titled acceleration, and fields mean, variance, MCR and label, also don t forget the primary key _id. Instantiate AccSQLiteOpenHelper in oncreate of the main activity, and in recordaccdata() use its getwritabledatabase method to access the database. Use insert() method on the returned database to save the data (kept in ContentValues ), as seen in the lectures. When should the sampling be started stopped? We definitely want to obey the user s commands, i.e. start and stop when a user clicks on one of the buttons. However, we should also stop sampling when the application is destroyed. Override ondestroy() in your app, and call stopalarm() of SensingAlarmReceiver. When your app is ready to be tested, take some samples while seated (don t forget to select the correct radio button option), and then while walking (just walk for a few minutes in the hallway). Then come back in, connect the phone to your computer and inspect the database: #adb s emulator 5554 shell and then #sqlite3 /data/data/your_package_name/databases/acceleration_db Check the content of the database with.dump acceleration Classification The recorded data is a good start for building a classifier of a user s physical activity. If you have time, try adding a NaiveBayes classifier from MachineLearningToolkit library for Android. To add the library to your project, put the following line in your gradle.build file under dependencies :

6 compile 'si.uni_lj.fri.lrss.machinelearningtoolkit:mltoolkit:1.2' The source code of the library is publicly available on GitHub: Put the accelerometer mean, variance and MCR as features, and the label (sitting, walking) as the class in the classifier. Train the classifier with the collected data. Now, go back to your app, remove the labelling options, and modify the app to recognise the label from the sensed data. Happy coding!