Android One Plus 6(android Pie Version) Boot Complete Broadcast Receiver Not Working

Android One plus 6(Android pie version) BOOT COMPLETE Broadcast Receiver not working

Solution 1:

I faced same problem in OnePlus 6. I was going to make background service and it should be auto-started after restarting device. The BOOT_COMPLETED intent received for most devices, but not working in OnePlus 6. I tried to search and found solution. The reason is that my app is optimized on Battery Optimization. I changed the status to Not Optimized, after that it's working well.

Add permission on AndroidManifest.xml

<uses-permissionandroid:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>

White-list / optimization enabled your app

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
        Intentintent=newIntent();
        StringpackageName= getPackageName();
        PowerManagerpm= (PowerManager) getSystemService(POWER_SERVICE);
        if (!pm.isIgnoringBatteryOptimizations(packageName)) {
            intent.setAction(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
            intent.setData(Uri.parse("package:" + packageName));
            startActivityForResult(intent, 1000);
        }
    }

I hope it will be helpful.

Solution 2:

This is a special broadcast which you must hold a specific permission in order to receive (from the documentation for ACTION_BOOT_COMPLETED):

You must hold the Manifest.permission.RECEIVE_BOOT_COMPLETED permission in order to receive this broadcast.

Be sure to declare that in your manifest. No runtime permissions are needed since it is a "normal" level permission. However, your app must also get started for the first time by the user (e.g. an Activity in your app) before the system will ever deliver this broadcast to your app.

Solution 3:

You cannot start a Service from a Receiver that gets pinged in the background on API 26+. This is not specific to the One Plus 6 -- it's universal across all phones.

See: https://developer.android.com/about/versions/oreo/background

You can get around this restriction with an ugly workaround:

From your Receiver, start an Activity instead of the Service (declare the Activity in your Manifest as well):

<activityandroid:name=".DummyActivity" />

...

publicclassConnectionReceiverextendsBroadcastReceiver {
    @OverridepublicvoidonReceive(Context context, Intent intent) {
        IntentstartActivityIntent=newIntent(context, DummyActivity.class);
        context.startActivity(startActivityIntent);
    }
}

In the DummyActivity, immediately start your Service, then call finish()

publicclassDummyActivityextendsAppCompatActivity {

    @OverrideprotectedvoidonCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        IntentstartServiceIntent=newIntent(this, MyBackgroundService.class);
        startService(startServiceIntent)
        finish()
    }
}

The screen will flicker momentarily as the Activity starts then finishes immediately, but the experience isn't too jarring for users.

Consider the nature of your background work and strongly consider moving to more modern APIs, such as Work Manager. Again, the behavior above is ugly and ongoing background Services are being pushed out by battery life improvement efforts by Google. If you insist on using a Service, and the work being done is ongoing, you should be using a Foreground Service.

Across a few hardware/sensor stacks, new APIs have been added for API 26+ to help you avoid manual ongoing background work in Services. For example, BluetoothLeScanner added an overload to startScan that takes a PendingIntent as a parameter instead of a ScanCallback, so that you can let the system perform your predefined operation in the future, instead of having to keep a scope open (in a Service) in order to handle ScanCallback function calls.

Share