ve registered to
listen for it, even if those processes may not do much work. This can have a
substantial impact on both device performance and user experience.

To alleviate this issue, Android 7.0 (API level 24) applies the following
restrictions:

  * Apps targeting Android 7.0 (API level 24) and higher do not receive ` [ CONNECTIVITY_ACTION ](/reference/android/net/ConnectivityManager#CONNECTIVITY_ACTION) ` broadcasts if they declare their broadcast receiver in the manifest. Apps will still receive ` [ CONNECTIVITY_ACTION ](/reference/android/net/ConnectivityManager#CONNECTIVITY_ACTION) ` broadcasts if they register their ` [ BroadcastReceiver ](/reference/android/content/BroadcastReceiver) ` with ` [ Context.registerReceiver() ](/reference/android/content/Context#registerReceiver\(android.content.BroadcastReceiver, android.content.IntentFilter\)) ` and that context is still valid. 
  * Apps cannot send or receive ` [ ACTION_NEW_PICTURE ](/reference/android/hardware/Camera#ACTION_NEW_PICTURE) ` or ` [ ACTION_NEW_VIDEO ](/reference/android/hardware/Camera#ACTION_NEW_VIDEO) ` broadcasts. This optimization affects all apps, not only those targeting Android 7.0 (API level 24). 

If your app uses any of these intents, you should remove dependencies on them
as soon as possible so that you can properly target devices running Android
7.0 or higher. The Android framework provides several solutions to mitigate
the need for these implicit broadcasts. For example, ` [ JobScheduler
](/reference/android/app/job/JobScheduler) ` and the new [ WorkManager
](/arch/work) provide robust mechanisms to schedule network operations when
specified conditions, such as a connection to an unmetered network, are met.
You can now also use ` [ JobScheduler
](/reference/android/app/job/JobScheduler) ` to react to changes to content
providers. ` [ JobInfo ](/reference/android/app/job/JobInfo) ` objects
encapsulate the parameters that ` [ JobScheduler
](/reference/android/app/job/JobScheduler) ` uses to schedule your job. When
the conditions of the job are met, the system executes this job on your app's
` [ JobService ](/reference/android/app/job/JobService) ` .

On this page, we will learn how to use alternative methods, such as ` [
JobScheduler ](/reference/android/app/job/JobScheduler) ` , to adapt your app
to these new restrictions.

##  User-initiated restrictions

On the [ **Battery usage** page within system settings
](https://support.google.com/pixelphone/answer/7015477) , the user can choose
from the following options:

  * **Unrestricted:** Allow all background work, which might consume more battery. 
  * **Optimized (default):** Optimize an app's ability to perform background work, based on how the user interacts with the app. 
  * **Restricted:** Fully prevents an app from running in the background. Apps may not work as expected. 

**Note:** When a user places your app in the "restricted" state but later
launches your app, the system temporarily treats your app as if it were in the
"unrestricted" state. When the user stops interacting with your app and begins
interacting with another app, the system places your app back in the
"restricted" state.

If an app exhibits some of the bad behaviors described in [ Android vitals
](/topic/performance/vitals) , the system might prompt the user to restrict
that app's access to system resources.

If the system notices that an app is consuming excessive resources, it
notifies the user, and gives the user the option of restricting the app's
actions. Behaviors that can trigger the notice include:

  * Excessive wake locks: 1 partial wake lock held for an hour when screen is off 
  * Excessive background services: If app targets API levels lower than 26 and has excessive background services 

The precise restrictions imposed are determined by the device manufacturer.
For example, on AOSP builds that run Android 9 (API level 28) or higher, apps
running in the background that are in the "restricted" state have t