Android 14 变更及适配攻略

准备工作

首先将我们项目中的 targetSdkVersion和compileSdkVersion 升至 34。
影响Android 14上所有应用

1.最低可安装的目标 API 级别

   从 Android 14 开始，targetSdkVersion 低于 23 的应用无法安装。要求应用满足这些最低目标 API 级别要求有助于提高用户的安全性和隐私性。
  恶意软件通常会以较旧的 API 级别为目标平台，以绕过在较新版本 Android 中引入的安全和隐私掩护机制。比方，有些恶意软件应用利用 targetSdkVersion 22，以避免受到 Android 6.0 Marshmallow（API 级别 23）在 2015 年引入的运行时权限的约束。这项 Android 14 变更使恶意软件更难以规避安全和隐私权方面的改进限制。
注意在升级到 Android 14 的设备上，targetSdkVersion 低于 23 的所有应用都将继承保持安装状态。
2.默认拒绝设定精确的闹钟

   精确闹钟适用于用户指定的通知，或是在确切时间必要实行的操作。
  SCHEDULE_EXACT_ALARM 是 Android 12 中引入的可让应用安排精确闹钟的权限，不再预先授予以 Android 13 和更高版本为目标平台的最新安装应用（默认情况下，设置为“拒绝”）。如果用户通过备份和恢复操作将应用数据转移到搭载 Android 14 的设备，则该权限仍然会被拒绝。如果现有应用已拥有此权限，则当设备升级到 Android 14 时，系统会预先授予此权限。
必要 SCHEDULE_EXACT_ALARM 权限才能通过以下 API 启动精确闹钟，否则系统会抛出 SecurityException：

• setExact()
  
• setExactAndAllowWhileIdle()
  
• setAlarmClock()
  

注意：如果利用 OnAlarmListener 对象设置精确闹钟（比方在 setExact API 中），则不必要 SCHEDULE_EXACT_ALARM 权限。
官方建议开辟者评估其利用场景，并确定精确闹钟是否仍然适用于他们。如果可以利用不精确闹钟，可以利用WorkManager或者AlarmManager的setAndAllowWhileIdle() , setWindow()或 set() API。
如果继承利用精确闹钟，首先利用AlarmManager的canScheduleExactAlarms() 查抄权限。没有权限时，可以引导用户跳动系统设置页 startActivity(Intent(Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM))去开启权限。最后在onResume()或者监听用户授予权限时系统发送的AlarmManager.ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED广播来设置精确闹钟。
最跋文得添加权限到AndroidManifest.xml中：

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

复制代码

3.关于不可关闭通知用户体验方式的变更

通过 setOngoing(true) 或设置 Notification.FLAG_ONGOING_EVENT 来制止用户关闭前台通知的应用。在Android 14上用户实际上能够关闭此类通知。
在以下情况下，此类通知仍不可关闭：

• 当手机处于锁屏状态时。
  
• 如果用户选择全部清除通知操作（有助于防止不测关闭）。
  
• 利用 CallStyle 绑定到呼叫的通知。
  
• 利用 NotificationCompat.MediaStyle 创建的媒体通知。
  
• 企业设备政策控制器 (DPC) 和支持软件包
  
• 默认的搜刮选择器软件包。
  

4.获得照片和视频的部分访问权限

Android 14 引入了“选定照片访问”，允许用户授予应用对其库中特定图像和视频的访问权限，而不是授予对给定类型的所有媒体的访问权限。

如果您在应用中利用了照片选择器，就无需请求任何存储权限，不受此变更影响。
如果您利用存储权限维护本身的图库选择器，请调整您的应用以利用新的READ_MEDIA_VISUAL_USER_SELECTED权限。如果您的应用不利用新权限，系统将以兼容模式运行您的应用。
兼容模式：如果应用不利用新权限，应用请求READ_MEDIA_IMAGES或READ_MEDIA_VIDEO权限，则系统会自动添加READ_MEDIA_VISUAL_USER_SELECTED权限到你的应用。当您的应用程序移动到后台时，或者当用户自动杀死您的应用程序时，系统最终会拒绝这些权限。这种举动就像其他一次性权限一样。
因为没有适配新权限，所以当用户选定了部分照片的访问权限后，如果用户想修改可见范围，无法做自动修改。因为对于此时的应用来说，是有READ_MEDIA_IMAGES或READ_MEDIA_VIDEO权限的。不可能每次都询问用户指定访问范围。
着实整体看来，兼容模式影响不大，应用可以正常利用。如果想要一个良好的用户交互体验，必要做适配，具体适配方法我们下面再具体说明。
影响以Android 13或更高版本为目标平台的应用

