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).
As usual, when there’s the word simple somewhere in the name of a protocol or API, it’s a big warning sign.
So today I forgot to enable the LOGIN authentication mechanism in the SSL connection of my SMTP mail server. The following happens with Windows Live Mail when sending a mail:
it tries to authenticate but fails silently
it tries to then send the email directly (like a spammer would do)
This is a good example of over engineering which comes back to bite you hard. Trying to send an email directly (that is, connecting ot the SMTP server of the recipient) should work in theory. In practice, most servers will reject this because most dynamic connections end up in many anti spam lists. The funny thing is that Windows Live Mail is completely silent about this. It doesn’t even show a warning or anything and if I didn’t check my mail logs, I wouldn’t have figured out why a client’s email messages would frequently fail to reach their destination.
But of course the real reason is that email is a mess.
How to represent datatypes? For example in a JSON output.
Dates
Don’t do things like:
2014-01-17T18:01:30+01:00
Seriously. Do you have any idea how difficult and computationally intensive this is to parse? And I’m not even talking about the variants with timezones like GMT, PST, Z, +- offsets and so on.
Instead, do the following:
1389978090000
This is the number of milliseconds since the beginning of times, that is 1st January 1970 with an UTC time zone. It’s easy to parse and there’s no room for interpretation. Every library understands that format.
Durations
Don’t do
3111.44
This uses floats. Not only it can give rounding errors but it’s slower than integers. Instead do:
3111044
which is the number of milliseconds. Again easy to parse and every timer related library understands integer milliseconds, not necessarily floats.
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
Crysis 2 is a great game. Outstanding graphics, fast dynamic rendering, good sound effects, advanced AI, etc.. Then someone at Crytek decided to remove quick saving at the last minute before releasing the game, making it annoying to play.
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.
