Warning: Sony Xperia Z, STAMINA, and AlarmManager
The SONY Xperia Z has STAMINA.
No, this has nothing to do with physical fitness, little blue pills, etc.
Instead, STAMINA refers to a battery “stamina” feature, that the user can toggle on via the “Power Management” screen in Settings.
When you toggle it on, you are greeted with the following description:
When the screen is off, Wi-Fi and mobile data will be temporarily disabled, and most applications will be inactive. You will still receive phone calls, SMS/MMS messages and, Sony™ calendar notifications and Sony™ alarm signals. The music player and FM radio will work, and downloads and uploads in progress will be allowed to finish. When the screen is on, your phone will function normally.
This is slightly in error — the screen has to be off and the device has to be unplugged for this behavior to occur. Also, apps can be added to a whitelist (“Apps active in standby”), where STAMINA mode does not affect those apps’ behavior.
The fact that WiFi and mobile data become unavailable to apps in this state, while different, is something developers should already be dealing with. On Android 4.0+, the user can set bandwidth caps per app, and therefore it is entirely possible that an app will “lose connectivity” for reasons other than the device itself actually losing connectivity. The trigger mechanism is merely different.
What scared me was the “and most applications will be inactive” part. And, as it turns out, my fears were justified.
In short, _WAKEUP style alarms do not wake up the device when it
is in STAMINA mode.
For example, I ran
one of my WakefulIntentService samples
on an Xperia Z in STAMINA mode. This sample is set to log an “I ran”
message to LogCat every 15 minutes.
03-06 18:09:05.194: D/ScheduledService(4237): I ran!
03-06 18:24:05.276: D/ScheduledService(4237): I ran!
(screen allowed to go dark at 18:30, plugged back in/turned on at 19:00)
03-06 19:00:15.967: D/ScheduledService(4237): I ran!
03-06 19:09:05.202: D/ScheduledService(4237): I ran!
(added to whitelist, then screen dark)
03-06 20:24:05.226: D/ScheduledService(4237): I ran!
03-06 20:39:05.236: D/ScheduledService(4237): I ran!
The behavior, therefore, is a bit reminiscent of non-_WAKEUP
alarms. Alarms that occur while the device is asleep are suppressed,
and you get one invocation of your PendingIntent at the point
the device wakes back up. At that point, the schedule continues as
though the alarms had been going off all along. Apps on the whitelist
are unaffected.
This is not necessarily a bad feature from the user’s standpoint. For example, with STAMINA mode on (and all other power-saving settings at their default), the Z gives me an “estimated standby time” of 80 hours. With STAMINA mode off, it gives me an estimated standby time of 40 hours. I have not tested the accuracy of those estimates, but users will generally consider 80 to be superior to 40. Hence, a resonable number of Xperia Z owners will experiment with STAMINA mode.
Mostly, you need to be aware of this from a support standpoint. If Xperia Z owners complain that your app behaves oddly, and you determine that your alarms are not going off, see if they have STAMINA mode on, and if they do, ask them to add your app to the whitelist.
If you are using “if my alarm has not gone off in X amount of time, the user perhaps force-stopped me, so let me reschedule my alarms” logic, you should be OK. Before one of your activities gets a chance to make that check, your post-wakeup alarm should have been invoked, so you can update your event log and last-run timestamp. Hence, you should not be tripped up by STAMINA and accidentally reschedule your alarms (potentially causing duplicates, depending upon your alarm-scheduling logic).
There may be other effects of STAMINA mode in the area of “and most applications will be inactive” that I have not tried.
The lesson for device manufacturers is that while you are welcome to make these sorts of changes, you should be shouting to developers from the rooftops about these changes and their specific impacts. Otherwise, you run the risk of developers considering your devices to be buggy and generally irritating them. If you are concerned that your rooftops are not high enough to reach all developers by shouting, work with those of us in the Android community to amplify your message.
