Programming is like sex: one mistake and you have to support it for the rest of your life.
— Michael Sinz
How would I guess, back when writing the first version of I’m sleeping, that I would constantly need to come back to it with each release of a major Android version?
Even though Android has a mechanism which is supposed to eliminate such kind of burden, it wouldn’t work in this particular app’s case.
The purpose of the app is simple: wake at a precise time, twice per day to set or unset the volume of the phone’s ringer.
Easy enough! Simply use the framework’s AlarmManager:
alarmManager.set()
No, wait! Starting from Android KitKat (4.4), set() doesn’t guarantee precise timing anymore because of battery saving reasons. One has to use a new call:
alarmManager.setExact()
No, wait! In Android Marshmallow (6.0), setExact() doesn’t work when the device is in idle mode (ie. left alone on a table without moving), which means you’ll miss alarms. One has to use another new call:
alarmManager.setExactAndAllowWhileIdle()
The annoying thing is that each of these API changes would simply break my app if I wasn’t closely monitoring the framework’s evolution. I really hope there’s won’t be a setExactAndAllowWhileIdleAndDeepFreeze() or so call in a future revision of the framework.
This is a good example of why perfectly working and stable code still needs to be maintained because of all the changes around it (OS, drivers and libraries).
Update:
They did it again! From Android 12+, the following permission is required:
Update: the following was tested for N910FXXU1COH4 and N910FXXU1COI3. For N910FXXU1COJ3 Samsung added an “AppFreezer” system. But it still kills background processes.
The Galaxy Note 4 is an amazing piece of hardware. Recently, it was updated to Android 5.1.1 which solved many performance problems the previous Lollipop (5.0.1) release had.
Unfortunately, the phone still feels sluggish. When you go back to an app that was used 5 minutes ago, you can see how it recreates the app from scratch, there’s a delay with many actions and it feels like an old phone. If you compare it with ie. a Nexus 5, the latter feels faster to use, yet it’s older, has a weaker CPU and less memory.
But worse! With the 5.1.1 release on the Galaxy Note 4 some apps will behave badly. For example you won’t get incoming VoIP calls, missing messages, missing notifications on Android Wear and so on.
People often blame TouchWiz (the Samsung framework modifications). So I decided to have a look at their framework.
Samsung indeed does change the process management part of their device. It seems this was added during the early Android versions (1.x, 2.x) and most of it is not necessary anymore. The default memory management of Android was greatly enhanced since Android Honeycomb (3.x) and even more since ART in Lollipop.
Basically what Samsung does is kill apps and services in the background very frequently. I’m really puzzled of what’s the point in it. I suspect the Samsung engineer responsible for memory management is pictured below:
I have no idea of what I’m doing
And there’s a lot of memory management systems in their framework. It seems that when they noticed memory problems, they just wrote a new one!
Fortunately, there’s a way to solve it:
root your device
edit system/build.prop with the following:
Find the following line and switch it to false, like this:
sys.config.samp_spcm_enable=false
This disables the service killer. Now your services will run reliably. Let’s add the following lines to disable their memory management:
The first line disables their Smart Adjust Manager which is a system that tries to rate tasks, do some statistics and kill the ones that seem to take most memory. It seems like a good idea at first but unfortunately it kills tasks you use the most as well and has absolutely no place on a system with 3GB of memory.
The second line enables a simpler memory management system (in fact, it disables most of the old memory management stuff, the ones that you configure with dha/sha lines). It’s very close to the AOSP one.
Finally, the TRIM system, as its name implies, removes cached apps. It seems it was designed for devices with 1GB of memory or less. Why it’s enabled on a Galaxy Note 4 is beyond human understanding.
With these lines, the device feels just as fast and smooth as an AOSP device. Your battery will also lasts longer during active use because the device won’t spend time killing and recreating tasks all the time. Multitasking is a joy again.
This proves that TouchWiz is not bloated but it’s just their braindead memory management.
Note: these modifications likely work with other Galaxy devices but I don’t have the time to reverse engineer all of them. If someone wants to try (Galaxy S6, S6 Edge, Note 5) feel free to report your experience in the comments below.
Whoever owns an Android device might wonder why it is that, most of the time, the device barrely makes it through the day, even with moderate usage.
After many experiments, I finally found the culprit: Google Play Services and its location feature.
There are 3 settings in the location mode. Let’s go over them:
Device only: this setting is the most simple one (as long as the definition of simplicity does not take into account the math needed to derive a position from satellite beacons). It is the same system that a standalone GPS will use. Lock on to several satellites, download their ephemeris data and compute the position from that. The advantage is that there’s no network needed, just a clear view of the satellites. The disadvantages is that it can take 10-30 seconds and it doesn’t work so well indoors.
Battery saving: this mode will scan for a list of current WiFi accesspoints and the phone tower the phone is connected to then compare them with a (possibly cached) database from Google. Since Google knows the position from the data, it can give back a position. The advantage of this mode is that it’s very fast. The disadvantage is that it requires network coverage and communication with Google if the data is not cached.
High accuracy: this mode combines both previous modes. It scans for WiFi and phone towers, gets the data from Google but then, it uses the GPS to confirm that data, or, if Google had no match for it, it creates that new data for Google.
Wardriving for the masses
What happens when using High accuracy mode is akin to wardriving around with a laptop and a GPS and submitting the data to a central server (Google). This uses a lot of battery. Not only is the GPS often used but there’s plenty of network communication with Google and WiFi scanning. The device is also often woken up to perform a fix.
So which is the mode which uses the least battery power? It’s Device only. Just try it for a few days and you’ll see. The battery saving mode’s name is just plain bad naming. It will still perform scanning, communication with Google, and it won’t be very accurate in case there’s no access point around.
My Nexus 5 switched from not even a day of battery (high accuracy) to 3 days (device only).
Android’s media playing capabilites have always been an annoying issue. Either you use the high level MediaPlayer API where most of the control is about supplying an URL to play, or you use JNI to write low level C code to do all the work (as of 2014-01-20, Android Studio doesn’t support the NDK). Since Android 4.1 (API 16), there’s a MediaCodec API which gives access to the decoding process using java code. The concept is as follows:
This sounds great… until you start using it. Unfortunately, there are several shortcomings to that API:
no control over the buffers. MediaCodec has both getInputBuffers() and getOutputBuffers() methods which give pointers to buffers whose sizes cannot be chosen. On a Nexus 5, the former is 4 and the later is 19. The only option when one needs bigger buffering would be to copy them around, which incurs a performance drop.
MediaExtractor has no way to get access to the data-only portion of the stream. It’s basically designed to feed its output to MediaCodec. Feeding a stream composed of multiple parts (as in the case of HTTP Live Streaming) is impossible and you need your own custom parser.
There’s no control over the rendering. You cannot touch the buffers but just render them into a surface.
It looks like this API was mostly designed for encoding media and the decoding was added as a bonus. It should work fine for decoding a file. For network sources you’ll probably run into streaming issues. Anything more advanced requires diving into the complexities of the NDK and OpenMAX API.
On a related note, this blog post has a good history of Android’s video decoding.
Also it seems that Google is still making improvements on that area so it might not stay half-assed forever.
A new version of I’m sleeping has been released!
Changes in this version:
- automatically puts the phone in silent mode when set in the UI and the time is within the sleeping range
- likewise for unsilencing
- added a "call through" mode which allows repeated calls to reach you
So let’s see what Apple copied from Android invented with the iPhone 5:
Shared Photo Streams (Google+ Events Party Mode)
Panorama photo mode
taking photos while shooting a video
Points of Interests in Maps
Turn navigation
Satellite imagery in Maps
3D Maps
changing camera angle in Maps with 2 fingers
iCloud tabs (Google Tabs Sync)
Sports team scores in Siri
Movies recommendations in Siri
And I’m not talking about 5 GHz WiFi, 16:9 screen aspect ratio, 1080p video support, and backside illuminated camera sensor which were available on the Galaxy Nexus which was released almost a year ago.
I was pretty amused to discover that Apple’s Do Not Disturb feature in iOS 6 is pretty close to my Android application I’m sleeping, which was available long before their version.
Android doesn’t offer such feature by default (but some ROMs do). At first, I was puzzled by that lack. I searched on Google Play but didn’t find anything that suited me, namely:
simple and intuitive user interface
intelligent design, with separate settings for week days and week ends
white list, allowing close friends or family to call you at all times
manual mode for naps or out-of-schedule sleeps without having to reconfigure everything
So I wrote it myself. Apple’s version is similar except it uses favorites instead of a white list. It also has a “go through” mode if the caller insists but doesn’t feature a manual mode (Apple still didn’t “invent” widgets).
Android is not very well documented when it comes to power consumption. Most user manuals tell you that, in order to save power, you have to turn off the features you don’t need. While these advice have their merits, they often involve a significant trade off. For this article, we’ll focus on wifi usage.
Wifi versus mobile data
When it comes to power usage, wifi behaves quite differently than 2G/3G mobile data. To keep things short, wifi is more power efficient when doing actual data transfer but less when staying on doing nothing, at least that’s the case with simple implementations. For example, my Sony Ericsson Xperia X10 Mini Pro (Android 2.1) will barely last a day when wifi is turned on and connected to an access point (AP) and there’s a reason for that:
contrary to what happens with mobile data, Android cannot sleep while a wifi link is active, even idle
Well. At least that statement was true until fairly recently.
Wifi powersaving mode
Since recent versions of Android, a power saving mode (PS-Poll) was implemented and many phones use it. It works in the following way and is only active when the screen of the mobile device is off:
the AP will keep packets for the phone buffered
the phone will periodically (typically every few seconds) poll the AP and asking if there are new packets
if there are, the AP will send them in a burst
It’s like if the phone was taking a dive, surfacing each few seconds to ask if there are packets. This decreases greatly power usage. The drawback is that it increases latency significantly and some APs don’t handle power save mode properly and simply disconnect the device. This is fine for “background data” usage though (syncing, email checking and so on).
Here’s how to test if your phone supports PS-Poll:
connect to your AP
on the phone, go to Settings / About phone / Status and look the IP address field
on a terminal on your computer, type:
ping -t <ip_address> (note: on Linux/Unix, drop the -t)
You should get some output like:
Reply from 192.168.1.71: bytes=32 time=452ms TTL=64
Reply from 192.168.1.71: bytes=32 time=200ms TTL=64
Reply from 192.168.1.71: bytes=32 time=1512ms TTL=64
Reply from 192.168.1.71: bytes=32 time=762ms TTL=64
Reply from 192.168.1.71: bytes=32 time=1768ms TTL=64
Anything bigger than 1000ms indicates that PS-Poll is active. Turn on the screen and notice how the timing become smaller because then PS-Poll is disabled, bringing better latency.
Sleeping is the key
While PS-Poll helps a lot, it still doesn’t solve the main issue. Phones’ greatest power saving strategy is to put the processor (CPU) to sleep mode, basically the same that happens when you put your laptop to “sleep”. You close the lid, the machine stops but the memory content stays intact so that you can quickly wake up again to resume work.
And this is also what recent phones are able to do. For example the Samsung Galaxy S II and the Galaxy Nexus have a dedicated ARM Cortex-M3 chip (a full blown CPU) and dedicated memory in their wifi subsystem. This allows the phone to be put to sleep while the wifi link stays active.
Android 4.0 and default wifi sleep policy
This is probably why the default sleep policy in Android 4 (ICS) was changed from “sleep when screen turn off” to “never”. I was actually surprised to see the change and had to do some research to find out why this was done.
Now not all phones implement this but if your phone is recent, chances are it does.
