Android 12 行为变更，对应用产生的影响

公众号：ByteCode，致力于分享最新技术原创文章，涉及 Kotlin、Jetpack、译文、系统源码、 LeetCode / 剑指 Offer / 多线程 / 国内外大厂算法题 等等一系列文章。

众所周知在春节过后 Google 发布了 「 Android 12 首个开发者预览版 」，3 月份的时候发布了 「 开发者预览版 2 」，在 Android 12 中让人眼前一亮的是系统界面做了很大改动，根据 Google 今年的发版计划，预计在今年 9 月份正式版将会发出来。

在 Android 12 中包含了很多的功能和一些行为的变更，接下来我们一起来分析这些行为的变更对我们的应用产生了那些影响以及 Google 为什么需要这么做。

通过这篇文章你将学习到以下内容：

• 为什么 Google 需要开发者显示声明 android:exported 属性？
• 为什么 Google 需要开发者显示指定 PendingIntent 的可变性？
• Google 为什么限制 adb 备份的默认行为？
• 如何检查 App 的安全漏洞？

PS ：文章中分析 Google 为什么需要做此行为的变更，纯属个人根据一些案例来分析，如果你遇到过其他安全性问题欢迎留言一起讨论。

android:exported 属性

在 Android 12 中包含 <intent-filter> 的 activity 、 service 或 receiver 必须为这些应用组件显示声明 android:exported 属性，如下所示：

<activity
    android:name=".TestActivity"
    android:exported="false">
    <intent-filter>
        ......
    </intent-filter>
</activity>

如果在包含 <intent-filter> 的 activity 、 service 或 receiver 组件中，没有显示声明 android:exported 的值，你的应用将无法安装，错误日志如下所示。

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

如果您的应用在需要声明 android:exported 的值时未进行此声明，错误日志如下所示。

Targeting S+ (version 10000 and above) requires that an explicit value for \
android:exported be defined when intent filters are present

如果对上面的异常产生的条件，不是很理解，可以点击下方链接查看，目前已经有很多开源项目都已经开始适配这个行为的变更了，例如 leakcanary 等等，详情前往查看下列地址：

• Update launcher activity attribute to Android 12
• Declared android:exported explicitly for components with intent-filter. Android 12 requirement

这个行为的变更无论是对库开发者 和 还是应用开发者、或者是开源项目影响都非常大。

为什么 Google 需要开发者显示声明 android:exported 属性

android:exported 属性的默认值取决于是否包含 <intent-filter>，如果包含 <intent-filter> 那么默认值为 true，否则 false。

• 当 android:exported="true" 时，如果不做任何处理，可以接受来自其他 App 的访问
• 当 android:exported="false" 时，限制为只接受来自同一个 App 或一个具有相同 user ID 的 App 的访问

正因为 android:exported 的属性的默认值的问题，Twicca App 发生过一次安全性问题，因为另一个没有访问 SD 卡或网络权限的 App，可以通过 Twicca App 将存储在 SD 卡上的图片或电影上传到 Twicca 用户的 Twitter 账户上的社交网络上。

产生问题的代码如下所示：

<activity android:configChanges="keyboard|keyboardHidden|orientation" android:name=".media.yfrog.YfrogUploadDialog" android:theme="@style/Vulnerable.Dialog" android:windowSoftInputMode="stateAlwaysHidden">           
    <intent-filter android:icon="@drawable/yfrog_icon" android:label="@string/YFROG">
        <action android:name="jp.co.vulnerable.ACTION_UPLOAD" />                
        <category android:name="android.intent.category.DEFAULT" />                
        <data android:mimeType="image/*" />                
        <data android:mimeType="video/*" />            
    </intent-filter>        
</activity>

因为添加了 intent-filter 所以 android:exported 的属性的默认值为 true，因此可以接受来自其他 App 的访问，进而造成了上述问题（通过 Twicca App 将存储在 SD 卡上的图片或电影上传到 Twicca 用户的 Twitter 账户上的社交网络上），而解决方案有两个：

• 方案一：添加 android:exported="false" 属性

<activity android:exported="false" android:configChanges="keyboard|keyboardHidden|orientation" android:name=".media.yfrog.YfrogUploadDialog" android:theme="@style/ VulnerableTheme.Dialog" android:windowSoftInputMode="stateAlwaysHidden" >    
</activity>

