android 8.0在系統(tǒng)性能和安全性上做了一些優(yōu)化乐疆，而這些API上的改動(dòng)荞怒，對(duì)我們軟件也帶來一部分影響蹬铺，下面簡(jiǎn)要說明一些我的軟件測(cè)試和適配
一、Android 8.0遇到的問題
1. 線程中斷：
- 描述:軟件中一個(gè)長(zhǎng)期掛載執(zhí)行的命令輪詢線程频蛔，中斷了，
- 原因：Android 8.0判斷軟件未活躍狀態(tài)秦叛，是否軟件持有的所有Wake Lock晦溪，恰巧線程中調(diào)用的Lock.wait，同步鎖挣跋，被系統(tǒng)喚醒后三圆，線程結(jié)束
- 處理：增加運(yùn)行標(biāo)簽，重新啟動(dòng)線程機(jī)制避咆，增加sleep機(jī)制
2. invalid pthread_t 0x2243df2546 passed to libc
- 描述: 在JNI運(yùn)行中報(bào)錯(cuò)舟肉，invalid pthread_t passed to libc，查看代碼發(fā)現(xiàn)牌借，在調(diào)用pthread_join()方法時(shí)報(bào)錯(cuò)
- 原因：
- 檢測(cè)到線程隊(duì)列指針為空的情況下還去調(diào)用分離線程會(huì)出現(xiàn)異常,在pthread_join中會(huì)調(diào)用__pthread_internal_find度气，https://github.com/aosp-mirror/platform_bionic/blob/master/libc/bionic/pthread_join.cpp
- 在__pthread_internal_find方法時(shí)https://github.com/aosp-mirror/platform_bionic/blob/master/libc/bionic/pthread_internal.cpp
image
- 處理：經(jīng)檢測(cè)發(fā)現(xiàn)，由于c++代碼中不嚴(yán)謹(jǐn)?shù)膶懛▽?dǎo)致了該問題膨报，未啟動(dòng)線程（未傳入線程指針）前磷籍，調(diào)用了pthread_join的方法，在以前的版本中现柠，軟件沒有崩潰院领，所以沒有檢測(cè)到，修改后無問題
二够吩、改動(dòng)：（這一切都是基于targetApi=26）
在新版的gradle要求中比然，軟件在2018年底google市場(chǎng)強(qiáng)制要求，軟件targetApi=26周循，一些簡(jiǎn)單的代碼改動(dòng)强法，如依賴包寫法等万俗，不提
-
后臺(tái)執(zhí)行限制：這一點(diǎn)很重要，android 8.0為了提高電池續(xù)航能力饮怯，增加機(jī)制如下
當(dāng)應(yīng)用沒有任何活躍的組件而進(jìn)入到緩存狀態(tài)時(shí)闰歪，系統(tǒng)將會(huì)釋放所有應(yīng)用所持有的Wake Lock
后臺(tái)應(yīng)用訪問后臺(tái)服務(wù)自由度降低
應(yīng)用不能用manifests注冊(cè)隱式廣播
-
部分注意點(diǎn)：
- targetApi=26的應(yīng)用，在沒有創(chuàng)建后臺(tái)服務(wù)的權(quán)限時(shí)調(diào)用startService()會(huì)拋出異常IllegalStateException
- 新方法Context.startForegroundService()會(huì)開啟一個(gè)前臺(tái)服務(wù)蓖墅。后臺(tái)應(yīng)用也可以調(diào)用這個(gè)方法库倘，但是在服務(wù)創(chuàng)建之后5秒鐘之內(nèi)必須調(diào)用startForeground()
-
位置更新頻率限制：受影響API：
- Fused Location Provider (FLP)
- Geofencing
- GNSS Measurements
- Location Manager
- Wi-Fi Manager
-
安全性
- 不再支持SSLv3
- 當(dāng)對(duì)一個(gè)服務(wù)器建立HTTPS連接時(shí)，如果服務(wù)器沒有正確實(shí)現(xiàn)TSL協(xié)議版本论矾，HttpsURLConnection不再回退到之前版本再次嘗試
- 安卓8.0對(duì)所有應(yīng)用程序都使用了SECCOMP過濾器教翩，限制了可以使用的syscall為bionic暴露的syscall。盡管由于后向兼容的原因贪壳，還有其他可以使用的syscall饱亿，但安卓強(qiáng)烈反對(duì)開發(fā)者使用這些syscall
- Webview對(duì)象運(yùn)行在多進(jìn)程模式。為了提供更好的安全性寥袭，網(wǎng)頁(yè)內(nèi)容會(huì)在一個(gè)應(yīng)用進(jìn)程外的獨(dú)立進(jìn)程處理
- APK不一定在以“-1”或者“-2”結(jié)尾的文件夾中路捧。應(yīng)用應(yīng)該使用sourceDir獲得路徑，不應(yīng)該直接使用文件夾的格式
-
隱私性
- 對(duì)于升級(jí)到8.0之前安裝的應(yīng)用传黄，ANDROID_ID會(huì)保持不變杰扫。如果卸載后重新安裝的話，ANDROID_ID將會(huì)改變膘掰。如果想保存卸載之前的ANDROID_ID的值章姓，可以使用Key/Value Backup將老值和新值關(guān)聯(lián)起來。
- 對(duì)于安裝在8.0系統(tǒng)的應(yīng)用來說识埋，ANDROID_ID根據(jù)應(yīng)用簽名和用戶的不同而不同凡伊。ANDROID_ID唯一決定于應(yīng)用簽名、用戶和設(shè)備三者的組合窒舟。
- 只要應(yīng)用簽名不變系忙，卸載再安裝應(yīng)用不會(huì)改變ANDROID_ID
- 有Google Play服務(wù)的設(shè)備可以使用Advertising ID，其他設(shè)備應(yīng)該繼續(xù)使用ANDROID_ID
- 訪問net.hostname會(huì)返回null
-
內(nèi)容改變通知
- 安卓8.0改變了ContentResolver.notifyChange(Uri, ContentObserver)和registerContentObserver(Uri, boolean, ContentObserver)的行為惠豺。這些接口要求Uri中的authority背后真實(shí)定義了一個(gè)有效的ContentProvider银还。
-
權(quán)限
- 應(yīng)用將只被授予其申請(qǐng)的權(quán)限。但是洁墙，如果應(yīng)用之后再申請(qǐng)同一權(quán)限組中的其他權(quán)限時(shí)蛹疯，將自動(dòng)被授予
例如，應(yīng)用在Manifest里同時(shí)注冊(cè)了READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAG兩個(gè)權(quán)限热监。在targetApi=25或之前的版本中捺弦，當(dāng)應(yīng)用請(qǐng)求READ_EXTERNAL_STORAGE權(quán)限并且用戶授權(quán)了之后，
系統(tǒng)會(huì)自動(dòng)授予WRITE_EXTERNAL_STORAG權(quán)限，因?yàn)镽EAD_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAG同屬STORAGE權(quán)限組其都在manifest里注冊(cè)了列吼。但在安卓8.0系統(tǒng)中幽崩，只有READ_EXTERNAL_STORAGE會(huì)被授權(quán)，但是當(dāng)應(yīng)用再次申請(qǐng)WRITE_EXTERNAL_STORAG權(quán)限時(shí)寞钥，系統(tǒng)會(huì)不提示用戶直接授權(quán)歉铝。
-
類加載
- 系統(tǒng)會(huì)檢查類加載器返回的類描述符是否匹配期望的類描述符，如果描述符不匹配凑耻，系統(tǒng)會(huì)拋出NoClassDefFoundError錯(cuò)誤，并且會(huì)在異常中記錄詳細(xì)信息柠贤。
- 系統(tǒng)還會(huì)檢查描述符是否有效香浩。這個(gè)檢查會(huì)捕獲由于JNI調(diào)用間接加載類的方法（如GetFieldID()）中無效的描述符引起的錯(cuò)誤。例如臼勉，簽名中java/lang/String的字段是無法找到邻吭，因?yàn)檫@不是一個(gè)有效的簽名。正確的簽名應(yīng)該為L(zhǎng)java/lang/String;宴霸。
- DexFile API已經(jīng)被廢棄了囱晴，強(qiáng)烈建議開發(fā)者使用包括PathClassLoader和BaseDexClassLoader在內(nèi)的系統(tǒng)類加載器。
