Android 14 适配的那些事情_android 14限制了应用在后台持续进行网络通信的能力

简介

• 距离 Android 14 发布已经有一段时间了，趁着这次机会，了解和熟悉了 Android 14 更新的内容，现在来和大家分享一下，大家喜欢的话可以点个赞多多支持一下，文章的内容按照适配内容的重要程度进行排序。

targetSdk 版本要求

• 在 Android 14 上面，新增了一个要求，要求新安装的应用的 targetSdkVersion 需要大于等于 23（即 Android 6.0 及以上），如果小于这个值将无法在 Android 14 的设备上面安装，此时大家心里可能有疑惑了，谷歌为什么要求那么做呢？我们来看看谷歌的原话是什么

text

复制代码

恶意软件通常会以较旧的 API 级别为目标平台， 以绕过在较新版本 Android 中引入的安全和隐私保护机制。 例如，有些恶意软件应用使用 targetSdkVersion 22， 以避免受到 Android 6.0 Marshmallow（API 级别 23）在 2015 年引入的运行时权限模型的约束。 这项 Android 14 变更使恶意软件更难以规避安全和隐私权方面的改进限制。

• 从上面这段话不难看出来谷歌的用意，其实为了保障用户的手机安全，如果用户安装应用的 targetSdkVersion 版本过低，有一些恶意软件会利用高系统会兼容旧软件这一特性（漏洞），故意绕过系统的安全检查，从而会导致 Android 高版本上面一些安全特性无法生效，没有了系统的管束，这些恶意软件可能就会肆意乱来。

• 另外你如果想在 Android 14 系统上面，仍然要安装 targetSdkVersion 小于 23 的应用，可以通过以下 adb 命令来安装 apk，这样就能绕过系统的安装限制。

adb install --bypass-low-target-sdk-block xxx.apk

前台服务类型要求

• 如果你的应用 targetSdkVersion 升级到了 34（即 Android 14），并且在 Service 中调用了 startForeground 方法，那么就需要进行适配了，否则系统会抛出 MissingForegroundServiceTypeException 异常，这是因为在 Android 14 上面，要求应用在开启前台服务的时候，需要注明这个前台服务的用途，谷歌给我们列举了以下几种用途：

• 介绍完这几种前台服务类型，接下来介绍如何适配它，适配前台服务类型的特性方式具体有两种方式，一种是注册清单属性，另外一种是代码动态注册

<service
  android:name=".XxxService"
  android:foregroundServiceType="dataSync"
  android:exported="false">
</service>

startForeground(xxx, xxx, ServiceInfo.FOREGROUND_SERVICE_TYPE_DATA_SYNC);

• 另外附上前台服务类型对应的适配属性

图片和视频的部分访问权限

• 谷歌在 API 33（Android 13）上面引入了 READ_MEDIA_IMAGES 和 READ_MEDIA_VIDEO 这两个权限，目前针对这两个权限在 Android 14 上面有新的变动，具体的变动点就是新增了 READ_MEDIA_VISUAL_USER_SELECTED 权限，那么这个权限的作用是什么呢？我们都知道 READ_MEDIA_IMAGES 和 READ_MEDIA_VIDEO 是申请图片和视频权限的，但是这样会有一个问题，当第三方应用申请到权限后，就拥有了手机相册中所有照片和视频的访问权限，这是十分危险的，也是非常不可控的，因为用户也无法知道第三方应用会干什么，所以谷歌在 API 34（Android 14）引入了这个权限，这样用户拥有了更多的选择，可以将相册中所有的图片和视频授予给第三方应用，也可以将部分的图片和视频给第三方应用。

• 讲完了这个特性的来龙去脉，那么接下来讲讲这个权限如何适配，如果你的应用申请了 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限，并且 targetSdkVersion 大于等于 33（Android 13），那么需要在申请权限时携带上 READ_MEDIA_VISUAL_USER_SELECTED 权限方能正常申请，如果不携带上 READ_MEDIA_VISUAL_USER_SELECTED 权限就申请 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限，会弹出权限询问对话框，但是如果用户是选择全部授予，那么 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限状态是已授予的状态，如果用户是选择部分授予，那么 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限状态是已拒绝的状态，假设此时有携带了 READ_MEDIA_VISUAL_USER_SELECTED 权限的情况下，那么 READ_MEDIA_VISUAL_USER_SELECTED 权限是已授予的状态。

• 看到这里，脑洞大的同学可能有想法了，那我不申请 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限，我就只申请 READ_MEDIA_VISUAL_USER_SELECTED 权限行不行啊？答案也是不行的，我替大家试验过了，这个权限申请会在不会询问用户的情况下，被系统直接拒绝掉。

• 另外需要的一点是 READ_MEDIA_VISUAL_USER_SELECTED 属于危险权限，除了在运行时动态申请外，还需要在清单文件中进行注册。

registerReceiver 需要指定导出行为

