Add your SDK
Home / Technology
Enjoy the best mobile SDKs news, tips & tricks, sent to you by mail

Android O: What Happens in the Background No Longer Stays in the Background

August 10, 2017 2:51 PM

It’s that time of year again when we get ready for the new Android OS version. Each Android version has plenty of small, nice, nice-to-have changes and one big major change. Lollipop brought us ART, Marshmallow brought us Runtime Permissions, and Nougat brought us multi-window. Now, Android’s cracking down on battery wastage and background activity.

Even though you might think OS upgrade is slow in the Android ecosystem (Nougat, for example, is “only” used by 11.5% of the user base), keeping your app updated is very important. First, 11.5% of the population is no small pickings. If you’re still bent on supporting Jelly Bean devices, no reason you shouldn’t support Nougat or O. Second, if you intend your app to run on a Pixel device (no reason why you wouldn’t), you better make sure your app is O-compatible, because some of the changes will affect *all* apps on these devices. And third, numbers are often deceiving. 11.5% of the global market may not apply to you. Your personal user base may very well reach as many as 95% using the latest and greatest.

So it’s settled then. You should make sure you’re compatible.

But what is it really all about? Android O is about being through being nice. For too long, Android has been a wild wild west of manufactures tweaking the OS, apps doing pretty much whatever they wanted and users constantly complaining that their battery runs out too fast. Well, no more.

Background Activity Limitation

The #1 cause for battery drain is excessive background activity. And that’s the biggest thing Android’s changing.

There are no new strict limitations to when the app is in foreground. It can start and run as many services as it wants. But, when in background, its services will be stopped. That’s right, after a small grace period, any service still running in background will be killed by the OS.

Some specific tasks will get longer grace periods (to the extent of several minutes). What makes a task special? That is does something the user eventually sees and/or interacts with. Such tasks include the handling of high-priority messages via Firebase Cloud Messaging, starting a VpnService or handling a legitimate broadcast receiver or notification.

Anything else you want to be doing while in background is now prohibited. If you want to check users’ Facebook status, location, or swing any other kind of background activity, you must use JobScheduler. In a nutshell, JobScheulder was introduced in Lollipop to help the device sleep better, save battery and only perform small works in controlled maintenance windows. It has now been enhanced to take over background and intent services. Best practice then, a must now.

Background Location Limitations

As mentioned, background activity is restricted. Background location activity is restricted as well. Now, this deserves a whole section for itself because background location activity is often the bread and butter of many apps and libraries, such as navigation apps.

In background, location access will be restricted to a few times per hour only. This is a major change, to the app code itself as well as to the 3rd party SDKs that rely on constant location reads. And how much do they read location in background? The following is an illustration taken from the SafeDK Dashboard of an ordinary app:

SDKs accessing Location in background, almost 3 reads per user per minute!

This, by the way, is one of those “affects all” kind of changes. All apps running on an Android O device, regardless of whether they are compatible or not, will have restricted background activity. And specifically restricted background location-access activity.

Some Implicit Broadcast Receivers Were Harmed in the Making of this Android

Part of the wild wild west we were talking about, allowed apps to register Broadcast Receivers via the manifest file and request to be notified of changes on the device. Network changes, Wi-Fi changes, chargers being plugged in and out etc. The result was that even if the app was dead, the OS had to wake it up or even recreate it in order to relay the message. These are known as “implicit broadcast receivers”.

On the contrary, apps could register receivers dynamically in code. This means that they’ll only be notified as long as the app is alive, but the app will not be resurrected once it was dead.

Android O is no longer just encouraging you to use dynamic Broadcast Receivers. It forces you. Many implicit receivers will simply no longer be called. So you better clear those battery hogging classes from your manifest and start explicitly registering them in code. You can find the list of restricted receivers here and adjust your app accordingly.

The main reason for this change, as mentioned before, is improving battery life, by disallowing multiple apps broadcast receivers to be all awoken at the same time.

Prepare for the Change – It’s a Big One!

Here’s the big thing you must understand. The changes in Android O are not background changes (pardon my pun) and are no small potatoes. They will actively disrupt app’s activities.

And you may think your app doesn’t rely on background services and implicit broadcast receivers that much. And you might even be right. But what about the 3rd party libraries and external tools you’re using? They may rely on it more than just a bit. Sometimes their whole product is based on this and they may stop working or giving you what you want. So you have to check your SDKs made the necessary adjustments and that you’re using their updated versions, the Android-O compatible ones, if and when they become available.

In many cases, using incompatible SDKs means you’re harming your app and losing users and money over it. Make sure you’re ready for the change. You and your partners – the SDKs.

