Android 12 已来,你的 App 解体了吗?
咱们曾经开始做 Android 12 的适配了,在 Android 12 中蕴含了很多的性能和一些行为的变更,接下来咱们一起来剖析这些行为的变更对咱们的利用产生了那些影响。
通过这篇文章你将学习到以下内容:
• 为什么在 Android 12 上须要显示申明 android:exported 属性?
• 为什么在 Android 12 上须要显示指定 PendingIntent 的可变性?
• 为什么在 Android 12 上限度 adb 备份的默认行为?
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 等等
这个行为的变更无论是对库开发者 和 还是利用开发者影响都十分大。
为什么在 Android 12 上须要显示申明 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 账户上的社交网络上。
产生问题的代码如下所示:
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();
}
...
}
}
}
这种计划也是可行的,因为在一台设施上,不可能会呈现两个包名雷同的利用
这仅仅是对于 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.
为什么在 Android 12 上须要显示的指定 PendingIntent 的可变性
在 Adnroid 12 之前,默认创立一个 PendingIntent 它是可变的,因而其余歹意应用程序可能会拦挡,重定向或批改此 Intent。(然而是有条件限度的)
一个 PendingIntent 是一个能够给另一个应用程序应用的 Intent,PendingIntent 接管待处理用意的应用程序能够应用与产生待处理用意的应用程序雷同的权限和身份执行待处理用意中指定的操作。
因而,创立待处理用意时必须小心,为了安全性 Google 在 Android 12 中须要开发者本人来指定 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。
为什么在 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 了,有趣味的小伙们能够反编译看看。
好了,明天的文章就到这里,感激浏览,喜爱的话不要忘了 三连。大家的反对和认可,是我分享的最大能源