一、背景
應客戶要求，需要在開機時，拉起應用A。但因為開機時，同時被拉起的應用過多，導致Launcher在開機那一刻較為卡頓。為解決這一問題，采取了延遲拉起的做法。在開機后，延遲一定時間，由系統服務，拉起應用A。
于是乎，就出現這么個報錯：
Not allowed to start service Intent { cmp=com.xxx.xxx/.XXXXService }: app is in background
二、解決方案
方案一：系統簽名
解決這個報錯，有個較為簡單的做法，是將應用A帶上系統簽名，但考慮到應用A后續有他們自己的OTA計劃，我們不可能把系統的簽名文件給他們（涉及安全）。他們也不可能更新應用時，再針對我們的產品，交給我們簽名，再發布特定渠道的應用（流程繁甭）。因此，此方案不可取。
方案二：透明Activity
拉起應用A的透明Activity，再由應用A的透明Activity拉起服務并Finish掉Activity。 這個方案，聽起來可以，但實際操作上會存在一個問題，即在被拉起的一瞬間，用戶的操作會被打斷，出錯短暫的卡頓現象以及焦點變化。因為是延時拉起，不知道此時用戶在做什么操作，導致的后續問題也是未知的，因此，此方案也不可取。
方案三：繞過限制
基于前2種方案， 最終決定，對限制的原因，進行分析。
- 分析報錯堆棧
2024-05-20 20:27:48.742 549-1975 Activi...nager pid-549 W Background start not allowed: service Intent { cmp=com.xxx/.XXXService } to com.xxxx/.XXXService from pid=1061 uid=1000 pkg=com.xxxx.xxx startFg?=false
2024-05-20 20:27:48.743 1061-1061 XXXXHelper com...e.xxx D start XXXService failed1111 = Not allowed to start service Intent { cmp=com.xxxx/.XXXService }: app is in background uid null
2024-05-20 20:27:48.743 1061-1061 System.err com...e.xxx W android.app.BackgroundServiceStartNotAllowedException: Not allowed to start service Intent { cmp=com.xxxx/.XXXService }: app is in background uid null
2024-05-20 20:27:48.743 1061-1061 com...e.xxx W at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1908)
2024-05-20 20:27:48.743 1061-1061 com...e.xxx W at android.app.ContextImpl.startService(ContextImpl.java:1864)
2024-05-20 20:27:48.743 1061-1061 com...e.xxx W at com.xxxx.xx.XXXXHelper.startXXXXService(XXXXHelper.java:36)
2024-05-20 20:27:48.744 1061-1061 com...e.xxx W at com.xxxx.xx.XXXXHelper.delayBootApps(XXXXHelper.java:25)
2024-05-20 20:27:48.744 1061-1061 com...e.xxx W at com.xxxx.XXAppService.delayBootApps(XXAppService.java:1161)
2024-05-20 20:27:48.744 1061-1061 com...e.xxx W at com.xxxx.XXAppService.-$$Nest$mdelayBootApps(Unknown Source:0)
2024-05-
)