5 Tips on Configuration for Mobile SDK Developers

May 23, 2017 3:51 PM

The deployment cycle of a mobile SDK is different than that of a mobile application – no matter how often and quick your release cycles are, you’re still dependent on the release cycles of the hosting app. This fact makes it harder to test and tweak your code based on production experience.

Configurable parameters to the rescue! Making your code configurable by adding parameter control from the server is not limited solely to the development stage of the SDK lifetime, it can be extremely beneficial in production as well. All part of the deal when you don’t control when new versions and code will be rolled out to users. So, while using configurations is a good practice for mobile apps and SDKS alike, for SDKs it can literally become a ‘make it or break it’ issue.

The basic need is for your code to behave differently based on server-side configuration. The configuration can include different behaviors for different customers, A\B testing, general parameters used throughout the code etc.

The implementation details can vary between different platforms, languages and use cases, but there are a few common issues to consider.

Continue Reading

NSLog or os_log: How to Log for Multiple iOS Versions?

February 27, 2017 3:53 PM

Our QA guy informed me one day that he doesn’t see our log messages when testing on an iOS 10 device.

“Good morning Siri darling, ” I clicked the round icon on the top right edge of my screen. “I don’t see my NSLog messages, please advise…”

“You should switch to os_log API”, she arrogantly replied. “And please stop asking me how much is 36 times purple, which bear is best or can Chuck Norris beat Thor in a fistfight”.

Thank you Siri, I’ll see what I can do.

Basically, a quick look around our code revealed that our NSLog calls are no longer displayed in the console application. Now, we write our code as a library. This means that our log messages within the app, the ones our QA looks for when testing, were part of a dylib compiled in release. And under those circumstances, NSLog doesn’t work starting with iOS 10.0. What does work? Well, according to Siri, a new API, the os_log API, should do the trick.

What is os_log API, you ask? Well, officially it’s called the “Unified Logging System.” Its function is described as “centralizing the storage of log data in memory and in a data store on disk.”

And so we were faced with quite the conundrum. The new os_log API is the way to go, Siri said so herself, but it’s only available starting with iOS 10.0. We had no choice – we had to use the new API when available, but still use NSLog for the old versions.

How were we to do that?

Continue Reading

Hello, Kotlin! Converting an Android Project – Part 2

January 24, 2017 10:37 AM

I was trying to convert an Android project to Kotlin in Android Studio via the Kotlin plugin. If you haven’t read part one (you can always do it now), then I’ll briefly tell you that it’s up to you to choose how many classes to convert. I chose them all. The conversion caused numerous compilation errors and practically swayed me to convert one/two classes at a time. Even though solving compilation errors was a great way to learn, I still had an ambition – convert my MVP example project from Java to Kotlin code.

Therefore, I decided to attack it from another angle. My second approach was less messy – one or two compilation errors per conversion, albeit it took me a couple of hours to get everything working.

In the following post I will cover:

  • Adapter’s getView() runtime error, caused by the conversion
  • Kotlin pros/cons for Android developers
  • Verbosity comparison of Java vs Kotlin

TL;DR Conversion might cause errors but Kotlin will reduce NullPointerExceptions, and minify your code into a much more readable version.

Continue Reading

Hello, Kotlin! How to Convert an Android Project – Part 1

January 17, 2017 5:13 PM

I’ve been hearing about Kotlin everywhere. It’s the new big thing in the Android world. So big that Gradle themselves are talking about incorporating it.

So I set out on a journey to see what the hype is all about.

What is Kotlin? Well, simply put it’s a statically-typed language from the house of JetBrains that compiles to Java’s bytecode and therefore can be run using a JVM. It’s got lots of interesting features and full compatibility with Java.

The following post is not a conventional Hello World tutorial on Kotlin, rather it’s an experiment with a big bold “don’t try this at home” warning. It’s risky and code might break because I’m going to convert a whole project of a mid-level complexity (30 classes) at the click of a button, or rather 4 buttons (ctrl + alt + shift + k). If that won’t work out (spoiler alert: it didn’t), I’ll switch to plan B and convert my project one class at a time.  I’ve decided to see if they’re making good on their promise, as well as teaching myself a new programming language upside down. From big concepts to the finer details.

Because I’m going to mess with lots of code and it might not end up pretty I chose to convert one of Android’s google-samples projects which I forked. I chose the todo-mvp branch: https://github.com/SerjSmor/android-architecture. If you are unfamiliar with different styles of Android architecture (MVC, MVP, MVW) or their implications I highly recommend going over them anyway if you haven’t yet.

TL;DR: we’re converting a TODO List app.

Environment:

