I got bitten by this the hard way. The official documentation on services doesn't have any warnings about this, so I figured onDestroy() was good enough. I had some audio shut down code in onDestroy() that wasn't getting called when the phone was being shut down, so I'd have a corrupt file because the MP4 file would not be properly finished by Android's MediaRecorder.
What would you recommend as an ideal way to handle this? Trap the shut down intents? Unfortunately, it seems that won't handle other instances where the app might kill the service, though I do register it as a foreground service. On Thursday, August 11, 2011 5:16:41 PM UTC-4, Mark Murphy (a Commons Guy) wrote: > > On Thu, Aug 11, 2011 at 4:58 PM, Mikael Kuisma <kui...@ping.se<javascript:>> > wrote: > > System.exit()? > > No, a regular stopSelf() / IntentService should be fine. > > > Since Android keeps the DVM around even after I terminate my > > services and activities, I thought it would be a nice place to store the > > state via a singelton object to save flash writes. > > As a cache, sure. Don't count on it though -- save your data before > onHandleIntent() returns or you call stopSelf(). Static data members > are *only* to be used as a cache. > > >> Users don't like sloppy developers who keep services in RAM for no > >> good reason. Guess what? Users win. > > > > A good reason is to save unnecessary flash writes, wouldn't you say? > > Users don't notice "unnecessary flash writes", assuming that they are > done on a background thread. They do notice services running 24x7. > Developers who create such everlasting services have harmed Android's > reputation and spawned the creation of task killers and equivalent > capabilities within the OS itself. > > You are welcome to write daemon processes that run forever on your 8GB > RAM Web server. Please don't do it on a 192MB RAM phone. > > >> You have to know "how long the next sleep will be", by definition. > >> After all, you have to tell Android when to resume operation of your > >> code, regardless of how you accomplish it (AlarmManager, > >> Thread.sleep(), postDelayed(), etc.). > > > > I don't control the user, I'm sorry. > > Then who is calling set() on AlarmManager to trigger your PendingIntent? > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://github.com/commonsguy > http://commonsware.com/blog | http://twitter.com/commonsguy > > Android Training in Oslo: http://bit.ly/fjBo24 > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