• 谷歌在 Android 12 （API 31）新增了四大组件需要指定 android:exported 属性的特性，这次在 Android 13 上面做了一些变动，因为谷歌之前只考虑到静态注册四大组件的情况，但是遗漏了一种情况，BroadcastReceiver 不仅可以静态注册，还可以动态注册，动态注册的广播不需要额外在 AndroidManifest.xml 中再进行静态注册，所以这次谷歌将这个规则漏洞补上了，并且要求开发者在动态注册广播的时候，能够指定 BroadcastReceiver 是否能支持导出，由此来保护应用免受安全漏洞的影响。

• 到此，大家心中可能有一个疑惑，这里的支持导出是什么意思？有产生什么作用？可以先看一下谷歌官方的原话

复制代码

为了帮助提高运行时接收器的安全性，Android 13 允许您指定您应用中的特定广播接收器是否应被导出以及是否对设备上的其他应用可见。 如果导出广播接收器，其他应用将可以向您的应用发送不受保护的广播。 此导出配置在以 Android 13 或更高版本为目标平台的应用中可用，有助于防止一个主要的应用漏洞来源。 在以前的 Android 版本中，设备上的任何应用都可以向动态注册的接收器发送不受保护的广播，除非该接收器受签名权限的保护。

• 谷歌的解释很明了，如果广播支持导出，那么其他应用可以通过发送这个广播触发我们应用的逻辑，这可能会发生程序安全漏洞的问题。

• 那么该如何适配这一特性呢？谷歌官方提供了一个 registerReceiver(BroadcastReceiver receiver, IntentFilter filter, int flags) API，flags 参数传入 Context.RECEIVER_EXPORTED（支持导出） 或 Context.RECEIVER_NOT_EXPORTED（不支持导出），具体的代码适配代码如下：

  String action = "xxxxxx";
  IntentFilter filter = new IntentFilter(action);
  if (VERSION.SDK_INT >= VERSION_CODES.TIRAMISU) {
      context.registerReceiver(new LocaleChangeReceiver(), filter, Context.RECEIVER_EXPORTED);
  } else {
      context.registerReceiver(new LocaleChangeReceiver(), filter);
  }
  

  还有一种情况，不需要指定 flag 参数，就是当要注册的广播 action 隶属系统的 action 时候，这个时候可以不需要指定导出行为。

更安全的动态代码加载

• 如果我们应用有动态加载代码的需求，并且此时 targetSdk 升级到了 API 34（即 Android 14），那么需要注意一个点，动态加载的文件（Jar、Dex、Apk 格式）需要设置成只读的，具体案例的代码如下：

File jar = new File("xxxx.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    jar.setReadOnly();
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

至于谷歌这样做的原因，我觉得十分简单，是为了程序的安全，防止有人抢先在动态加载之前先把动态文件替换了，那么会导致执行到一些恶意的代码，间接导致应用被入侵或者篡改。

另外需要注意的一个点的是，如果你的应用 targetSdk 大于等于 API 34（即 Android 14），如果不去适配这一特性，那么运行在 Android 14 的手机上面系统会抛出异常。

屏幕截图检测

• Android 14 新增引入了屏幕截图检测的 API，方便开发者更好地检测到用户的操作，具体的使用案例如下：

1. 在清单文件中静态注册权限

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

2. 创建监听器对象

final Activity.ScreenCaptureCallback screenCaptureCallback = new Activity.ScreenCaptureCallback() {
 
    @Override
    public void onScreenCaptured() {
        // 监听到截图了
    }
};

3. 在合适的时机注册监听

public final class XxxActivity extends Activity {
 
    @Override
    protected void onStart() {
        super.onStart();
        registerScreenCaptureCallback(executor, screenCaptureCallback);
    }
}

4. 在合适的时机取消注册监听

public final class XxxActivity extends Activity {
 
    @Override
    protected void onStop() {
        super.onStop();
        unregisterScreenCaptureCallback(screenCaptureCallback);
    }
}

需要注意的是，如果使用的是 adb 进行的截图，并不会触发 onScreenCaptured 监听方法。

如果不想你的应用能被系统截图，可以考虑给当前的 Window 窗口加上 WindowManager.LayoutParams.FLAG_SECURE 标记位。

最后表达一下我对这个 API 看法，这个 API 设计得不是很好，比如应用想知道用户是否截图了，应用可能需要知道的是，截图文件的存放路径，但是 onScreenCaptured 是一个空参函数，也就意味着没有携带任何参数，如果要实现获取截图文件存放路径的需求，可能还需要沿用之前的老方式，即使用 ContentObserver 监听媒体数据库的变化，然后从几个维度（文件时间维度、文件路径维度、图片尺寸维度）判断新增的图片是否为用户的截图，这种实现的方式相对是比较麻烦的，但是也无发现更好的实现方式。

作者：37手游移动客户端团队
链接：https://juejin.cn/post/7308434314777772042
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。