Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
559 views
in Technique[技术] by (71.8m points)

android - Background execution not allowed receiving intent BOOT_COMPLETED

I've read about Android Oreo background execution limitations, and it clearly states that BOOT_COMPLETED broadcast is unaffected, but I can't get it to work on Android Oreo.

First, I am compiling against SDK 27. Secondly, I declared the receiver inside the manifest file:

    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
    <receiver
        android:name="helpers.StartDetectionAtBoot"
        android:label="StartDetectionAtBoot"
        android:enabled="true"
        android:exported="true">
        <intent-filter>
            <category android:name="android.intent.category.DEFAULT"/>

            <action android:name="android.intent.action.MY_PACKAGE_REPLACED"/>

            <action android:name="android.intent.action.BOOT_COMPLETED"/>
            <action android:name="android.intent.action.QUICKBOOT_POWERON"/>
            <!--For HTC devices-->
            <action android:name="com.htc.intent.action.QUICKBOOT_POWERON"/>
            <!--For MIUI devices-->
            <action android:name="android.intent.action.REBOOT"/>
        </intent-filter>
    </receiver>

Then there's the implementation of the receiver, which can also be simple as that:

public class StartDetectionAtBoot extends BroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {
        Log.i("test", "test");

        Intent intent0 = new Intent( context, ActivityRecognitionService.class );
        PendingIntent pendingIntent = PendingIntent.getService(context, 111, intent0, PendingIntent.FLAG_UPDATE_CURRENT);
        ActivityRecognitionClient activityRecognitionClient = ActivityRecognition.getClient(context);
        activityRecognitionClient.requestActivityUpdates(5000, pendingIntent);
    }
}

onReceive method is not called and I will always get logcat error on Android Oreo devices/emulator:

W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.BOOT_COMPLETED flg=0x400010 }

Reading other answers, they said there were some problems when registering explicit intents in the manifest but this is not the case of BOOT_COMPLETED one.

Neither this helped because the receiver is not called at all.

Registering broadcast intent at runtime, get it to work (on the emulator, firing the intent from adb shell), but I'm not sure it's the right way to do it:

registerReceiver(new StartDetectionAtBoot(), new IntentFilter(Intent.ACTION_BOOT_COMPLETED));

Are there any known bugs with this?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

Self-registering your receiver(s) in a code for the needed implicit intents is really the right way to start receiving that intents. No service is needed for this (in most cases, see below...). But you need to be aware of the following in order not to be confused during testing and not to break earlier implementation:

  1. Self-registering should be done once per the application run. In terms of Java / Kotlin application data: once per a static field life. So one static boolean field should allow you to know: if you need to self-register (e.g. after reboot or after Android system killed your app later...) or not (I cite working code from this commit: https://github.com/andstatus/todoagenda/commit/74ffc1495f2c4bebe5c43aab13389ea0ea821fde ):
    private static volatile boolean receiversRegistered = false;

    private static void registerReceivers(Context contextIn) {
        if (receiversRegistered) return;

        Context context = contextIn.getApplicationContext();
        EnvironmentChangedReceiver receiver = new EnvironmentChangedReceiver();

        IntentFilter providerChanged = new IntentFilter();
        providerChanged.addAction("android.intent.action.PROVIDER_CHANGED");
        providerChanged.addDataScheme("content");
        providerChanged.addDataAuthority("com.android.calendar", null);
        context.registerReceiver(receiver, providerChanged);

        IntentFilter userPresent = new IntentFilter();
        userPresent.addAction("android.intent.action.USER_PRESENT");
        context.registerReceiver(receiver, userPresent);

        Log.i(EventAppWidgetProvider.class.getName(), "Registered receivers from " + contextIn.getClass().getName());
        receiversRegistered = true;
    }
  1. Insert the call of your registerReceivers method to all possible entry points of your application in order to maximize chances that the receivers are registered even if your application was started by Android system only once, e.g.:
    @Override
    public void onUpdate(Context baseContext, AppWidgetManager appWidgetManager, int[] appWidgetIds) {
        registerReceivers(baseContext);

        ...
    }
  1. You may leave your receivers being registered to the same intents in AndroidManifest.xml file (as this works for Android before v.7 ...), but note that in this case in logcat you will still see "Background execution not allowed" with a reference to your receivers. This only means that registration via the AndroidManifest.xml doesn't work (as expected for Android 8+) but self-registered receivers should be called anyway!

  2. As I noted above, starting foreground service is generally not needed for a light widget. Moreover, a User won't like constantly seeing notification that your "widget" is running in the foreground (and thus constantly eating resources). The only case, when this may be really needed, is when Android kills your application too often and thus deletes that self-registration done after reboot. I think that making your "widget application" as light as possible (requiring as few memory and CPU resources, as possible...) is the right way to ensure that your widget app will be killed only in critical cases for your device... Maybe you should split your large app in two, making a widget sort of a launcher for the heavyweight app that needs to work from time to time...


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...