IDE = Android Studio 2.1.2. There’s a plugin for Eclipse too.

Kotlin version = 1.0.4

The before photo (before tinkering):

Hello, Kotlin! How to Convert an Android Project – Part 1

Continue Reading

The App Store Policy That Might Get You Rejected in 2017

December 21, 2016 9:48 AM

Update: Apple just announced that it is postponing the ATS compliance deadline. A new deadline is unknown at this time.


During WWDC 2016, in the What’s new in Security session, Apple announced it will start enforcing App Transport Security in the App Store by the end of 2016. Our research indicates that most apps are still using keys that disable this policy and are not ready for this new regulation.

App Transport security (ATS) was introduced during WWDC 2015: “If you link your app against OS X El Capitan or iOS 9, by default it won’t be able to make any unprotected HTTP connections; they will simply fail…”

Now, with 2017 only a few days away, apps face harsher scrutiny by Apple. As if it wasn’t already tough enough getting through the review process unscathed, app publishers are now checked at the door for unsecure connections. Any irregularity and you won’t be let into the store before doing some proper explaining.

Continue Reading

Two Years of Multidexing: Is the 65K Limit Still a Big Deal?

October 20, 2016 8:42 AM

I still remember when I saw my first multidex app. It was almost two years ago and ho so rare. It was an almost religious experience – seeing something you didn’t think could exist with your very own eyes. And yet today I’m surprised when I stumble upon an app and it only has one dex file. Seriously, it’s like finding an oasis in the Sahara. A sight for sore eyes.

Which is why I was so surprised when our saleswoman told me about a meeting she had, where the developers in question specifically asked about it. They were determined to stay single dex no matter what.

You see, silly me, I thought the 65k limit was like one of those things you read about in history books or see in old movies. But it turns out I was living in a bubble. But hey, can you really blame me? Even Android’s own new compiler – Jack – refers to it in both code and documentation as “legacy”.

Which leads me to really think – is the 65K limit in Android still a big deal?

Continue Reading

Mobiles on Fire: Am I Using Firebase or Google Play Services?

September 13, 2016 5:15 AM

It’s been almost five months now since Google announced the new generation of Firebase with great fanfare at this year’s Google I/O, and true enough mobile developers have been adapting. In fact, our research at SafeDK uncovers that nearly 8% of top apps are already actively using Firebase, with Firebase Crash Reporting definitely leading the pack in strength (and that’s just a sneak peek spoiler at our next Android SDK Market Report).

But if you’re a mobile developer and have tried integrating Firebase then you may have found yourself feeling more confused than anything else.

You see, Firebase is this big SDK from the house of the rising Google that answers many of a developer’s needs with the premise being “and it’s all completely free”. Analytics, Crash Reporting, Database, Storage space, Push Notifications and more. Some aren’t even mobile SDKs, just great services for developers such as hosting services and so on.

But Google already has a huge amazing all-you-need-ever-wanted-and-can-ask-for SDK. It’s called the Google Play Services. An SDK which over 96% of [Android] developers use, according to our research. And well, that’s exactly where the confusing parts kick in.

For all of you TL;DR folks – Firebase is actually a part of Google Play Services. What does that mean? Well, read on.

Continue Reading

Through the Nougat Glass: What’s New with the New Android?

July 6, 2016 6:05 PM

Android N is now officially Android Nougat (sorry to everyone who were still hoping for Namey McNameface…) and the APIs are now official, so it won’t be long before the new Android will be released and shipped off to users globally.

Now true, the name itself has left many fans with a bitter aftertaste. Google took it’s time struggling with this one. Finding a candy name that’s both favorable and rolls off the tongue easily and that Android-ers wouldn’t find hard to swallow was a tall order. The craziness even posed the question – are nuts technically a candy?

But Alas, Nougat is what it is.

Which means it’s just the right time to check in and find out what’s new with the new Android.

Continue Reading

The JIT of N: How Android’s ART Will Be Faster?

May 30, 2016 1:18 PM

If you’ve read some of my posts in the past, you know I have a near-obsession with mobile app start time. And I know I’m not alone there. It’s this generation “We can lend a man on the moon” most favorite complaint – It’s 2016, how can it be we’re still waiting for apps to launch?

Well, looks like indeed I’m not alone. I’m in good company with the nice folks over at Google / Android, who are doing some nice things to improve app start time.

One of the most interesting things I’ve heard in both keynote and sessions at Google I/O two weeks ago was how the ART virtual machine has improved and how well it’s going to affect both start time and system update time. Alongside the introduction of Android Instant Apps, it looks like Android is looking to dispose of any unnecessary waiting time.

Continue Reading