Profile cover photo
Profile photo
Arne Stockmans
Lead Android Developer at November Five
Lead Android Developer at November Five

Arne Stockmans's interests
View all
Arne Stockmans's posts

Post has attachment

Post has attachment
Fully resizable apps will arrive sooner or later on Android and ChromeOS. I wrote a blogpost about why I think this'll happen and how to prepare your app for it.

Post has attachment
On moments like these, I really love the split screen feature of Android! #android #nougat #splitscreen #f1 #MexicoGP

Post has attachment

Post has attachment

Unknown error code during application install: "-505"

One of our clients told us today that some users couldn't install or update their app anymore.
The Google Play Store gave the users a message "Unknown error code during application install: "-505"".
First we thought it'd probably be a temporary bug in the Play Store, but after investigation it for a while we found out it was caused by our app.
Well, not only by our app, but also by a different app with the same "bug".

It appears that when we upgraded to Google Play Services 8.3 (the issue is also reported on v8.1 btw), Google added a new Provider to our manifest file.
Its authority is set to "{your app's applicationId}.google_measurement_service", which shouldn't be a problem.
By including the applicationId, you can be sure the authority is unique and doesn't clash with any other apps.
The problem is that for some reason, we didn't have our applicationId defined in the build.gradle file.
This caused the authority to fallback to "".
As you can see, the chances of this being unique for all your users isn't that high anymore.
So if a user has a different app installed, which also had this issue, he couldn't install your app anymore.

Once we figured this out, we tried to reproduce this issue.
Luckily one of our employees reported the same issue this morning, so we had a test device.
When trying to install the current version of the app using adb install, we saw the error "INSTALL_FAILED_CONFLICTING_PROVIDER".
But when we tried to install the modified version where we explicitly added the applicationId in the build.gradle file, everything worked fine :)

Post has shared content
Android Studio - Code completion for design time layout attributes

Finally, Android Studio 2.0 enables code completion for design time layout attributes!

+ Design time layout attributes:
+ Source: [13:27]


Post has shared content
Good lord this is freakin' awesome
I want this in my IDE so it matches the inside of my head when I'm in the zone.
Animated Photo

Post has shared content
A flowchart for background work, alarms, and your Android app
Pro-tip by +Ian Lake

For many apps, doing work in the background can be an important part of building a great experience. An alarm registered with AlarmManager ( is one way to schedule your app to be run sometime in the future, even if your app isn’t in the foreground. What alarm type and API should you use for your app or are alarms even the best option? Let’s go through some of the factors that should influence your opinion:

How often do you want to trigger?
For events less than 60 seconds apart, alarms aren’t the best choice: use the much more efficient Handler ( for frequent work.

Want to set a user visible alarm clock?
On API 21+ devices, new APIs allow you to set a user visible alarm via setAlarmClock(): the system UI may display the time/an icon and apps can retrieve the next alarm clock with getNextAlarmClock(). Note that alarms set with setAlarmClock() work even when the device/app is idle (similar to setExactAndAllowWhileIdle()): getting you as close to an exact wake up call as possible. For backward compatibility, you’ll follow the same guide below for a single alarm.

Wake up the device/app while idle (i.e., doze, app standby)?
On Android 6.0+ (API 23) devices, additional power-savings optimizations ( have been added in the form of Doze (triggered by a completely stationary, unplugged, and idle device) and App Standby (triggered by an unplugged device on idle apps that haven’t been used recently). You’ll use setAndAllowWhileIdle() for inexact and setExactAndAllowWhileIdle() for exact alarms if you need it to fire an alarm while in these idle states. If it can wait until the user returns to their device/your app, use the standard set() and setExact() to be the best Android citizen and save your user’s battery.

(We’ll be talking more specifically about Doze and App Standby later!)

Just a single alarm?
A single alarm can be set with the aptly named set() method. One thing to keep in mind is that on API 19+ devices when you target API 19+, the system will be treated as inexact, potentially batching alarms together - the alarm will never go off before the time specified, but may go off afterwards. If you have some flexibility in the start time but have a hard deadline, consider using setWindow() to gain more control over the exact time period to be used.

You can use setExact() for a precisely timed single alarms on API 19+ devices, but use these only when the exact timing is required (such as with a calendar reminder).

Need to repeat at a constant rate?
For repeating alarms, batching is the key to good battery life. setInexactRepeating() does exactly that. Prior to API 19, you can use one of the INTERVAL_ constants (such as INTERVAL_HOUR to batch alarms of the same interval. On API 19+ devices, all repeating alarms (no matter what the interval) set with setInexactRepeating() will be batched.

You’ll note there’s also setRepeating() - similar to set() the behavior changes with API 19 from exact to inexact repeating alarms, meaning if you are on an API 19+ device and target API 19+, this functions identically to setInexactRepeating(). If you really need exact repeating alarms on API 19+, set an exact alarm with setExact() and schedule the next alarm once your alarm has triggered - keep in mind the battery implications though!

BUT WAIT: should you even use alarms?
If you want to be as battery efficient as possible (and you should!), consider using JobScheduler ( on API 21+ devices or GcmNetworkManager ( on all Google Play services enabled devices of API 9+.

Supporting both one off and periodic work, these APIs lack the ability to wake from idle, but gain the ability to wait for network access, wait until the battery is charging, take advantage of automatic backoff and retry, persist across reboots, and batch jobs across the system (meaning lower battery usage!).

That’s a lot of good reasons to use JobScheduler and GcmNetworkManager so consider them strongly in your push to #BuildBetterApps

Post has shared content
As an addition to the article: There's a useful gist from Jake Wharton which will fail your build if you're using dynamic versions. In combination with gradle init scripts you can easily make sure your build server stops building projects with dynamic versions.
Wait while more posts are being loaded