https://developer.android.com/about/versions/oreo/background?hl=ja
[Shakyo]: For myself
In order to avoid unexpected shutdown of the application due to system load etc., the execution operation of the application is restricted when the application is not directly operated. There are two ways to limit it.
--Restrict background services when the app is idle --No restrictions apply to foreground services
Restrictions are imposed on Android 7.0 (API 24) or later, and restrictions are strengthened on Android 8.0 (API 26).
With a few exceptions
--The app cannot use the manifest to register implicit broadcasts. --However, you can register an implicit broadcast when the app is running. --Apps can use manifests to register explicit broadcasts.
| Note: By default, these restrictions apply only to apps that target Android 8.0 (API 26) or later. However, even if your app targets less than API 26, users can still enable most of these restrictions for their app on the Settings screen. (Constraining will ensure the quality of the user experience) |
In many cases, the app can work around the limitation with JobScheduler </ font>.
JobScheduler </ font> lets you take action when your app is inactive, but you can also schedule it so that it doesn't affect the user experience.
Android 8.0 adds some improvements to JobScheduler </ font> that make it easy to replace services and broadcast receivers with scheduled jobs. For more information, see JobScheduler Improvements.
JobScheduler: </ strong>
A schedule service that manages tasks so that various processes can be executed efficiently. </ font>
--There is visible activity (may have been paused)
--Use foreground service
--The app is connected to another foreground app and is bound to one of the services of the foreground app
--The app is connected to another foreground app and is using the foreground app's content provider
= Example of binding other foreground apps =
In any other state, the app is considered background processing.
| Note: The above rules do not apply to bound services. If your app defines a bound service, you can bind another component to that service, whether your app is in the foreground or not. |
You are free to generate and run foreground and background services while your app is running in the foreground. When the app goes to the background, it can afford to generate and run services for only a few minutes, after which the system determines that the app is idle and Service.stopSelf. Stop the background service of the app, like when using the () </ font> method.
The condition for the app to be whitelisted is when the user is doing the following visible processing.
Under certain conditions, the background app will be on a temporary whitelist, free to launch and run for a few minutes.
--High priority Firebase Cloud Messageing (FCM) </ font> message processing --Receive broadcasts (SMS / MMS messages, etc.) --Execute PendingIntent from notification --Starting VpnService before VPN app promotes confidence to the foreground
When dealing with background services in IntentService
| Note: Since IntentService is a service, it is subject to new restrictions on background services. Therefore, apps that depend on IntentService will not work properly on Android 8.0 or later. For this reason, Android Support Library 26.0.0 introduces a new JobIntentService class. This class provides the same functionality as IntentService , but uses jobs instead of services when running on Android 8.0 and above. |
JobScheduler In many cases, the app will replace the background service with a JobScheduler </ font> job (for example, when migrating to Android 8.0: API 26 or later). Scheduled jobs are launched on a regular basis, query the server, and finish.
In Android 8.0 and earlier, the way to create a background service is to create a background service and then promote that service to the foreground.
Starting with Android 8.0, the system no longer allows background apps to create background services. Instead, a startForegroundService () </ font> method has been introduced that is used to start a new service in the foreground.
After executing startForegroundService () </ font>, startForeground () </ font> </ strong> will be called within
Learn how to apply background limits for less than API 26. Setting background limits helps maintain the quality of the user experience.
You can enable restrictions on your app on the ** [settings] ** screen even if your API is less than 26. new You may need to update your app to comply with the restrictions.
--Depends on the processing of background services when the app is idle --Declaring a receiver for implicit broadcasts in the manifest
If your app is idle and it relies on the processing of background services, your app will need to replace these services.
**
--If your app is in the background and you want to create a foreground service
startForegroundService </ font> method, startService () </ font> Use instead of to generate foreground services
--The service displayed to the user should be the foreground service.
Use the startForegroundService </ font> method instead of startService () </ font>. Use to generate foreground service
--Duplicate service functionality with scheduled jobs
Generally, use scheduled jobs as an alternative to services that are not running in a user-recognizable situation.
--Without polling in the background, </ font> Use FCM to selectively launch the app when a network event occurs
Polling: Query other systems at regular intervals </ font>
--Hold background operation until the app naturally goes to the foreground
Check the broadcast receiver defined in the app manifest. If you declare a receiver for implicit broadcasts in your manifest, you need to replace it. Possible solutions are:
**
--Instead of declaring the receiver in the manifest, call Context.registerReceiver () </ font> to create the receiver at runtime
--Use a scheduled job to see the conditions that triggered an implicit broadcast
Recommended Posts