A bit of a followup: http://developer.android.com/reference/android/os/SystemClock.html
Note that SendDelayed relies on uptimeMillis(), as described below: uptimeMillis()<http://developer.android.com/reference/android/os/SystemClock.html#uptimeMillis()> is counted in milliseconds since the system was booted. This clock stops when the system enters deep sleep (CPU off, display dark, device waiting for external input), but is not affected by clock scaling, idle, or other power saving mechanisms. This is the basis for most interval timing such as Thread.sleep(millls)<http://developer.android.com/reference/java/lang/Thread.html#sleep(long)> ,Object.wait(millis)<http://developer.android.com/reference/java/lang/Object.html#wait(long)>, and System.nanoTime()<http://developer.android.com/reference/java/lang/System.html#nanoTime()>. This clock is guaranteed to be monotonic, and is the recommended basis for the general purpose interval timing of user interface events, performance measurements, *and anything else that does not need to measure elapsed time during device sleep*. Most methods that accept a timestamp value expect the uptimeMillis()<http://developer.android.com/reference/android/os/SystemClock.html#uptimeMillis()> clock. On Monday, March 19, 2012 7:06:37 PM UTC-7, OldJim wrote: > > It seems a bit remarkable that this thread would get so long and fail to > actually discuss the REAL question - Why doesn't Delayed Send work. You > know, WHY it doesn't, not why you shouldn't do it because it somehow > weakens the entire Android ecosystem and other religious stuff. The simple > technical facts are entirely adequate to convince a thoughtful developer on > what NEEDS to be done to make his bloody app work per its design intent. > > At the heart of the issue on the WHY side is that: > > 1. Android reduces its activities to conserve power. > 2. Part of that reduction of activity means the app may not be scheduled > to run for a long time (even if it is left in memory). The processor may > actually HALT execution at times on some devices. > 3. And finally that Send Delayed is not implemented in the OS, it is > implemented in the app. So if the app does not run, the elapsed delay > interval is not recognized and the message does not get sent for an > unpredictable interval of time. > 4. On the other hand, The Alarm Manager IS implemented as an essential > service of Android and WILL generate a notification that CAN actually cause > your app to be started(and certainly scheduled), if necessary. > > I am interested in collecting any other pertinent information on this > technical point. > > Thanks, > Jim > > On Sunday, March 18, 2012 8:23:53 PM UTC-7, Kristopher Micinski wrote: >> >> > Thanks Mark. Why can't timers or handlers be used ?. There is nothing >> in the >> > documentation of why timers or handlers cant be used to run tasks >> after 24 >> > hours. >> > AlarmManager is more heavy weight on the OS. The documentation says >> that >> > you must acquire a WAKE lock when processing the alarm, since the >> device can >> > go to sleep as soon as the Intent is processed. This behavior is also >> not >> > what we really want for the application. The application has a simple >> > requirement to run a task every 24 hours. >> > >> >> Wait... this is just flat false. An alarm manager, which allows your >> app to safely be killed off and put away to be restarted later, that >> is lighter weight on the OS, than expecting that your app will >> constantly reside in memory on the device? >> >> This is *exactly* what an AlarmManager is for.. >> >> kris >> >> -- 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
