前言
8月16日，谷歌宣布Android13新系統(tǒng)的源代碼已經(jīng)上傳到Android開源項(xiàng)目（AOSP）中，Android13正式發(fā)布。自從2022年2月Android13第一個預(yù)覽版上線以來，歷經(jīng)7個月的測試和優(yōu)化，正式版本的Android13終于來了！Android13仍然聚焦個人隱私保護(hù)和安全，并提供了萬物互聯(lián)時(shí)代下大小屏適配、電池利用率優(yōu)化等相關(guān)的技術(shù)開發(fā)能力。感興趣的開發(fā)者可以登錄官網(wǎng)下載源碼測試學(xué)習(xí)
個推服務(wù)開發(fā)者多年，一直密切關(guān)注和跟進(jìn)行業(yè)發(fā)展趨勢。Android13正式版發(fā)布后，我們使用模擬器進(jìn)行了研究和適配測試。本文將從權(quán)限變更、系統(tǒng)優(yōu)化、功能更新等方面來談?wù)凙ndroid13新特性，以幫助開發(fā)者快速上手完成Android新系統(tǒng)的適配。
權(quán)限變更
一、通知權(quán)限
通知欄消息一直是App和用戶溝通的有效渠道。在Android13之前，App只需要使用NotificationManager即可向終端用戶推送通知欄消息。Android13則引入了新的運(yùn)行時(shí)通知權(quán)限：POST_NOTIFICATIONS。對此，App開發(fā)者需要予以重點(diǎn)關(guān)注。
個推對該權(quán)限進(jìn)行了測試，總結(jié)如下：
1. 首先看TargetSdk< 33的情況。
如下圖，當(dāng)App使用通知欄功能時(shí)，系統(tǒng)將自動彈出授權(quán)彈窗：
用戶點(diǎn)擊"允許"，App可正常給用戶推送消息：
2. 再看TargetSdk == 33的情況。
開發(fā)者需要在AndroidManifest.xml中聲明POST_NOTIFICATIONS權(quán)限，還需要在使用通知欄推送功能時(shí)在代碼中申請運(yùn)行時(shí)權(quán)限：
requestPermissions(new String[]{"android.permission.POST_NOTIFICATIONS"})
以上是用戶點(diǎn)擊"允許"App推送的情況。當(dāng)然，用戶也有可能點(diǎn)擊"不允許"。值得注意的是，一旦被用戶拒絕授權(quán)，下次系統(tǒng)將不會再出現(xiàn)權(quán)限申請的彈窗。
如果App仍然要推送重要消息（比如重大版本更新）給用戶，則需要引導(dǎo)用戶前往設(shè)置界面打開通知權(quán)限。代碼如下：
privatevoidjumpNotificationSetting() { final ApplicationInfo applicationInfo = getApplicationInfo(); try { Intent intent = new Intent(); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); intent.setAction("android.settings.APP_NOTIFICATION_SETTINGS"); intent.putExtra("app_package", applicationInfo.packageName); intent.putExtra("android.provider.extra.APP_PACKAGE", applicationInfo.packageName); intent.putExtra("app_uid", applicationInfo.uid); startActivity(intent); } catch (Throwable t) { t.printStackTrace(); Intent intent = new Intent(); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); intent.setAction("android.settings.APPLICATION_DETAILS_SETTINGS"); intent.setData(Uri.fromParts("package", applicationInfo.packageName, null)); startActivity(intent); }}
★溫馨提示：
如果App要確認(rèn)用戶是否已啟用通知，可以調(diào)用NotificationManager.areNotificationsEnabled()進(jìn)行判斷。
另外，除了"允許"和"不允許"兩種選擇外，用戶還可以劃走權(quán)限申請對話框（User swipes away from dialog），即用戶未選擇授權(quán)（也未選擇不授權(quán)）。那么下次App進(jìn)行通知欄消息推送時(shí)，系統(tǒng)將再次彈出用戶授權(quán)彈窗。
二、WiFi權(quán)限變更
Android13對WiFi權(quán)限的變更也是一大重點(diǎn)。在萬物互聯(lián)的當(dāng)下，不同的智能家居/智能穿戴設(shè)備多是通過WiFi互通互聯(lián)，因此這些類型的App開發(fā)者更要著重關(guān)注該部分內(nèi)容。
在以往版本的Android系統(tǒng)下，如果App要使用WiFi相關(guān)功能，需要申請 ACCESS_FINE_LOCATION，即位置權(quán)限，如下圖：
▲圖片來源于Android13官網(wǎng)
為了避免App過度索權(quán)，更好地保護(hù)終端用戶隱私，Android13將WiFi權(quán)限從位置權(quán)限中分離了出來，引入了新的運(yùn)行時(shí)權(quán)限：NEARBY_WIFI_DEVICES。
如果App僅需要使用WiFi相關(guān)的API，并不需要使用getScanResults()、startScan()等與位置相關(guān)的API，那么建議App開發(fā)者切換到新的NEARBY_WIFI_DEVICES權(quán)限。
新的WiFi權(quán)限運(yùn)行機(jī)制：
▲圖片來源于Android13官網(wǎng)
權(quán)限使用和適配：
開發(fā)者需要注意的是，如果你的應(yīng)用（targetSdk == 33）已經(jīng)聲明不會根據(jù) WiFi信息推導(dǎo)設(shè)備的物理位置信息，那就不再需要聲明 ACCESS_FINE_LOCATION 權(quán)限。
另外，如果應(yīng)用在Android13上只使用WiFi API而不使用位置信息，那開發(fā)者可以在AndroidManifest.xml中增加NEARBY_WIFI_DEVICES權(quán)限，并將usesPermissionFlags屬性設(shè)為neverForLocation，給ACCESS_FINE_LOCATION權(quán)限增加maxSdkVersion="32"的限制，代碼如下：
三、更細(xì)分的媒體權(quán)限
除了通知權(quán)限和WiFi權(quán)限的更新外，Android13對本地?cái)?shù)據(jù)訪問權(quán)限也做了進(jìn)一步細(xì)化。
Android13將READ_EXTERNAL_STORAGE和 WRITE_EXTERNAL_STORAGE權(quán)限細(xì)分為：READ_MEDIA_IMAGES、 READ_MEDIA_VIDEO和 READ_MEDIA_AUDIO，如下圖：
▲圖片來源于Android13官網(wǎng)
個推使用android.permission.READ.MEDIA_IMAGES，對新權(quán)限進(jìn)行了測試：
我們發(fā)現(xiàn)，單獨(dú)請求READ_MEDIA_IMAGES、單獨(dú)請求 READ_MEDIA_VIDEO和同時(shí)請求READ_MEDIA_IMAGES& READ_MEDIA_VIDEO，系統(tǒng)均將只顯示一個授權(quán)彈窗。
另外，如果App（targetSdk == 33）已經(jīng)申請了讀的權(quán)限，那App同時(shí)也就有了寫的權(quán)限，無需再額外聲明 WRITE_EXTERNAL_STORAGE權(quán)限，代碼如下：
四、精確的鬧鐘權(quán)限
為了節(jié)省系統(tǒng)資源，Android12引入了SCHEDULE_EXACT_ALARM權(quán)限進(jìn)行"鬧鐘和提醒"功能的授權(quán)管理。Android13則又引入了新的鬧鐘權(quán)限USE_EXACT_ALARM。
和Android12的SCHEDULE_EXACT_ALARM權(quán)限不同，如果App已經(jīng)申請使用了USE_EXACT_ALARM新權(quán)限，那么用戶是不能在設(shè)置頁面里關(guān)閉授權(quán)的。
對于日程管理、時(shí)間管理等類型的App來講，Android13引入的USE_EXACT_ALARM權(quán)限能夠帶來一定便利。相比Android12的SCHEDULE_EXACT_ALARM權(quán)限，使用新權(quán)限的應(yīng)用將不再需要頻繁打擾用戶進(jìn)行授權(quán)，能夠更高效地為用戶提供鬧鐘、日程提醒等服務(wù)。
不過，為了防止新權(quán)限被濫用，GooglePlay設(shè)置了嚴(yán)格的上架審核機(jī)制。開發(fā)者要注意，一旦使用了USE_EXACT_ALARM權(quán)限，App在上架GooglePlay時(shí)將會被平臺嚴(yán)格審查。除非App屬于鬧鐘、計(jì)時(shí)器、日歷等類型的應(yīng)用或者在已被列入到應(yīng)用市場的白名單里，否則GooglePlay將不會允許使用該權(quán)限的應(yīng)用上架。
五、后臺的傳感器權(quán)限
如今生物信息安全也是大眾關(guān)注的焦點(diǎn)。為了更好地保護(hù)終端用戶的個人生物信息，Android13增加了新的后臺傳感器權(quán)限。
App在后臺運(yùn)行時(shí)，如果需要獲取心率、體溫、血氧飽和度等傳感器信息，將不僅需要向用戶申請現(xiàn)有的BODY_SENSORS權(quán)限，還必須聲明新的BODY_SENSORS_BACKGROUND權(quán)限。
綜上可以看到，Android13對個人隱私保護(hù)的重視和加強(qiáng)。除了權(quán)限變更方面，Android13還進(jìn)行了系統(tǒng)優(yōu)化、組件更新，以進(jìn)一步提升系統(tǒng)的安全性和友好性。
系統(tǒng)優(yōu)化
一、更安全的系統(tǒng)組件
IntentFilter
在之前版本的Android系統(tǒng)中，開發(fā)者只需將android:exported設(shè)為true就可以跨應(yīng)用顯式啟動Activity和Service，即使intent-filter中的action或者type不匹配，也能夠啟動。
為避免上述漏洞，Android 13增強(qiáng)了intent-filter的匹配過濾邏輯。在接收方的targetSdk == 33的情況下，如果intent-filter匹配命中，無論發(fā)送方的targetSdk版本如何，intent都將生效。
★溫馨提示：
以下幾種情況不需要遵循intent-filter的匹配過濾邏輯：
組件沒有聲明
同一個App里的intent
系統(tǒng)或Root進(jìn)程發(fā)出的intent
BroadcastReceiver
以往的Android系統(tǒng)下，應(yīng)用動態(tài)注冊的BroadcastReceiver廣播接收器會接收到任何應(yīng)用發(fā)送的廣播（除非該接收器使用了應(yīng)用簽名權(quán)限保護(hù)），這會使動態(tài)注冊的廣播接收器存在安全風(fēng)險(xiǎn)。
Android13要求，應(yīng)用動態(tài)注冊的廣播接收器必須以顯著的方式指出是否允許其他應(yīng)用訪問，即其他應(yīng)用是否可以向其發(fā)送廣播。否則，在動態(tài)注冊時(shí)系統(tǒng)將拋出安全異常（SecurityException）。
目前該增強(qiáng)措施并非默認(rèn)生效，開發(fā)者需啟用 DYNAMIC_RECEIVER_EXPLICIT_EXPORT_REQUIRED兼容性框架，并在動態(tài)注冊廣播時(shí)指定是否接受其他應(yīng)用的廣播：
context.registerReceiver(receiver, intentFilter, RECEIVER_EXPORTED)context.registerReceiver(receiver, intentFilter, RECEIVER_NOT_EXPORTED)
★溫馨提示：
系統(tǒng)廣播不受RECEIVER_NOT_EXPORTED影響。
二、前臺服務(wù)(FGS)任務(wù)管理器
Android13還新增了前臺服務(wù)（FGS）任務(wù)管理器功能。
如下圖，用戶可以在下拉的通知欄中直接關(guān)閉前臺服務(wù)和應(yīng)用程序：
此外，如果系統(tǒng)檢測到應(yīng)用長時(shí)間運(yùn)行某項(xiàng)前臺服務(wù)（在24小時(shí)的時(shí)間段內(nèi)至少運(yùn)行20小時(shí)），便會向用戶發(fā)送提醒通知，通知內(nèi)容如下：
APP is running in the background for a long time. Tap to review.
值得注意的是，滿足以下任一條件的情況下，系統(tǒng)均將不會顯示該通知：
已經(jīng)發(fā)送過前臺服務(wù)相關(guān)的通知，也就是說，用戶未關(guān)閉之前的提醒通知
前臺服務(wù)的類型為 FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK 或 FOREGROUND_SERVICE_TYPE_LOCATION
★溫馨提示：
如果系統(tǒng)針對某應(yīng)用已經(jīng)顯示過此通知，那至少在30天后系統(tǒng)才會再次顯示該通知。另外，系統(tǒng)級應(yīng)用、安全應(yīng)用（比如具有android.app.role.EMERGENCY 角色的應(yīng)用）等運(yùn)行的前臺服務(wù)，將不會顯示在FGS任務(wù)管理器中。
三、通知權(quán)限
Android9引入了應(yīng)用待機(jī)存儲分區(qū)功能，根據(jù)應(yīng)用的使用時(shí)間和頻率，將應(yīng)用動態(tài)分配到五個不同優(yōu)先級的存儲分區(qū)，然后對不同存儲分區(qū)的應(yīng)用施加不同級別的應(yīng)用資源限制。
如下，存儲分區(qū)按照優(yōu)先級從高到低排序，優(yōu)先級越低對該分區(qū)內(nèi)的App限制越多：
活躍：應(yīng)用目前正在使用中，或者最近剛剛使用過。
工作集：應(yīng)用會定期使用。
常用：應(yīng)用會經(jīng)常使用，但不會每天使用。
極少使用：應(yīng)用不經(jīng)常使用。
受限：應(yīng)用會消耗大量的系統(tǒng)資源，或表現(xiàn)出不良行為（Android11引入）。
其中"受限"狀態(tài)的應(yīng)用，將受到以下限制：
無法啟動前臺服務(wù)。
現(xiàn)有的前臺服務(wù)會從前臺移除。
不會觸發(fā)鬧鐘。
不會執(zhí)行Jobs。
在Android9應(yīng)用待機(jī)存儲分區(qū)功能的基礎(chǔ)上，Android13對電池資源策略進(jìn)行了優(yōu)化，以延長設(shè)備的電池續(xù)航時(shí)間，提升終端用戶的體驗(yàn)。
首先，Android13新增了以下規(guī)則，符合相應(yīng)規(guī)則的應(yīng)用將進(jìn)入到"受限"存儲分區(qū)（設(shè)備處于關(guān)閉狀態(tài)的時(shí)間不會計(jì)入互動限制）：
用戶已經(jīng)8天沒有與應(yīng)用互動。
應(yīng)用在1天內(nèi)調(diào)用過多的廣播或者綁定服務(wù)。
應(yīng)用在1天內(nèi)消耗了大量的電池電量，閾值取決于設(shè)備。
其次，Android13還對"受限"存儲分區(qū)的應(yīng)用增加了限制措施：
應(yīng)用將不收受到BOOT_COMPLETED、LOCKED_BOOT_COMPLETED廣播
四、對non-SDK接口限制的更新
Android 13對一些non-SDK接口進(jìn)行了限制（并針對部分限制提供了替代方案）。開發(fā)者需要明確App在升級時(shí)是否使用了受限的non-SDK接口。
Android13中受限的non-SDK接口參考：
Landroid/app/Activity;->setDisablePreviewScreenshots(Z)V # Use setRecentsScreenshotEnabled() instead.Landroid/os/PowerManager;->isLightDeviceIdleMode()Z # Use isDeviceLightIdleMode() instead.Landroid/os/Process;->setArgV0(Ljava/lang/String;)V # In general, do not try to change the process name. If you must change the process name (for instance, for debugging), you can use pthread_setname_np() instead, though be aware that doing this might confuse the system.Landroid/view/accessibility/AccessibilityInteractionClient;->clearCache(I)V # Use android.accessibilityservice.AccessibilityService#clearCache() instead.
功能更新
用戶體驗(yàn)的提升也一直是Android系統(tǒng)更新的重點(diǎn)。Android13主要針對剪切板、大小屏適配、UI展示等進(jìn)行了功能更新。
一、剪切板
首先來看剪貼板。相信大家都使用過剪貼板，它能夠快速復(fù)制頁面上的內(nèi)容，方便我們進(jìn)行內(nèi)容編輯和修改。
但是一直以來，剪切板功能存在這樣一個隱患，即剪切板復(fù)制的內(nèi)容中可能存在敏感信息。為了更好地保障剪切板中的隱私內(nèi)容（比如手機(jī)號碼、郵箱、賬號密碼等）不被泄露，Android13對剪切板功能進(jìn)行了更新。
如下圖，Android13剪切板功能的使用分2步：
確認(rèn)內(nèi)容已成功復(fù)制。
提供所復(fù)制內(nèi)容的預(yù)覽。
此外，Android13還提供了脫敏功能，使用戶能夠?qū)羟邪逯械拿舾行畔⑦M(jìn)行隱藏，實(shí)現(xiàn)了便利性和安全性兼得。
二、更好地支持平板和大屏幕
平板電腦、車載大屏、智能電視屏等的廣泛應(yīng)用，使用戶的終端場景越來越多樣化。如何給不同終端的用戶始終美觀和流暢的體驗(yàn)？Android13對此提供了更好的支持，對大屏上的系統(tǒng)UI以及分屏展示等進(jìn)行了更新。
如下圖，在大屏幕上，Android13支持不同的功能模塊同屏展示，使得大屏幕的優(yōu)勢能夠充分被利用。
▲Android13系統(tǒng)下，用戶可以將"快速設(shè)置"版塊和"通知欄"版塊置于同屏當(dāng)中。
三、Jetpack WindowManager
另外，Android13還支持用戶在大屏幕中一次顯示多個Activity，以充分利用大屏的顯示空間。
開發(fā)者可通過創(chuàng)建XML配置文件或進(jìn)行Jetpack WindowManager API調(diào)用來確定App實(shí)現(xiàn)多個Activity同屏顯示（比如并排或堆疊）的具體方式。
▲比如，以分割任務(wù)窗口（splite task window）的形式實(shí)現(xiàn)單個屏幕內(nèi)展示兩個Activity。
四、更好的兼容性支持
對于尚未適配大屏幕的App，Android13也提供了更加友好和穩(wěn)定的兼容支持，讓這些App在默認(rèn)情況下也能有舒適美觀的UI展示，不會影響到終端用戶的體驗(yàn)，如下圖：
▲圖片來源于Android13官網(wǎng)
總結(jié)
通過近兩年的Android系統(tǒng)更新可以看到，Google不再對安卓系統(tǒng)進(jìn)行大刀闊斧的改動，而是在用戶體驗(yàn)、隱私保護(hù)、系統(tǒng)安全、組件優(yōu)化等方面下足了功夫。
更多Android13的更新要點(diǎn)，開發(fā)者可進(jìn)入Android13官網(wǎng)做進(jìn)一步了解
如果您還想就新系統(tǒng)適配以及安卓開發(fā)等內(nèi)容進(jìn)行更深入的交流，歡迎添加@個推技術(shù)支持，和我們聯(lián)系。后續(xù)，個推還將持續(xù)關(guān)注安卓系統(tǒng)和行業(yè)發(fā)展動態(tài)，和開發(fā)者們一起交流移動開發(fā)技術(shù)，共建移動互聯(lián)網(wǎng)新生態(tài)。