1.必须声明前台服务类型

   为了资助开辟者更有目的地界说面向用户的前台服务，Android 10 在 元素内引入了 android:foregroundServiceType 属性。如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，则必须为应用中的每项前台服务指定至少一个前台服务类型。您应该选择一个能够代表应用用例的前台服务类型。系统必要特定类型的前台服务满足特定用例。
  Android 14 中新增了 health, remoteMessaging, shortService, specialUse 和 systemExempted 类型，加上之前的还有camera, connectedDevice, dataSync, location, mediaPlayback, mediaProjection, microphone, phoneCall类型。
以下代码段提供了一个清单中的前台服务类型声昭示例：

1. <manifest ...>
2.   ...
3.   <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
4.   <uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />
5.   <uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />
6.     <application ...>
7.       <service
8.           android:name=".MyMediaPlaybackService"
9.           android:foregroundServiceType="location|mediaPlayback"
10.           android:exported="false">
11.       </service>
12.     </application>
13. </manifest>

复制代码

如果以 Android 14 为目标平台的应用未在清单中界说给定服务的类型，系统会在调用 startForeground() 时引发 MissingForegroundServiceTypeException。如果应用中的用例与这些类型均不干系，猛烈建议您迁移逻辑以利用 WorkManager 或用户发起的数据传输作业。
然后上面的代码中，你会发现多了一个FOREGROUND_SERVICE_MEDIA_PLAYBACK权限，因为Android14上必须声明所选前台服务类型所对应的权限，好比mediaPlayback就对应FOREGROUND_SERVICE_MEDIA_PLAYBACK。所有这些权限都界说为一般权限，并默认授予，且用户无法撤消这些权限。
如果没有声明适当的前台服务类型权限，系统会抛出 SecurityException。
也可以在启动前台服务时声明类型，此时所声明的类型应是AndroidManifest中类型的子集：

1. ServiceCompat.startForeground(0, notification, notification, FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK);

复制代码

如果调用中未指定前台服务类型，则该类型默以为清单中界说的值。如果您未在清单中指定服务类型，系统会抛出 MissingForegroundServiceTypeException。
同时注意系统会查抄前台服务类型的利用是否适当，并确认应用是否已请求适当的运行时权限或利用所需的 API。比方，系统希望利用前台服务类型 FOREGROUND_SERVICE_TYPE_LOCATION 的应用请求 ACCESS_COARSE_LOCATION 或 ACCESS_FINE_LOCATION。其他类型规则见每种前台服务类型的预期用例和逼迫实行。
2.BLUETOOTH_CONNECT

在 BluetoothAdapter 中逼迫实行 BLUETOOTH_CONNECT 权限，对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 14 会在调用 BluetoothAdapter getProfileConnectionState() 方法时逼迫实行 BLUETOOTH_CONNECT 权限。
此方法已必要 BLUETOOTH_CONNECT 权限，但未被逼迫实行。请确保您的应用在应用的 AndroidManifest.xml 文件中声明 BLUETOOTH_CONNECT，并在调用 getProfileConnectionState 之前查抄用户是否已授予权限。

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

复制代码

3.OpenJDK 17 更新

Android 14 将继承更新 Android 的焦点库，以与最新 OpenJDK LTS 版本中的功能保持同等，包罗得当应用宁静台开辟者的库更新和 Java 17 语言支持。
以下变更可能会影响应用兼容性：

• 对正则表达式的更改：现在，为了更严酷地遵照 OpenJDK 的语义，不允许无效的组引用。您可能会看到 java.util.regex.Matcher 类抛出 IllegalArgumentException 的新情况，因此请务必测试应用中利用正则表达式的情形。如需在测试期间启用或停用此变更，请利用兼容性框架工具切换 DISALLOW_INVALID_GROUP_REFERENCE 标志。
  
• UUID 处置惩罚：现在，验证输入参数时，java.util.UUID.fromString() 方法会实行更严酷的查抄，因此您可能会在反序列化期间看到 IllegalArgumentException。如需在测试期间启用或停用此变更，请利用兼容性框架工具切换 ENABLE_STRICT_VALIDATION 标志。
  
