Android 15？我想躺着

大家好，最近行业形势越来越差，希望大家安好吧。

之前写过一些 Android 版本的适配：

安卓11来了，快！扶我起来
安卓13来了，快！扶起我来！
Android 14 又来了？别扶！抬起我来吧！

今年继续，这对于自己来说也算是一个小的任务或者说传统吧。

同样，本篇文章也会从以下几个点切入：

涉及所有应用的变更
针对Android 15应用的变更
Android 15新功能探索
Android 15 时间线及总结

涉及所有应用的变更

Support for 16 KB page sizes

之前的 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 设备上运行。

构建文档如下：https://developer.android.com/guide/practices/page-sizes#build

隐私空间

隐私空间是 Android 15 中的一项新功能，用户可在其设备上创建一个单独的空间，通过额外的身份验证，让敏感应用远离窥探。由于隐私空间中的应用可见性受到限制，因此某些类型的应用需要采取额外步骤才能查看用户隐私空间中的应用并与之交互。由于私人空间中的应用保存在单独的用户配置文件中（类似于工作配置文件），因此应用不应假设其应用的任何已安装副本（不在主配置文件中）都在工作配置文件中。

这块大部分开发者无需考虑，和应用没有什么关系，但对 Launcher 和应用商店有些影响，需要坐下适配。

Launcher

如果在开发 Launcher ，则必须先执行以下操作，然后隐私空间中的应用才可见：

开发的 Launcher 必须被指定为设备的默认应用，即拥有该 ROLE_HOME 角色。
必须在应用的清单文件中ACCESS_HIDDEN_PROFILES 声明正常权限。

声明该ACCESS_HIDDEN_PROFILES权限 Launcher 必须处理以下私有空间用例：

必须有一个单独的启动器容器，用于安装位于私人空间的应用。
用户必须能够隐藏和显示私人空间容器。
用户必须能够锁定和解锁私人空间容器。
锁定期间，私人空间容器内的任何应用都不应可见，或无法通过搜索等机制发现。

应用商店应用

隐私空间中包含一个“安装应用”按钮，该按钮会启动隐式 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

顾名思义，这就是相机和多媒体相关应用需要注意的修改，在 Android15 中，当达到资源限制时，直接和卸载音频播放现在会使先前打开的直接或卸载音轨无效。在 Android15 之前，如果一个应用在另一个应用正在播放音频时请求直接或卸载音频播放，且已达到资源限制，则该应用将无法打开新的 AudioTrack。从 Android15 开始，当应用请求直接或卸载播放且达到资源限制时，系统会使任何当前打开的 AudioTrack 对象无效，从而阻止满足新曲目请求。

有需要查看详细信息的可以进官网看下：https://developer.android.com/about/versions/15/behavior-changes-all#camera-media

预测返回动画

这个也是之前 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 类型适用于转码媒体文件等操作。例如，媒体应用可能会下载音频文件，并需要将其转换为其他格式才能播放。

<serviceandroid:name="Service"android:foregroundServiceType="mediaProcessing" />

可以使用 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()，当可见性发生变化时会接收到回调信息。