Android14(U)適配攻略
1. 升級編譯環(huán)境
開發(fā)環(huán)境
準備Flamingo 或者最新Bate 版本的Android Studio 準備Android 14 的設備((https://developer.android.google.cn/about/versions/14/devices?hl=zh-cn)) gradle配置 classpath 'com.android.tools.build:gradle:8.0.0' distributionUrl=https://services.gradle.org/distributions/gradle-8.0.0-bin.zip 設置Android 14 SDK android { ? ? compileSdkPreview = "UpsideDownCake" ? ? ... ? ? defaultConfig { ? ? ? ? targetSdkPreview = "UpsideDownCake" ? ? } } 生成BuildConfig和AIDL 關聯(lián)文件 buildFeatures { buildConfig = true aidl = true } R文件傳遞 android.nonTransitiveRClass=false View的id區(qū)分時使用Switc case 使用 if()else if() 替換 switch case 或者在Gradle.properties中添加android.nonFinalResIds=false 設置命名空間:刪除Manifest下的package標簽,將包名信息添加到gradle的android路徑下 android { namespace = "com.xx.xx" } 項目中使用CompileOnly 編譯的庫需要在混淆文件中添加間接引用的類
TargetSdkVersion >=34的修改
對隱式 intent 和待處理 intent 的限制
對于以 Android 14 為目標平臺的應用,Android 會通過以下方式限制應用向內部應用組件發(fā)送隱式 intent:
- 隱式 intent 只能傳送到導出的組件。應用
必須使用顯式 intent 傳送到未導出的組件
帶包名的去跳轉,或將該組件標記為已導出。
- 如果應用通過未指定組件或軟件包的 intent 創(chuàng)建可變待處理 intent,系統(tǒng)現在會拋出異常。
這些變更可防止惡意應用攔截意在供應用內部組件使用的隱式 intent。
<activity android:name=".AppActivity" android:exported="false"> //false 不可導出 true可導出 <intent-filter> <action android:name="com.example.action.APP_ACTION" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> </activity> Intent explicitIntent =new Intent("com.example.action.APP_ACTION") //跳轉不可導出,需要設置包名 explicitIntent.setPackage(context.getPackageName()); context.startActivity(explicitIntent);
在運行時注冊的廣播接收器必須指定導出行為
在 Android 14 上,運行時通過 Context#registerReceiver()
動態(tài)注冊廣播接收器,需要設置標記 RECEIVER_EXPORTED
或 RECEIVER_NOT_EXPORTED
,標識是否導出該廣播,避免應用程序出現安全漏洞,如果注冊的是系統(tǒng)廣播,則不需要指定標記。
三方SDK兼容修改方式:
如果三方SDK適配困難可以先在Activity或者Application中復寫廣播注冊方法,如果有未添加是否可導出標記可以手動添加上
@Override public Intent registerReceiver(@Nullable BroadcastReceiver receiver, IntentFilter filter) { return registerReceiver(receiver, filter, Context.RECEIVER_EXPORTED或者Context.RECEIVER_NOT_EXPORTED); } @Override public Intent registerReceiver(@Nullable BroadcastReceiver receiver, IntentFilter filter, int flags) { Intent intent=null; try { boolean flagExported = (flags & Context.RECEIVER_EXPORTED) != 0; boolean flagNotExported = (flags & Context.RECEIVER_NOT_EXPORTED) != 0; if(!flagExported && !flagNotExported){ intent = super.registerReceiver(receiver, filter, flags|Context.RECEIVER_EXPORTED或者Context.RECEIVER_NOT_EXPORTED); return intent; } intent = super.registerReceiver(receiver, filter,flag); } catch (Throwable e) { } return intent; } 。。。。。其他多參方法補上EXPORTED 參數
安全的動態(tài)代碼加載(插件化/熱更新)
new DexClassLoad(x,x,x,)
DexFile.loadFile(x) 都會拋異常
在動態(tài)文件(例如 DEX、JAR 或 APK 文件)打開并寫入任何內容之前立即將其設為只讀,插件化、熱修復涉及ClassLoad去加載代碼的地方,如果文件有寫權限會立即報錯。
將新下載的文件屬性修改成只讀文件,如果是已存在的文件最好可以先刪除然后重新下載并且設置只讀權限。
public static void modifyFileOnlyRead(String apkPath) { if (Util.isAndroidU()) { try { File file = new File(apkPath); boolean b = file.setReadOnly(); if (file.canWrite()) { Runtime.getRuntime().exec("chmod 400 " + apkPath); } } catch (Exception e) { e.printStackTrace(); } } }
壓縮路徑遍歷
對于以 Android 14 為目標平臺的應用,Android 會通過以下方式防止 Zip 路徑遍歷漏洞:如果 Zip 文件條目名稱包含“..”或以“/”開頭,ZipFile(String)
和 ZipInputStream.getNextEntry()
會拋出 ZipException
。
應用可以通過調用 dalvik.system.ZipPathValidator.clearCallback()
選擇停用此驗證。
從后臺啟動Activity的附加限制
系統(tǒng)進一步限制了應用在后臺啟動 Activity 的時間:
- 當應用使用
PendingIntent#send()
發(fā)送PendingIntent
以及類似行為時,如果應用想要授予其自己的后臺 service 啟動權限以啟動 pending intent,則該應用現在必須選擇加入一個ActivityOptions
,具體為帶有setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
- 當一個可見應用使用
bindService()
綁定另一個在后臺運行的應用的服務時,如果該可見應用想要將其自己的后臺 activity 啟動權限授予綁定服務,則它現在必須選擇加入BIND_ALLOW_ACTIVITY_STARTS
標志。
啟動前臺服務必須設置前臺服務類型
如果有使用startForeground() 在清單文件中必須要指定服務的前臺類型,例如音頻播放類的可以使用mediaPlayback
為了幫助開發(fā)者更有目的地定義面向用戶的前臺服務,Android 10 在 <service> 元素內引入了 android:foregroundServiceType
屬性。
如果您的應用以 Android 14 為目標平臺,則必須指定適當的前臺服務類型。與以前的 Android 版本一樣,可組合使用多個類型。下面列出了可供選擇的前臺服務類型:
- camera
- connectedDevice
- dataSync
- health
- location
- mediaPlayback
- mediaProjection
- microphone
- phoneCall
- remoteMessaging
- shortService
- specialUse
- systemExempted
如果應用中的用例與這些類型均不相關,強烈建議您遷移邏輯以使用 WorkManager 或用戶發(fā)起的數據傳輸作業(yè)。
Android 14 中新增了 health, remoteMessaging, shortService, specialUse
和 systemExempted
類型。
以下代碼段提供了一個清單中的前臺服務類型聲明示例:
<manifest ...> ? <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> ? <uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" /> ? ? <application ...> ? ? ? <service ? ? ? ? ? android:name=".MyMediaPlaybackService" ? ? ? ? ? android:foregroundServiceType="mediaPlayback" ? ? ? ? ? android:exported="false"> ? ? ? </service> ? ? </application> </manifest>
如果以 Android 14 為目標平臺的應用未在清單中定義給定服務的類型,系統(tǒng)會在調用 startForeground() 時引發(fā) MissingForegroundServiceTypeException
Open JDK 17
Android 14 將繼續(xù)更新 Android 的核心庫,以與最新 OpenJDK LTS 版本中的功能保持一致,包括適合應用和平臺開發(fā)者的庫更新和 Java 17 語言支持。
以下變更可能會影響應用兼容性:
- 對正則表達式的更改:現在,為了更嚴格地遵循 OpenJDK 的語義,不允許無效的組引用。您可能會看到
java.util.regex.Matcher
類拋出IllegalArgumentException
的新情況,因此請務必測試應用中使用正則表達式的情形
。如需在測試期間啟用或停用此變更,請使用兼容性框架工具切換DISALLOW_INVALID_GROUP_REFERENCE
標志。 - UUID 處理:現在,驗證輸入參數時,
java.util.UUID.fromString()
方法會執(zhí)行更嚴格的檢查,因此您可能會在反序列化期間看到IllegalArgumentException
。如需在測試期間啟用或停用此變更,請使用兼容性框架工具切換ENABLE_STRICT_VALIDATION
標志。 - ProGuard 問題:有時,在您嘗試使用 ProGuard 縮減、混淆和優(yōu)化應用時,添加
java.lang.ClassValue
類會導致問題。問題源自 Kotlin 庫,該庫會根據Class.forName("java.lang.ClassValue")
是否會返回類更改運行時行為。如果您的應用是根據沒有java.lang.ClassValue
類的舊版運行時開發(fā)的,則這些優(yōu)化可能會將computeValue
方法從派生自java.lang.ClassValue
的類中移除。
Android 14 中有關限制非 SDK 接口的更新
非SDK API 表 (官網下載文件)
使用 Lint工具檢查
TargetSdkVersion >=33的修改
默認拒絕設定精確的鬧鐘
Android 14 開始 ,targetSdkVersion>=33的新安裝用戶 SCHEDULE_EXACT_ALARM
權限默認拒絕,在使用
setExact()
setExactAndAllowWhileIdle()
setAlarmClock()
時,APP會拋出異常,可在調用上述方法之前使用 canScheduleExactAlarms()
判斷是否有鬧鐘權限,并且設置AlarmManager.ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED
監(jiān)聽前臺廣播并對其做出正確反應 ,系統(tǒng)會在用戶授予權限時發(fā)送該廣播。
三種種方式修改:
public static void openAlarmPage(Context context){ //可定義廣播監(jiān)聽 SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED 是否開啟 Intent intent = new Intent(); intent.setAction(ACTION_REQUEST_SCHEDULE_EXACT_ALARM); context. startActivity(intent); }
Menifest申明
<uses-permission
android:name
="android.permission.USE_EXACT_ALARM" />
這個普通權限不需要運行時申請,但是需要注意隱私聲明public void start () { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) { alarmManager.setExact(xxx, xxx, "TAG", new AlarmManager.OnAlarmListener() { @Override public void onAlarm() { start(); } }, xx); } }
授予對照片和視頻的部分訪問權限
只授予所選中媒體文件的權限
針對Android 13 及以上用戶 Android 14 以上新增的權限 READ_MEDIA_VISUAL_USER_SELECTED
僅允許授予選中媒體文件的訪問權限。如需要訪問所有媒體文件需要同步申請READ_MEDIA_IMAGES
和 READ_MEDIA_VIDEO
.
TargetSdkVersion==xxx 不區(qū)分版本對所有應用的更改
TargetSdkVersion<23的應用無法在Android U上安裝
安全性,降低低版本權限問題導致APP數據泄露,升級TargetSdkVersion >=23
INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7
如果需要調試低版本Target的APP可以使用命令行安裝
adb install --bypass-low-target-sdk-block app.apk
應用進入緩存時,上下文注冊的廣播將加入隊列
應用進入緩存狀態(tài)(例如進入后臺) 上下文注冊的廣播會加入隊列,等待應用退出緩存狀態(tài)時,會一次性將多個在緩存隊列的廣播一次性發(fā)送, 存在廣播合并的情況, 例如監(jiān)聽屏幕開啟/關閉/開啟/關閉, 應用只能接受開啟-關閉 中間的狀態(tài)會丟失.,廣播也可能由于系統(tǒng)原因會從緩存隊列刪除. 此項變更讓廣播接收變得不那么靠譜,可能會導致APP資源得不到銷毀引起內存泄露
應用只能終止自己的后臺進程
從 Android 14 開始,當您的應用調用 killBackgroundProcesses()
時,該 API 只能終止您自己應用的后臺進程。(影響第三方殺進程的應用例如(360手機衛(wèi)士))
用戶可以關閉不可關閉的通知
這項變更適用于通過 Notification.Builder#setOngoing(true)
或 NotificationCompat.Builder#setOngoing(true)
設置 Notification.FLAG_ONGOING_EVENT
來阻止用戶關閉前臺通知的應用。FLAG_ONGOING_EVENT
的行為已發(fā)生變化,使用戶實際上能夠關閉此類通知。
在以下情況下,此類通知仍不可關閉:
- 當手機處于鎖定狀態(tài)時
如果用戶選擇
全部清除
通知操作
(有助于防止意外關閉)
此外,這一新行為不適用于以下用例中的不可關閉通知:
使用
MediaStyle
創(chuàng)建的通知(notification.setStyle(ew NotificationCompat.MediaStyle()))安全和隱私用例的政策限制使用
企業(yè)設備政策控制器 (DPC) 和支持軟件包
新增、改善功能
截屏監(jiān)聽
添加權限: 可以監(jiān)聽截屏但是截屏文件還需要使用常規(guī)方法自己獲取
<uses-permission android:name="android.permission.DETECT_SCREEN_CAPTURE" /> final Activity.ScreenCaptureCallback screenCaptureCallback = new Activity.ScreenCaptureCallback() { @Override public void onScreenCaptured() { // Add logic to take action in your app. } }; @Override protected void onStart() { super.onStart(); // Pass in the callback created in the previous step // and the intended callback executor (e.g. Activity s mainExecutor). registerScreenCaptureCallback(executor, screenCaptureCallback); } @Override protected void onStop() { super.onStop(); unregisterScreenCaptureCallback(screenCaptureCallback); }
禁止當前ACtivity截屏可以添加下面的flag
activity.getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
Path 路徑可查詢過程中的點位信息
Android 的 Path
API 是一種強大且靈活的機制,可用于創(chuàng)建和渲染矢量圖形,能夠描邊或填充路徑,根據線段、二次曲線或立方曲線構建路徑,執(zhí)行布爾運算以獲取更復雜的形狀,或同時執(zhí)行所有這些操作。但是無法了解 Path 對象中實際包含的內容;該對象的內部信息在創(chuàng)建后對于調用方是不透明的。
如需創(chuàng)建 Path
,可以調用 moveTo()
、lineTo()
和 cubicTo()
等方法來添加路徑片段。但無法詢問該路徑有哪些片段,因此必須在創(chuàng)建時保留該信息。
從 Android 14 開始,可以查詢路徑以了解其內部內容。首先,需要使用 Path.getPathIterator
API 獲取 PathIterator
對象:
Path path = new Path();path.moveTo(1.0F, 1.0F); path.lineTo(2.0F, 2.0F);path.close(); PathIterator pathIterator = path.getPathIterator();
接下來,可以調用 PathIterator
逐個遍歷片段,并檢索每個片段的所有必要數據。以下示例使用了 PathIterator.Segment
對象,它會打包數據
while (pathIterator.hasNext()) { PathIterator.Segment segment = pathIterator.next(); Log.i(LOG_TAG, "segment: " + segment.getVerb() + ", " + segment.getPoints());}
PathIterator
還有一個非分配版 next()
,可以在其中傳入緩沖區(qū)來保存點數據。
查詢 Path
數據的一個重要用例是插值。例如,大家可能想在兩個不同的路徑之間添加動畫(或變形)。為了進一步簡化該用例,Android 14 針對 Path
還有一個新的 interpolate()
方法。假設兩個路徑具有相同的內部結構,interpolate()
方法會使用該插值結果創(chuàng)建一個新的 Path
。以下示例返回了一個形狀介于 path
和 otherPath
之間的一半(線性插值為 0.5)的路徑:
Path interpolatedResult = new Path(); if (path.isInterpolatable(otherPath)) { path.interpolate(otherPath, 0.5F, interpolatedResult); }
單應用語言偏好/語法優(yōu)化/地區(qū)偏好
功能和 API 概覽 | Android 開發(fā)者 | Android Developers (google.cn)
位置權限新增標簽描述
權限彈窗是會顯示描述信息,需要在清單文件中添加
在應用的資源目錄/etc/ASL/asl-locations.xml新增配置, <ASL-locations> <ASL package="com.xx.xx">【Path to ASL XML} </ASL> </ASL-locations>
新增用戶初始化Job權限RUN_USER_INITIATED_JOBS
Android 14 引入了android.permision.RUN_USER_INITIATED_JOBS權限,允許一個應用執(zhí)行用戶初始化Job權限,此權限可以被用手動關閉或者被系統(tǒng)撤銷,應用需要targestsdk升級到U后來請求此權限
新增喚醒屏幕權限
Android 14 引入了android.permision.TURN_SCREEN_ON權限,目標平臺為Android 14及以上的應用使用喚醒屏幕時,需要在AndroidManifest文件中配置這個權限。另外喚醒屏幕權限有一個對應的appops權限AppOpsManager.OP_TURN_SCREEN_ON,這個權限在Android T上是默認開啟,在Android U上對目標平臺為Android 14及以上的應用默認關閉。
不申請權限調用下面API 沒有效果無法喚醒屏幕
PowerManager powerManager = (PowerManager) Context.getSystemService( Context.POWER_SERVICE); PowerManager.WakeLock wakeLock = powerManager.newWakeLock( PowerManager.SCREEN_BRIGHT_WAKE_LOCK | PowerManager.ACQUIRE_CAUSES_WAKEUP, "testName"); wakeLock.acquire(3000)
字體放大可以到200%
功能和 API 概覽 | Android 開發(fā)者 | Android Developers (google.cn)
到此這篇關于Android14(U)適配攻略的文章就介紹到這了,更多相關Android14(U)適配攻略內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
Android開發(fā)中Looper.prepare()和Looper.loop()
Looper用于封裝了android線程中的消息循環(huán),默認情況下一個線程是不存在消息循環(huán)(message loop)的,具體調用方法大家可以通過本文學習2016-11-11