大家好，最近行业形势越来越差，希望大家安好吧。之前写过一些 `Android` 版本的适配： - [安卓11来了，快！扶我起来](https://juejin.cn/post/6844904132352933896) - [安卓13来了，快！扶起我来！](https://juejin.cn/post/7117449403765358605) - [Android 14 又来了？别扶！抬起我来吧！](https://juejin.cn/post/7235906062309965880) 今年继续，这对于自己来说也算是一个小的任务或者说传统吧。同样，本篇文章也会从以下几个点切入： - 涉及所有应用的变更 - 针对Android 15应用的变更 - Android 15新功能探索 - Android 15 时间线及总结 ## 涉及所有应用的变更 ### [Support for 16 KB page sizes](https://developer.android.com/about/versions/15/behavior-changes-all#16-kb) 之前的 Android 版本中仅支持 4 KB 页面内存，这优项修改化了系统内存性能，使其适用于 Android 设备通常拥有的平均总内存量。从 Android 15 开始，Android 支持配置为使用 16 KB 页面大小的设备。 - 系统面临内存压力时缩短应用启动时间：平均缩短 3.16%，谷歌测试的一些应用的改进更为显著（高达 30%） - 降低应用程序启动时的耗电量：平均减少 4.56% - 相机启动速度更快：热启动速度平均加快 4.48% - 冷启动速度平均加快 6.60% - 改善系统启动时间：平均改善1.5%（约0.8秒）如果应用使用的是 `Java` 或 `Kotlin` 构建的话，则无需做处理，可以直接适配，但如果应用使用任何NDK库（无论是直接使用还是通过 SDK 间接使用），则需要重新构建应用，使其在这些 16 KB 设备上运行。构建文档如下： ### 隐私空间隐私空间是 Android 15 中的一项新功能，用户可在其设备上创建一个单独的空间，通过额外的身份验证，让敏感应用远离窥探。由于隐私空间中的应用可见性受到限制，因此某些类型的应用需要采取额外步骤才能查看用户隐私空间中的应用并与之交互。由于私人空间中的应用保存在单独的用户配置文件中（类似于工作配置文件），因此应用不应假设其应用的任何已安装副本（不在主配置文件中）都在工作配置文件中。这块大部分开发者无需考虑，和应用没有什么关系，但对 `Launcher` 和应用商店有些影响，需要坐下适配。 #### Launcher 如果在开发 `Launcher` ，则必须先执行以下操作，然后隐私空间中的应用才可见： 0. 开发的 `Launcher` 必须被指定为设备的默认应用，即拥有该 [`ROLE_HOME`](https://developer.android.com/reference/android/app/role/RoleManager#ROLE_HOME) 角色。 0. 必须 [在应用的清单文件中](https://developer.android.com/training/permissions/declaring)[`ACCESS_HIDDEN_PROFILES`](https://developer.android.com/reference/android/Manifest.permission#ACCESS_HIDDEN_PROFILES) 声明正常权限。声明该`ACCESS_HIDDEN_PROFILES`权限 `Launcher` 必须处理以下私有空间用例： 0. 必须有一个单独的启动器容器，用于安装位于私人空间的应用。 0. 用户必须能够隐藏和显示私人空间容器。 0. 用户必须能够锁定和解锁私人空间容器。 0. 锁定期间，私人空间容器内的任何应用都不应可见，或无法通过搜索等机制发现。 #### 应用商店应用隐私空间中包含一个“安装应用”按钮，该按钮会启动隐式 `Intent` 以将应用安装到用户的私人空间中。需要在应用的清单文件中声明一个带有 [`CATEGORY_APP_MARKET`](https://developer.android.com/reference/android/content/Intent#CATEGORY_APP_MARKET) 的 ""。这个东西怎么说呢，冠冕堂皇，看着好像是给用户一些隐私，但隐私有直接在页面中展示的么？难道不应该是通过一些用户自定义的特殊操作才能触发的才叫隐私么？不过有比没有强，相信国内的各大厂商会把这个功能做的更好，真正成为“隐私空间”。 ### MinSDK 更新 MinSDK 版本从 23 增加到了 24，大家都知道，`Android 14` 中将 MinSDK 改为了23，想要彻底杜绝应用设置 SDK 版本为 23 以下从而绕开动态权限，这回又升级了一下，应用想绕过 `FileProvider` 处理一些文件也不可以了，之后肯定会越来越高，这样挺好，能杜绝一些流氓应用。如果需要测试针对旧 API 级别的应用，可以使用以下 ADB 命令： ``` adb install --bypass-low-target-sdk-block FILENAME.apk ``` ### [Camera and media]() 顾名思义，这就是相机和多媒体相关应用需要注意的修改，在 `Android15` 中，当达到资源限制时，直接和卸载音频播放现在会使先前打开的直接或卸载音轨无效。在 `Android15` 之前，如果一个应用在另一个应用正在播放音频时请求直接或卸载音频播放，且已达到资源限制，则该应用将无法打开新的 `AudioTrack`。从 `Android15` 开始，当应用请求直接或卸载播放且达到资源限制时，系统会使任何当前打开的 `AudioTrack` 对象无效，从而阻止满足新曲目请求。有需要查看详细信息的可以进官网看下： ### 预测返回动画这个也是之前 `Android` 版本中就加入的新功能，从 Android 15 开始，预测返回动画的开发者选项已被移除（默认打开）。对于已完全或在 Activity 级别选择启用预测返回手势的应用，现在将显示返回主页、跨任务和跨活动等系统动画。如果应用受到影响，请执行以下操作： 1、确保应用已正确迁移以使用预测返回手势。 2、确保 fragment transitions 与预测性返回导航兼容。 3、放弃动画和框架转换，改用动画器和 androidx 转换。 4、迁移 FragmentManager 未知的返回堆栈。改用由 FragmentManager Navigation 组件管理的返回堆栈。 ## 针对Android 15应用的变更 ### 数据同步前台服务超时行为 `Android 15` 为以 `Android 15` 或更高版本为目标平台的应用引入了新的超时行为 `dataSync`。系统允许应用的 `dataSync` 服务在 24 小时内总共运行 6 小时，之后系统将调用正在运行的服务的 `Service.onTimeout(int, int)` 函数。此时，`Service` 有几秒钟的时间调用 `Service.stopSelf()`。当 `Service.onTimeout()` 被调用时，服务不再被视为前台服务。如果服务未调用 `Service.stopSelf()`，则会报错。 ``` override fun onTimeout(startId: Int) { super.onTimeout(startId) stopSelf() } ``` 由于目前 `Android 15` 还没有正式发布，现在最新版本为 `Beta 2` ，在 Beta 2 中，错误显示为 ANR。 > 注意：应用的所有前台服务都共享 6 小时的时间限制dataSync。例如，如果应用运行一项dataSync服务 4 小时，然后启动另一项dataSync服务，则第二项服务将只允许运行 2 小时。但是，如果用户将应用置于前台，计时器将重置，应用将有 6 小时的可用时间。如果应用的dataSync前台服务在过去 24 小时内已运行了 6 个小时，则无法启动另一个dataSync前台服务，除非用户将应用调至前台（这会重置计时器）。如果尝试启动另一个dataSync前台服务，系统会抛出 ForegroundServiceStartNotAllowedException 一条错误消息，例如“前台服务类型 dataSync 的时间限制已用尽 ### 新媒体处理前台服务类型 Android 15 引入了一种新的前台服务类型：`mediaProcessing`，此 `Service` 类型适用于转码媒体文件等操作。例如，媒体应用可能会下载音频文件，并需要将其转换为其他格式才能播放。 ``` ``` 可以使用 `mediaProcessing` 前台服务来确保即使应用在后台，转换仍会继续进行。 ### Receiver 启动前台服务的限制 BOOT_COMPLETED 广播接收器启动前台服务有了新的限制，不得启动以下类型的前台服务：`dataSync`、`camera`、`mediaPlayback`、`phoneCall`、`mediaProjection`、`microphonemicrophone`（此限制自 `Android 14` 起生效）如果BOOT_COMPLETED接收器尝试启动任何类型的前台服务，系统将抛出异常：ForegroundServiceStartNotAllowedException。 ### 有SYSTEM_ALERT_WINDOW权限时启动前台服务之前 `Android` 版本中如果应用程序拥有该 SYSTEM_ALERT_WINDOW 权限，即使应用程序当前处于后台，也可以启动前台服务。如果应用以 `Android 15` 为目标平台，则此豁免范围现在缩小了。应用现在需要获得权限 SYSTEM_ALERT_WINDOW，并且还必须具有可见的 overlay window。也就是说，应用需要先启动一个 TYPE_APPLICATION_OVERLAY 窗口，并且该窗口必须在启动前台服务之前可见。如果尝试从后台启动前台服务而不满足这些新要求（并且没有其他豁免），系统将抛出 ForegroundServiceStartNotAllowedException。如果声明了 SYSTEM_ALERT_WINDOW 权限并从后台启动前台服务，则可能会受到此更改的影响。如果应用报错 ForegroundServiceStartNotAllowedException，需要检查应用的操作顺序，并确保在应用尝试从后台启动前台服务之前，应用已有一个 overlay window。可以通过调用 `View.getWindowVisibility()` 来检查 overlay window 当前是否可见，或者也可以重写View.onWindowVisibilityChanged()，当可见性发生变化时会接收到回调信息。 ### 阻止与堆栈顶部 UID 不匹配的应用启动流氓应用可以在同一任务中启动另一个应用的 `Activity`，然后将自己叠加在上面，造成该应用的假象。这种“劫持”攻击绕过了当前的后台启动限制，因为这一切都发生在同一可见任务中。为了降低这种风险，`Android 15` 添加了一项标记，阻止与堆栈顶部 UID 不匹配的应用启动 `Activity`。要选择加入应用的所有 `Activity` 的 AndroidManifest.xml文件中的属性，如下代码所示： ``` ``` 如果启用了安全措施，应用程序在完成了自己的任务后可能会返回主页，而不是最后可见的应用程序。如果以下所有条件均满足，新的安全措施就会生效： 0. 执行启动的应用程序以 Android 15 为目标 0. 任务堆栈顶部的应用程序以 Android 15 为目标 0. 任何可见的活动都已选择加入新的保护措施 ### 更安全的Intent `Android 15` 引入了新的安全措施，使 `Intent` 更安全、更强大。这些变化旨在防止潜在的漏洞和滥用 `Intent`，以免被恶意应用利用。`Android 15` 对 `Intent` 的安全性进行了两项主要改进： - 匹配目标 `IntentFilter`：针对特定组件的 `Intent` 必须准确匹配目标的 `IntentFilter` 规范。如果发送 `Intent` 以启动另一个应用的 `Activity`，则目标 `Intent` 组件需要与接收 `Activity` 声明的 `IntentFilter` 保持一致。 - `Intent` 必须具有操作：没有操作的 `Intent` 将不再匹配任何 `IntentFilter`。这意味着用于启动 `Activity`或 `Service` 的 `Intent` 必须具有明确定义的操作。可以启用严格模式来帮助发现应用中的潜在问题： ``` fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) } ``` ### Edge-to-edge enforcement 如果应用以 `Android 15` 为目标平台，则应用在运行 `Android 15` 的设备上默认为无边框。这是一项重大变更，可能会对应用的 UI 产生负面影响。这是一项重大变更，会影响以下 UI 区域：状态栏、导航栏、三大金刚键、刘海： - 手势控制导航栏 - 默认透明。 - 底部偏移被禁用，因此除非应用插入，否则内容将在系统导航栏后面绘制。 - [`setNavigationBarColor`](https://developer.android.com/reference/android/view/Window#setNavigationBarColor(int))和`R.attr#navigationBarColor`已被弃用，并且不会影响手势导航。 - [`setNavigationBarContrastEnforced`](https://developer.android.com/reference/android/view/Window#setNavigationBarContrastEnforced(boolean))并且 `R.attr#navigationBarContrastEnforced`继续对手势导航没有影响。 - 三大金刚键 - 不透明度默认设置为 80%，颜色可能与窗口背景相匹配。 - 底部偏移已禁用，因此除非应用插入，否则内容将在系统导航栏后面绘制。 - [`setNavigationBarColor`](https://developer.android.com/reference/android/view/Window#setNavigationBarColor(int))并`R.attr#navigationBarColor`默认设置为与窗口背景匹配。窗口背景必须是彩色可绘制对象，此默认设置才会应用。此 API 已弃用，但仍会影响金刚键。 - [`setNavigationBarContrastEnforced`](https://developer.android.com/reference/android/view/Window#setNavigationBarContrastEnforced(boolean))默认情况下为 `R.attr#navigationBarContrastEnforced`真，这会在金刚键中添加 80% 不透明的背景。 - 状态栏 - 默认透明。 - 顶部偏移被禁用，因此除非应用插入，否则内容会绘制在状态栏后面。 - [`setStatusBarColor`](https://developer.android.com/reference/android/view/Window#setStatusBarColor(int))和`R.attr#statusBarColor`已被弃用，并且对 Android 15 没有影响。 - [`setStatusBarContrastEnforced`](https://developer.android.com/reference/android/view/Window#setStatusBarContrastEnforced(boolean))和 `R.attr#statusBarContrastEnforced`已被弃用，但仍对 Android 15 有影响。 - 刘海 - `layoutInDisplayCutoutMode`非浮动窗口必须是 `LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS`。`SHORT_EDGES`，`NEVER`并且 `DEFAULT`被解释为`ALWAYS`，以便用户不会看到由显示切口引起的黑条并且出现边到边。 ### [适配Edge-to-edge](https://developer.android.com/develop/ui/views/layout/edge-to-edge) 如果应用尚未实现无边框设计，则很有可能受到影响。除了已实现无边框设计的应用场景外，你还应考虑以下事项： - 1、如果应用在 `Compose` 中使用 `Material 3` 组件不会受到影响 - 2、如果应用在 `Compose` 中使用 `Material 2` 组件，需手动设置边距。 - 3、如果应用使用 `View` 和 `Material` 组件，大多数基于视图的 `Material` 组件（例如`BottomNavigationView`、`BottomAppBar`、 `NavigationRailView` 等）都可以处理边距。但如果使用 `Layout` 则需要添加 android:fitsSystemWindows="true"。 - 4、对于自定义 `Composables`，需手动设置边距。 - 5、如果正在使用 `View` 、`BottomSheet` 、`SideSheet` 或自定义容器，需使用 `ViewCompat.setOnApplyWindowInsetsListener` 进行监听设置对应边距。对于 `RecyclerView` 需添加 `clipToPadding="false"`。其实这个修改很快乐，之前应用想要实现沉浸式其实是一个比较费劲的事，会有各种人、各种文章来教你如何设置，但效果却不尽人意，不是实现不了就是代码很丑陋，导致大部人会在 `BaseActivity` 中直接写上沉浸式的修改。但在 `Android 15` 中，如果应用想要实现沉浸式的话，你需要做的事是：**什么都不做！** #### 原生 View 适配先来写下布局： ```