• 方案二： Twicca App 没有使用方式一，而是检查调用者的包名是否与自身的包名相同

public void onCreate(Bundle arg5) {
    super.onCreate(arg5);
    ...
    ComponentName v0 = this.getCallingActivity();
    if(v0 == null) {
        this.finish();
    } else if(!jp.r246.twicca.equals(v0.getPackageName())) {
        this.finish();
        } else {
            this.a = this.getIntent().getData();
            if(this.a == null) {
                this.finish();
            }
            ...
        }
    }
}

这种方案也是可行的，因为在一台设备上，不可能会出现两个包名相同的应用，更多详细的信息可以前往查看 Restrict access to sensitive activities。

这仅仅是关于 activity 的安全漏洞的其中一个，在不同的场景下利用这些漏洞做的事情也可能不一样。当然还有 service 和 receiver 组件也都是一样，存在安全性问题。

指定 PendingIntent 的可变性

在 Android 12 中创建 PendingIntent 的时候，需要显示的声明是否可变，请分别使用 PendingIntent.FLAG_MUTABLE 或 PendingIntent.FLAG_IMMUTABLE 标志，如果您的应用试图在不设置任何可变标志的情况下创建 PendingIntent 对象，系统会抛出 IllegalArgumentException 异常，错误日志如下所示：

PACKAGE_NAME: Targeting S+ (version 10000 and above) requires that one of \
FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if \
some functionality depends on the PendingIntent being mutable, e.g. if \
it needs to be used with inline replies or bubbles.

为什么 Google 需要开发者显示的指定 PendingIntent 的可变性?

在 Adnroid 12 之前，默认创建一个 PendingIntent 它是可变的，因此其他恶意应用程序可能会拦截，重定向或修改此 Intent。（但是是有条件限制的）

一个 PendingIntent 是一个可以给另一个应用程序使用的 Intent，PendingIntent 接收待处理意图的应用程序可以使用与产生待处理意图的应用程序相同的权限和身份执行待处理意图中指定的操作。

因此，创建待处理意图时必须小心，为了安全性 Google 在 Android 12 中需要开发者自己来指定 PendingIntent 的可变性。

更多关于 PendingIntent 安全性介绍，可以前往查看 Always pass explicit intents to a PendingIntent

adb 备份限制

Android 开发者都应该知道这个命令 adb backup , 它可以备份应用的数据，在 Android 12 中，为了保护私有应用数据，用户运行 adb backup 命令时，从设备导出的任何其他系统数据都不包含应用数据。

如果你在测试和开发过程中需要使用 adb backup 来备份应用数据，你可以在 AndroidManifest 中将 android:debuggable 设置为 true 来导出应用数据。

<application
    android:name=".App"
    android:debuggable="true"
    ....../>

注意：在发布应用前将 android:debuggable 设置为 false

为什么 Google 在 Android 12 限制了 adb backup 命令的默认行为

因为这个存在严重的安全问题，当初 Google 为了提供 App 数据备份和恢复功能，可以在 AndroidManifest 中添加 android:allowBackup 属性，默认值为 true, 当你创建一个应用的时候，会默认添加这个属性，如下所示：

<application
    android:name=".App"
    android:allowBackup="true"
    ....../>

当 android:allowBackup="true" 时，用户可以通过 adb backup 和 adb restore 命令对应用数据进行备份和恢复，也就是说可以在其他的 Android 手机上安装同一个应用，通过如上命令恢复用户的数据。

为了安全起见，我们在发布出去的 Apk 中一定要将 android:allowBackup 属性设置为 false 来关闭应用程序的备份和恢复功能，以免造成信息泄露。国民级应用 XX 信, 在曾今发出的版本中 allowBackup 的属性值是 true，被其他逆向开发者利用之后，现在的版本中这个值已经修改为 false了，有兴趣的小伙们可以反编译看看。

如何检查 App 的安全漏洞

在这里推荐一个开源项目 linkedin/qark 这是由 LinkedIn 开源的项目，这个工具被设计用来寻找与安全相关的 Android 应用程序漏洞，无论是源代码还是打包的 APK，具体的用法文档上写的非常的清楚了，这里不做详细的介绍了。