• ProGuard 题目：有时，在您尝试利用 ProGuard 缩减、混淆和优化应用时，添加 java.lang.ClassValue 类会导致题目。题目源自 Kotlin 库，该库会根据 Class.forName("java.lang.ClassValue")是否会返回类更改运行时举动。如果您的应用是根据没有 java.lang.ClassValue 类的旧版运行时开辟的，则这些优化可能会将computeValue 方法从派生自 java.lang.ClassValue 的类中移除。
  

4.对隐式 Intent 和PendingIntent 的限制

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，隐式Intent或PendingIntent只能打开设置了android:exported="true"的组件，如果android:exported="false"，系统会抛出异常。
比方，下面是可以在应用的清单文件中声明的 intent 过滤器：

1. <activity
2.     android:name=".AppActivity"
3.     android:exported="false">
4.     <intent-filter>
5.         <action android:name="com.example.action.APP_ACTION" />
6.         <category android:name="android.intent.category.DEFAULT" />
7.     </intent-filter>
8. </activity>

复制代码

如果应用尝试利用隐式 intent 启动此 activity，则系统会抛出异常：

1. context.startActivity(new Intent("com.example.action.APP_ACTION"));

复制代码

如需启动非导出的 activity，应用应改用显式 intent：

1. Intent explicitIntent =new Intent("com.example.action.APP_ACTION")
2. explicitIntent.setPackage(context.getPackageName());
3. context.startActivity(explicitIntent);

复制代码

5.动态注册的广播接收器必须指定导出举动

以 Android 14（API 级别 34）或更高版本为目标平台并利用上下文注册的接收器的应用和服务必须指定一个标志，以指明接收器是否应导出到设备上的所有其他应用：分别为 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED。
这点客岁的Android 13中就有干系先容，其时不是逼迫适配，到Android 14开始就必须要适配了。如果不适配，会有如下崩溃信息：

1. java.lang.SecurityException: xxx.xxx: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts

复制代码

适配方法：

1. // 接收来自其他应用程序的广播
2. context.registerReceiver(sharedBroadcastReceiver, intentFilter, ContextCompat.RECEIVER_EXPORTED);
4. // 私有广播接收器
5. context.registerReceiver(privateBroadcastReceiver, intentFilter, ContextCompat.RECEIVER_NOT_EXPORTED);

复制代码

如果应用利用Context#registerReceiver方法注册了一个系统广播接收器，那么不必要声明以上标志。如果你利用的是LocalBroadcastManager，那么也可以忽略此条变更。
6.后台启动 activity 限制

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，在原有的基础上增长了两条限制：

• 当应用利用 PendingIntent#send() 或类似方法发送 PendingIntent 时，，其干系的参数ActivityOptions应该设置setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)。
  

1. // A app创建pendingIntent
2. PendingIntent pendingIntent = PendingIntent.getActivity(this,
3.         0,
4.         notificationIntent,
5.         PendingIntent.FLAG_MUTABLE,
6.         null);
7. //通过将pendingIntent发送到B app
8. //B app收到创建的pendingcontent，然后执行send()方法发送，同时构建ActivityOptions，
9. //设置相应的模式
10. PendingIntent pendingIntent = intent.getParcelableExtra("pending");
11. ActivityOptions options = ActivityOptions.makeBasic()
12. .setPendingIntentBackgroundActivityStartMode(ActivityOptions.MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
13. .setPendingIntentCreatorBackgroundActivityStartMode(ActivityOptions.MODE_BACKGROUND_ACTIVITY_START_ALLOWED);
14. pendingIntent.send(context, 0, null, null, null, null, options.toBundle());  

复制代码

• 当一个可见应用程序利用bindService()方法绑定另一个后台应用程序的服务时，如果想要授予绑定的后台服务所在应用启动Activity，必须要在绑定服务的时间，即调用bindService()方法的时间包含BIND_ALLOW_ACTIVITY_STARTS。
  

1. targetSdk＜34，前台应用绑定后台服务启动Activity需要BIND_AUTO_CREATE
2. bindService(intent, coon, BIND_AUTO_CREATE);
3.    
4. targetSdk≥34，前台应用绑定后台服务要启动Activity，需要在之前的基础上添加BIND_ALLOW_ACTIVITY_STARTS标志。
5. bindService(intent, coon, BindServiceFlags.of(BIND_ALLOW_ACTIVITY_STARTS|BIND_AUTO_CREATE));

复制代码

7.压缩路径遍历

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 会通过以下方式防止 Zip 路径遍历漏洞：如果 zip 文件条目名称包含..或以/开头，则 ZipInputStream.getNextEntry() 和ZipFile(String)会抛出ZipException。
应用可以通过调用 dalvik.system.ZipPathValidator.clearCallback() 选择停用此验证。
8.获得照片和视频的部分访问权限

上面已经说明了干系情况，这里就不赘述了，下面直接说如何适配。
首先Android 13的基础上添加新权限：

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

复制代码

请求权限时，根据版本区分请求的权限，Android 14上必要同时请求READ_MEDIA_IMAGES，READ_MEDIA_VISUAL_USER_SELECTED，如果你必要视频，那就再加上READ_MEDIA_VIDEO。

1. private val permissionLauncher =
2.     registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { _ ->
3.         // 处理权限请求结果
4.     }
6. private fun requestPermissions() {
7.     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
8.         permissionLauncher.launch(
9.             arrayOf(READ_MEDIA_IMAGES,
10.                 READ_MEDIA_VIDEO,
11.                 READ_MEDIA_VISUAL_USER_SELECTED)
12.         )
13.     } else if (Build.VERSION.SDK_INT == Build.VERSION_CODES.TIRAMISU) {
14.         permissionLauncher.launch(arrayOf(READ_MEDIA_IMAGES, READ_MEDIA_VIDEO))
15.     } else {
16.         permissionLauncher.launch(arrayOf(READ_EXTERNAL_STORAGE))
17.     }
18. }

