Reading Time: 5 Minutes
Android has always been considered the more “powerful” mobile platform when compared to iOS because of how much freedom its 3rd-party applications have. This enables a lot of automation to take place simply because Android applications can do more tasks while they’re running in the background. However, this comes with a downside as it opens the door for potentially more battery drain thanks to background processes running on the device.
It’s one thing to know you’re loading up your phone with applications that run in the background since you’re willing to sacrifice some of your battery life for the benefits they bring. It’s a different story if you’re just downloading traditional applications which aren’t optimized and that perform tasks in the background when you don’t want or even need them to. Google has been working to fix this by placing more and more restrictions on what applications can do in the background, and the release of Android O brings the most background process/receiver restrictions by far.
However, the vast majority of users won’t see Android O on their devices for many months from now (if at all). But if you are running Android 7.0 or Android 7.1, there’s a simple trick you can do to manually prevent an application from ever running in the background – and it doesn’t require root or a third-party application. This is more powerful than what Greenify or apps like Brevent offer, as without root access those apps are fairly limited in what they can do. But with this trick, now you can block apps such as Facebook or Hangouts from ever running in the background – they will only work when they are actively being used!
Restrict Background Processes Tutorial
- Install the USB drivers for your particular device OEM (Google provides a list of some universal USB drivers here).
- Download the ADB binary for your particular OS (Windows, Mac, Linux). These links will always point to the latest version of the binary.
- Extract the contents of the ZIP file into an easily accessible folder on your PC.
- Go to the Settings app on your phone and tap on the About Phone option.
- Find the Build Number and tap on it 7 times to enable Developer Mode.
- Go back to the Settings main menu and enter Developer Options so you can enable USB Debugging Mode.
- Plug your phone into the computer and change it from “charge only” mode to “file transfer (MTP)” mode. This is not necessary on every device but many devices require this as a security measure before allowing ADB to work.
- Go back to the PC and browse to the directory where you extracted the ADB binary.
- Launch a Command Prompt or Terminal in your ADB directory. For Windows users, this can be done by holding Shift and Right-clicking then selecting the “open command prompt here” option. (Some Windows 10 users may see “command prompt” replaced with “PowerShell”.)
- Once you’re in the Command Prompt or Terminal environment, enter the following command:
- This will start the ADB daemon if it hasn’t been launched already, just wait for it to finish. If this is your first time running ADB, you will also see a prompt on your phone asking you to authorize a connection with the computer. Allow USB Debugging access here.
- Now if you re-run the adb devices command from step 10, the command prompt/terminal will print the serial number of your device. If so, then you’re ready to move on. If not, then the USB drivers are likely not installed properly.
- You will then need to find the package name for the application you’re wanting to freeze background processes. You can do this by installing the App Inspector application on your phone.
- Go back to the Command Prompt and enter the following command:
- Now execute the following command to free an application’s background processes:
cmd appops set RUN_IN_BACKGROUND ignore
- If you ever want to revert the change you have just made and allow an app’s background processes again, enter this command:
cmd appops set RUN_IN_BACKGROUND allow
- You’ll know it works if it takes you back to another ADB shell prompt and doesn’t give you an error message.
How exactly this command works is that it allows you to restrict a hidden permission that is normally not accessible to the user in the Settings app. This permission is called the RUN_IN_BACKGROUND permission and the only way it can be modified is to use “cmd appops” which is the command line interface for “App Ops” – Google’s user-facing permission management system.
Google added this hidden ADB command that enables you to restrict any application from receiving implicit broadcast intents (ie. the app waking up in the background) and also prevent those applications from scheduling background services without using JobScheduler (ie. the app waking up at an inopportune time, draining your battery). This command is actually meant for use only by developers looking to simulate how their app would perform under low memory conditions, but thankfully we’re able to put it to our own use.
By removing dependencies on an app’s background services and manifest-registered implicit broadcast receivers, developers can optimize their application to run better on low-memory devices. Google says applications optimized for these type devices, or ones which are in low-memory conditions, can improve both the performance as well as the user experience. At Google I/O this year, the company announced a modified version of Android called Android Go, that will be used for very low-memory smartphones, so we presume that this command would be useful for developers aiming at that platform.
In any case, this command can be fairly useful for the average user, but be careful what you restrict here. Apps such as Hangouts or Facebook will completely stop syncing in the background until you open them up, which if this is what you are aiming for then I’m sure you don’t mind. But don’t be surprised when your emails or messages become delayed if you run this command on an app that depends on background receivers.
Latest posts by Richard Swain (see all)
- What would happen if we upload our brains to computers? | Robin Hanson - 12 September 2017
- An All-metal FAN?? - 12 September 2017
- Samsung Announces a New 11nm LPP Process, 7nm LPP on Schedule - 11 September 2017