首先我這邊遇到的問(wèn)題是插電后workmanager（間隔15分鐘）也不運(yùn)行，后來(lái)發(fā)現(xiàn)是APP被設(shè)為限制后臺(tái)運(yùn)行或者Autorun被關(guān)掉了

1. 搜索發(fā)現(xiàn)下面這個(gè)方法可以判斷當(dāng)前是否限制后臺(tái)運(yùn)行：??！API level 28
isBackgroundRestricted Added in API level 28
當(dāng)處于這個(gè)模式下，即便應(yīng)用充電也不行，除非前臺(tái)在運(yùn)行

Query whether the user has enabled background restrictions for this app.
The user may chose to do this, if they see that an app is consuming an unreasonable amount of battery while in the background.
If true, any work that the app tries to do will be aggressively restricted while it is in the background. At a minimum, jobs and alarms will not execute and foreground services cannot 【be started 】unless an app activity is in the foreground.

**Note that these restrictions stay in effect even when the device is charging.**

| Returns |
| `boolean` | true if user has enforced background restrictions for this app, false otherwise. |

2. 關(guān)于打開(kāi)控制APP后臺(tái)限制的設(shè)置頁(yè)面的搜索：

Open Background Restriction in settings
"Background Restriction" (or "Allow Background Activity" on some devices) is intended to stop ALL background activity regardless of whether your service has called setForeground()
There is no way around this setting. You cannot programmatically disable it. Your only option is to programmatically check if it's enabled using ActivityManager.isBackgroundRestricted() and display a pop-up informing your users on how to disable this setting
Google's Universal Music Player sample project on GitHub happens to work (as of the writing of this answer) only because a service bind is not released when the main Activity is paused. The sample project's service is however killed when the main Activity is garbage collected (typically 30-45 minutes depending on the device).

所以可以文字提示并引導(dǎo)到自己應(yīng)用的設(shè)置頁(yè)面
Intent intent=new Intent(android.provider.Settings.ACTION_APPLICATION_DETAILS_SETTINGS,  Uri.fromParts("package", getPackageName(), null))
startActivity(intent);

3. 嘗試搜索后的另外一條路： 忽略電源管理

首先要說(shuō)一下由于Android 系統(tǒng)UI的定制化嚴(yán)重，所以很多設(shè)備不能很好地匹配UI，或者
設(shè)置成功后無(wú)法取消，但三星的設(shè)備表現(xiàn)還是中規(guī)中矩的。

https://stackoverflow.com/posts/48859802/timeline

This is part of the new App Standby（應(yīng)用待機(jī)） feature introduced with API 23 (Marshmallow) alongside Doze Battery Optimization aimed to optimize power and resource usage while the app is in background (App Standby) or when the device has long been in sleep (Doze).

Following is the explanation from the Android Developer's site page:

Specifically, in the App Standby mode, the system determines that an app is idle when the user is not actively using it. The system makes this determination when the user does not touch the app for a certain period of time and none of the following conditions applies:

• The user explicitly launches the app.
• The app has a process currently in the foreground (either as an activity or foreground service, or in use by another activity or foreground service).
• The app generates a notification that users see on the lock screen or in the notification tray.
• The app is an active device admin app (for example, a device policy controller). Although they generally run in the background, device admin apps never enter App Standby because they must remain available to receive policy from a server at any time.

When the user plugs the device into a power supply, the system releases apps from the standby state, allowing them to freely access the network and to execute any pending jobs and syncs. If the device is idle for long periods of time, the system allows idle apps network access around once a day.

So, this means that starting from API 23 (Marshmallow), the device may actively put your app on standby, preventing network access (say for task like sync) and limiting (or disabling) background executions. Now, for most of the apps this behavior is fine or you could easily optimize for such behavior, but for some apps out there this may cause some unexpected behavior, especially for apps that have been poorly optimized or use non-standard sync strategies or some other means of background sync/execution. So to circumvent that, the user can explicitly mark the app as non-optimized and the system will fallback and not put the app to standby, although this leads to a poorer user experience and you should not be doing this for regular apps that could be optimized.

resolvent

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
            String packageName = context.getPackageName();
            PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
            Intent intent = new Intent();
            if (!pm.isIgnoringBatteryOptimizations(packageName)) {
              
                intent.setAction(android.provider.Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
                intent.setFlags(FLAG_ACTIVITY_NEW_TASK);
                intent.setData(Uri.parse("package:" + packageName));
              
            }else{
                intent.setAction(Settings.ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS); //BATTERY_SAVER_SETTINGS
            }
            context.startActivity(intent);
        }

Also, you need to add the following permission in manifest

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