复制代码

授权结果查抄判断：

1. private fun checkPermissionResult() {
2.     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU
3.         && (ContextCompat.checkSelfPermission(this, READ_MEDIA_IMAGES) == PERMISSION_GRANTED
4.                 || ContextCompat.checkSelfPermission(this, READ_MEDIA_VIDEO) == PERMISSION_GRANTED)
5.     ) {
6.         // Android 13及以上完整照片和视频访问权限
7.     } else if (
8.         Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE &&
9.         ContextCompat.checkSelfPermission(this, READ_MEDIA_VISUAL_USER_SELECTED) == PERMISSION_GRANTED
10.     ) {
11.         // Android 14及以上部分照片和视频访问权限
12.     } else if (ContextCompat.checkSelfPermission(this, READ_EXTERNAL_STORAGE) == PERMISSION_GRANTED) {
13.         // Android 12及以下完整本地读写访问权限
14.     } else {
15.         // 无本地读写访问权限
16.     }
17. }

复制代码

如果READ_MEDIA_IMAGES和READ_MEDIA_VIDEO权限都有了，那就获取了所有的照片视频的访问权限，就和之前版本的交互一样。
如果只有READ_MEDIA_VISUAL_USER_SELECTED权限，说明用户之前指定看可见范围。那么可以添加一个入口让用户修改可见的照片和视频范围，具体可以参考下面的交互流程。

点击按钮可以重新请求权限，让用户修改可见范围。

---

其他还有安全的全屏 intent 通知，每个 MediaProjection 拍摄会话均必要征得用户同意等举动变更，因为我涉及不多，这里就不说了，有必要可以直接看文末的官方文档。
其他新功能及API

1.非线性字体放大至 200%

从 Android 14 开始，系统支持字体放大高达 200%，为弱视用户提供了符合网络内容无停滞指南 (WCAG) 的其他无停滞选项。
为防止屏幕上的大文本元素放大过大，系统会接纳非线性放大曲线。这种放大计谋意味着大号文本的放大比例不会与较小的文本雷同。非线性字体缩放有助于保持不同巨细元素之间的比例条理布局，同时缓解高级别线性文本缩放的题目（比方文本被截断或文本因超大显示巨细而难以阅读）。
如果你的应用字体利用的dp为单位，那么不会受次影响，否则必要测试一下ui是否可以正常显示。但是必要注意一点，利用 TypedValue.applyDimension() 从 sp 单位转换为像素，并利用 TypedValue.deriveDimension() 将像素转换为 sp。这些方法会自动应用适当的非线性缩放曲线。
避免利用 Configuration.fontScale 或 DisplayMetrics.scaledDensity 。由于字体缩放是非线性的，因此 scaledDensity 字段不再精确。fontScale 字段应仅用于提供信息，因为字体不再利用单个标量值进行缩放。
好比我们常利用scaledDensity用作像素转sp：

1. public static int px2sp(Context context, float pxValue) {
2.         final float fontScale = context.getResources().getDisplayMetrics().scaledDensity;
3.         return (int) (pxValue / fontScale + 0.5f);
4. }

