Compared to iOS, Android is a much more open platform, offering more freedom but also allowing for more lawlessness. Android has fewer restrictions on apps than iOS, which has spawned a lot of rogue apps. While Google has been trying to put more restrictions on the backend and clean up android’s ecosystem, rogue apps have resorted to desperate tactics to stay in the backend. Rogue App resident background has what strange skill lewd skill? Take a look.
Android system background mechanism
Let’s start by talking about Android’s background mechanics, which will give us a clearer picture of why rogue apps tend to reside in the background. Android is a Linux-based operating system, so its background mechanism is similar to That of Linux — typically, applications are not pushed out of the background when they return to the desktop, but run continuously in the background until the system needs more resources.
Android doesn’t just clean up background processes, in Android, App is divided into Foreground_App (foreground App), Visiable_App (visible App), Secondary_App (secondary App), Hidden_App (hidden App), Content_Provider (content provider), Empty_App (empty App) Such as state. When the Empty_App process and service run out of memory, the Empty_App process and service run out of memory. Memory gets tight again, so start messing with Content_Provider, and so on. Therefore, the more important processes are kept and the less important processes are cleared out of memory first, which seems to be fine at first glance.
However, things are not satisfactory, the rogue App is rogue, is not obey the rules. Android has too much leeway for apps to do anything in the Background. Even with The introduction of Doze napping in Android 6.0 and the introduction of background-free Android O, rogue apps can still quietly dominate the Background. Rogue apps can even turn phones into hand warmers that last up to two hours without special background killing tools or roMs that have special restrictions on the background.
Rogue App resident background skills: disorderly registration state
As mentioned, Android divides apps into several states, but rogue apps don’t follow these rules and make the background run according to these states. For example, a rogue App can register itself as foreground application through startForeground so that its background foreground is the highest priority and will never be eliminated by the system.
However, this method has been officially taken by Google. On Android 4.3 or higher, if an App registers this status incorrectly, the notification bar will show “XX is running in the background”. Although rogue apps got around it by some means, Google closed the vulnerability in Android 7.0. If you upgrade to Android 7.0 and an App keeps saying “XX is running in the background” in the notification bar, you’re a rogue App.
Rogue App resident background skills: transparent suspension window
This is an imaginative move, as we know that unlike iOS, apps can display floating Windows in the system, providing users with all kinds of real-time information. An App with a floating window will run all the time, and the process won’t be cleaned up. One rogue App will set up a transparent suspension window with a size of 1 pixel. The user can’t see it, but the suspension window does exist. When the App retreats to the background, the process is preserved thanks to a floating window.
This method has also been noticed by Google, in the new version of Android system and many third-party ROMs, apps can no longer apply for permission to hover window.
Rogue App resident background skills: random request wake up
As anyone who has used Android knows, the most annoying thing about rogue apps is that they start randomly, which is inseparable from rogue apps asking for a wake-up call randomly. Android has a wake up mechanism, so the App can trigger specific actions with specific events. For example, when the time is up, the App can trigger a ringtone; For example, when connected to the network or after a certain interval, the App can trigger the data synchronization action. These actions need to wake up the App to run, so the rogue App will frequently use the “Alarm”, “Sync Adapter” and other periodic tasks to wake up themselves, so that they continue to start in the background, which is also the reason why many background apps can not completely eliminate the rogue App background process.
For this, Google officials also tried to use the alignment wake up mechanism to solve the problem. In Android 6.0, Google introduced Doze mechanism, so that background processes as much as possible in a uniform cycle wake up at the same time, so that the CPU gets as long as possible sleep time. However, this mechanism is not radical enough and requires the phone to sit still for a long time to work. Overall, the effect is limited. Doze doesn’t even work if you’re using your phone a lot, and rogue apps are still gobbling up battery power.
Rogue App resident background technique: processes wake up each other
In addition to using Android’s wake up mechanism, rogue apps can also use processes to wake each other up. On the one hand, rogue apps can register multiple processes in the background, and even if one process is killed, it can be woken up by other processes. If you look carefully, you can see that many apps register more than one process in the background, just to wake up. On the other hand, rogue apps can wake each other up in groups! When you start application A, its process may wake up application B, and application B’s process may wake up application C in turn. This kind of “chain wake up” is particularly common in Domestic apps, which is hard to prevent.
There’s a reason why chain awakenings are so common. Due to the absence of Google services, many Domestic apps have to use some third-party SDKS in order to achieve push and advertising functions. These third-party SDKS often wake up apps in groups. Many APPS actually don’t want to play rogue, but with these third-party SDKS, they have to stay rogue. There is, of course, a way around this, and a way for aspiring developers to avoid “chain arousal” is to tap into the Project Condom open source library (go to the Github home page here) while using the Rogue SDK.
Google is also aware of the problem, as the android 8.0 development specification requires apps to stop all background services for a short period of time once they enter the background and not start new ones. It remains to be seen how effective this will be, as Android 8.0 is not yet widely available.
Rogue App resident background skills: complicity
This should be the ultimate coup! If the rogue App itself is in cahoots with ROM, the App will undoubtedly have the highest right of way and will not be killed anyway. For example, when have you ever seen native Android kill Google Play (not to mention Play is not a rogue service)? Domestic a pile of ROM will not kill their own rogue push service, but also rely on push to sell advertising.
Users are essentially helpless in the face of this situation. Third-party ROMs based on AOSP may solve the problem, but not all devices have conditional swipes.
conclusion
In fact, The Android ecosystem has become almost a vicious circle, rogue apps constantly find ways to stay in the background, and various ROMs to deal with rogue apps, the background restrictions are increasingly tightened, which makes Android gradually lose its original selling point. To this end, the industry is also trying to solve the problem of rogue App, for example, developers put forward the Android green application convention (click here to view), domestic developers are also planning to establish a unified App push mechanism, reduce the need for App background resident, hoping that the Android ecosystem can eventually get better and better.