这个开源项目的检查结果，作为参考即可。当然也有很多公司花了重金去购买第三方的服务来检查 App 的安全漏洞。

在 Android 12 上这几个行为的变更它们都有一个共性：安全性，可见 Google 这几年在安全上做了很多的努力，当然还有其他的一些行为的变更，可以前往查看 行为变更：以 Android 12 为目标平台的应用

开发中 App 安全的注意事项

从 Google 在 Android 12 上的安全行为变更来看，Google 应该收到了很多安全漏洞的案例，是通过这几个基本组件来进行的，要不然也不会做此重要的改变（纯属个人看法）。

在很早之前，看到过一篇文章 谈谈 Android 下 App 的安全性问题，这篇文章包含：activity 、 service  、  Broadcast 、 webview 、 Content Provider 开发中的一些注意事项和安全编码建议，以及一些测试方法，找了很久才找到，有兴趣的小伙们可以前往查看，这里就不详细列出来了，原文有更加详细的介绍。

参考文章

• 行为变更：以 Android 12 为目标平台的应用
• Update launcher activity attribute to Android 12
• Declared android:exported explicitly for components with intent-filter. Android 12 requirement
• confluence

结语

这篇文章主要介绍了在 Android 12 上行为的变更，对 App 都有些影响，以及这些行为在 App 中都有那些安全漏洞，我们在开发中应该如何注意这些潜在的问题。

全文到这里就结束了，如果有帮助 点个赞 就是对我最大的鼓励

代码不止，文章不停

欢迎关注公众号：ByteCode，持续分享最新的技术

最后推荐我一直在更新维护的项目和网站：

• 全新系列视频：现代 Android 开发 (MAD) 技巧系列教程：在线查看
  
• 计划建立一个最全、最新的 AndroidX Jetpack 相关组件的实战项目 以及 相关组件原理分析文章，正在逐渐增加 Jetpack 新成员，仓库持续更新，欢迎前去查看：AndroidX-Jetpack-Practice
  
• LeetCode / 剑指 offer / 国内外大厂面试题 / 多线程 题解，语言 Java 和 kotlin，包含多种解法、解题思路、时间复杂度、空间复杂度分析

• 剑指 offer 及国内外大厂面试题解：在线阅读
• LeetCode 系列题解：在线阅读

• 最新 Android 10 源码分析系列文章，了解系统源码，不仅有助于分析问题，在面试过程中，对我们也是非常有帮助的，仓库持续更新，欢迎前去查看 Android10-Source-Analysis
  
• 整理和翻译一系列精选国外的技术文章，每篇文章都会有译者思考部分，对原文的更加深入的解读，仓库持续更新，欢迎前去查看 Technical-Article-Translation
  
• 「为互联网人而设计，国内国外名站导航」涵括新闻、体育、生活、娱乐、设计、产品、运营、前端开发、Android 开发等等网址，欢迎前去查看 为互联网人而设计导航网站

历史文章

• 为数不多的人知道的 Kotlin 技巧以及 原理解析（一）
• 为数不多的人知道的 Kotlin 技巧以及 原理解析（二）
• Jetpack 最新成员 AndroidX App Startup 实践以及原理分析
• Jetpack 成员 Paging3 实践以及源码分析（一）
• Jetpack 成员 Paging3 网络实践及原理分析（二）
• Jetpack成员Paging3获取网络分页数据并更新到数据库中（三）
• Jetpack 成员 Hilt 实践（一）启程过坑记
• Jetpack 成员 Hilt 结合 App Startup（二）进阶篇）进阶篇
• Jetpack 新成员 Hilt 与 Dagger 大不同（三）落地篇
• 全方面分析 Hilt 和 Koin 性能
• 神奇宝贝(PokemonGo)  眼前一亮的 Jetpack + MVVM 极简实战
• Kotlin Sealed 是什么？为什么 Google 都用
• Kotlin StateFlow 搜索功能的实践 DB + NetWork
• 再见吧 buildSrc, 拥抱 Composing builds 提升 Android 编译速度
• [Google] 再见 SharedPreferences 拥抱 Jetpack DataStore
• Kotlin 插件的落幕，ViewBinding 的崛起
• 竟然如此简单，DataBinding 和 ViewBinding
• 图解多平台 AndroidStudio 技巧(三)