复制代码

修改为：

1. public static int px2sp(Context context, float pxValue) {
2.         if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
3.                 return (int) TypedValue.deriveDimension(TypedValue.COMPLEX_UNIT_SP, pxValue, context.getResources().getDisplayMetrics());
4.         }
5.         final float fontScale = context.getResources().getDisplayMetrics().scaledDensity;
6.         return (int) (pxValue / fontScale + 0.5f);
7. }

复制代码

好比我同一设备调到最大字号时，计算了100px便是多少sp，两种方法结果如下：

1. scaledDensity：17
2. deriveDimension：21

复制代码

可以看到就有偏差了，如果是标准字号，结果如下：

1. scaledDensity：35
2. deriveDimension：34

复制代码

差1是因为我们加了0.5f，实际浮点值都是34.72222。
当然更推荐利用的core库（1.12.0版本以上）的TypedValueCompat类，内里有pxToSp等方法，内里已经帮我们做了以上适配。
2.语法性别API

有 30 亿人在利用区分性别的语言，此类语言的语法种别（比方名词、动词、形容词和介词）会根据您攀谈所涉及的人或物的性别而厘革。传统上，许多区分性别的语言利用阳性语法性别作为默认或通用性别。
以错误的语法性别来称呼用户，比方以阳性语法性别来称呼女性，可能会对她们的表现和态度产生负面影响。相比之下，界面语言如果能精确反映用户的语法性别，就可以提高用户互动度，并提供更个性化、更天然的用户体验。
为资助您针对区分性别的语言构建以用户为中心的界面，Android 14 引入了语法厘革 API，让您无需重构应用便能添加对语法性别的支持。
好比首选语法性别设为阴性，通过以下API指定：

1. GrammaticalInflectionManager gIM = mContext.getSystemService(GrammaticalInflectionManager.class);
2. gIM.setRequestedApplicationGrammaticalGender(Configuration.GRAMMATICAL_GENDER_FEMININE);

复制代码

string.xml必要相应的设置，好比法语：

• 阴性：res/values-fr-feminine/strings.xml
  
• 阳性：res/values-fr-masculine/strings.xml
  
• 中性：res/values-fr-neuter/strings.xml
  
• 默认：res/values-fr/strings.xml
  

因为我做的是出海项目，所以我会特别注意这点。因为之前我们碰到过用户反馈的干系题目，所以针对不同性别显示不同的文案。
3.各应用语言偏好设定

客岁在Android 13的新功能上就看到了这条，其时发现此功能被阉割了，所以没有过多的尝试。这次在我的手机上（Origin OS 4）发现了几款外洋应用支持了此功能，没有被阉割了。
位置位于应用信息页，有个语言入口：

Android 14 扩展了 Android 13中引入的按应用设定语言功能，并包含以下额外功能：

• 自动生成应用的 localeConfig：从 Android Studio Giraffe Canary 7 和 AGP 8.1.0-alpha07 开始，您可以将应用设置为自动支持各应用语言偏好设定。Android Gradle 插件会根据您的项目资源生成 LocaleConfig 文件，并在最终清单文件中添加对该文件的引用，这样您就不再必要手动创建或更新该文件。AGP 利用应用模块的 res 文件夹中的资源以及任何库模块依靠项来确定要在 LocaleConfig 文件中添加的语言区域。
  
• 动态更新应用的 localeConfig：利用 LocaleManager方法中的 setOverrideLocaleConfig() 和 getOverrideLocaleConfig() 可以在设备的系统设置中动态更新应用的受支持语言列表。有了这种机动性，您可以按区域自界说支持的语言列表、运行 A/B 实验，或者如果您的应用通过服务器端推送进行本地化，则可以提供更新后的语言区域列表。
  
• 输入法 (IME) 的应用语言可见性：IME 可以利用 getApplicationLocales() 方法查看当前应用的语言，并将 IME 语言与该语言进行匹配。
  

具体利用方法参考：按应用设定语言偏好。说句题外话，这些新功能我发现一般谷歌自家的Gmail都支持的比力快，好比各应用语言偏好设定，预测性返回手势，应用启动画面等都可以在Gmail上体验。
其他新功能我就不逐一先容了，有必要可以直接看文末的官方文档。

---

整体来说，Android 14是在13的基础上做了更多的增补完善，适配上来说难度不大。
参考

• 官方文档
  
• 小米 - Android14 应用适配指南
  
• Android 14新特性，选择性照片和视频访问授权
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。