Android Restrictions You May Encounter During Development Process
Bluetooth and WiFi scanning issues, Background service obstacles that can appear in your way
Hi there! I am from the Navigine team. For eight years we have been providing integrated positioning mobile technologies that enable advanced indoor navigation and proximity solutions. As we have Android SDK and application, we have to meet various difficulties and restrictions on the development stage very often, that we decided to talk about them all in one article and show how to get around them. However, it’s worth noting, that in some cases we still have to put up and play by the rules of the Android.
WiFi scan limitations
In the previous articles, we told a little about WiFi scan limitations, but mostly it was about scanning in the background. Now let’s talk about all the limitations. Starting from Android 8 there is a restriction for background scanning — now you can start scan only once per 30 minutes. It sounds very deplorable, and if you take into account that there are still DOZE mode, you can assume that in the background you have almost no chance to scan the Wi-Fi, but still there is a small loophole, but more on that later.
Starting from Android 9 there are also foreground scan restrictions, now you can start a WiFi scan only 4 times per 2 minutes. That means you should distribute your scan equally during this 120 seconds for getting better results. By the way, it’s worth noting, that WiFi RTT ranging also needs WiFi scan starting, so you should alternate the WiFi receiver registering and unregistering for correct working. There is the code snippet above, how it should look like.
Bluetooth scan limitations
There are no documented issues in Android docs, but the limitations for the BLE scan also exist. Starting from Android 7 you could not start the BLE scan more than 5 times per 30 seconds. But here it’s worth noting an important point, unlike the Wi-Fi scan, the BLE scanning does not need to be restarted every time to get scan results, it will work in a loop. Therefore, this restriction may affect you if you decide to restart the BLE scan very often.
You cannot continuously scan. Attempt to do so and you will eventually stop discovering devices entirely. It’s also a battery drain and destabilizes other operations. You have to simulate continuous scanning using intermittent scan pulses. (From Android BLE Issues wiki)
The change also converts scans that are long-running into opportunistic scans. Initially long-running was defined to be 5 minutes, which was later increased to 30 minutes. An opportunistic scan will only get results if another non-opportunistic scan sees results that match the opportunistic scan’s scan filter. We assume this change is to prevent apps from scanning in the background endlessly.
Background service limitations
Probably the most interesting section of this article, there is real chaos with these services starting from Android 8. Most of the tips that you find on the Internet will not help you defeat the Android and force it to make your services work in the background. Firstly, a regular service that works fine up to and including android 7 will not work in the background at all starting from android 8. To solve this problem, Android offers two alternatives — JobScheduler and WorkManager.
WorkManager built using simple Service, so it works on old devices and using JobScheduler, so it works on new Android versions. If you do not want to bother with services and a job scheduler, you can just use the work manager and it will decide what to do itself. As you can see in the example above, it’s pretty clear to understand. There exist two types of works — one time and periodic. We used the periodic and put the timeout between works equal to 15 minutes because starting from Android 8 works could not be more often than once per 15 minutes. Otherwise Android will just reschedule this work.
Here the most amazing part begins, starting from Android 8 there is the concept of DOZE mode, which comes after a short time after you lock the screen and leave it idle and not connected to charging. As you can see, the documentation states that the job scheduler will not work, which means that your work manager will stop working and all your background tasks will not be performed as soon as the phone gets into DOZE mode. As soon as the user turns on the screen, or connects the phone to charging, the phone will exit this state and your task will continue its work. But here you need to decide how much you agree with such conditions.
Conclusion
You can see that the android is trying harder and harder to limit the capabilities of developers and trying to limit the possibilities in the background. But despite this, loopholes still remain to deal with all this.
In the next article we will tell in more detail about how to avoid restrictions in the background using foreground services, but of course about its limitations too. Development for Android is a thorny path, but the more interesting it is to develop for Android and look for ways out of various situations.
Thanks to Il Kadyrov.
