aosp12 framework重大bug：contentprovider获取低概率偶现延时10s问题修复经验分享

问题背景：

在android12的版本上，陆陆续续发现一个低概率偶现的问题，那就是桌面第一次启动会存在显示空白10s以上，正常空白一般在1-2s，在个空白10s以上确实就属于非常严重的问题，但这个是一个低概率偶现问题，而且只有一例，所以说一直也没有引起重视。直到陆续确实有测试都报有这个同样问题，这个时候就开始要着力重点解决，这里分享一下针对这种低概率偶现问题的处理方式，这种方式适合所有framework端的一些低概率的偶现问题解决。
更多framework干货知识手把手教学

Log.i("千里马qq群"，“422901085”);

framework层面低概率偶现问题处理方法

这里主要分享一下公司里面是如何处理低概率偶现问题的：
1、需要在对应的怀疑地方加追踪日志，等待下一次测试复现时候可以有更多的log依据
2、如果概率较高，比如可以几十次复现一次，那么就需要组织测试人力进行集中复现该问题
3、只要可以概率复现，和测试合作复现，就不断的加日志缩小范围，追踪到根本原因
4、知道了根本原因后,考虑修改代码故意触发错误，然后让问题必现，看看现象是否和低概率问题一致
5、确定波及最小的修改问题方案进行修改，修改后验证可以先考虑让代码故意触发bug看看是否修改已经生效，然后再去除故意触发bug代码，提交给测试验证测试

contentprovider的具体问题揭秘

首先来看看android 12上的acquireProvider代码：

@UnsupportedAppUsagepublic final IContentProvider acquireProvider(Context c, String auth, int userId, boolean stable) {final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable);if (provider != null) {return provider;}ContentProviderHolder holder = null;final ProviderKey key = getGetProviderKey(auth, userId);try {synchronized (key) {//这里从ams查询又没有改providerholder = ActivityManager.getService().getContentProvider(getApplicationThread(), c.getOpPackageName(), auth, userId, stable);//如果没有查询到provider，那么就需要等待ams发布provider即notifyContentProviderPublishStatus执行if (holder != null && holder.provider == null && !holder.mLocal) {synchronized (key.mLock) {//注意这里加锁进行下面操作//注意这里就有wait 10s的操作key.mLock.wait(ContentResolver.CONTENT_PROVIDER_READY_TIMEOUT_MILLIS);holder = key.mHolder;}if (holder != null && holder.provider == null) {// probably timed outholder = null;}}}} //省略return holder.provider;}
//ams端回调app进程通知provider已经准备好了@Overridepublic void notifyContentProviderPublishStatus(@NonNull ContentProviderHolder holder,@NonNull String authorities, int userId, boolean published) {final String auths[] = authorities.split(";");for (String auth: auths) {final ProviderKey key = getGetProviderKey(auth, userId);synchronized (key.mLock) {//注意这里进行对应的mHolder设置填充key.mHolder = holder;key.mLock.notifyAll();}}}

乍一看好像代码没有问题，代码想要实现流程如下：
在这里插入图片描述

但是为啥有会有这个等待10s问题，而且等了10s后确实有相应的provider值
问题关键，多线程并发，没有注意锁的范围控制：
在这里插入图片描述

同时看看notifyContentProviderPublishStatus的锁也是这个key.mLock

 public void notifyContentProviderPublishStatus(@NonNull ContentProviderHolder holder,@NonNull String authorities, int userId, boolean published) {//省略synchronized (key.mLock) {key.mHolder = holder;key.mLock.notifyAll();}}

但是呢？大家看看
在这里插入图片描述

那么也就存在可能

     holder = ActivityManager.getService().getContentProvider(getApplicationThread(), c.getOpPackageName(), auth, userId, stable);

这一行代码查询时候确实没有，但是查询完了后如果多线程产生并发notifyContentProviderPublishStatus又同时执行了，那么notifyContentProviderPublishStatus先获取了mLock,而且给provider赋值了，导致自己的mLock就再也不会有notifyContentProviderPublishStatus来解锁

 synchronized (key) {holder = ActivityManager.getService().getContentProvider(getApplicationThread(), c.getOpPackageName(), auth, userId, stable);if (holder != null && holder.provider == null && !holder.mLocal) {//查询完成后，还没有执行下面的代码，马上有ams回调执行了notifyContentProviderPublishStatus，导致了这个key.mLock执行在notifyContentProviderPublishStatus后面synchronized (key.mLock) {key.mLock.wait(ContentResolver.CONTENT_PROVIDER_READY_TIMEOUT_MILLIS);holder = key.mHolder;}if (holder != null && holder.provider == null) {// probably timed outholder = null;}}

那么问题就明白了相当于本质其实就是锁范围不对，导致了这个10s问题

解决方案

这里为了最小的波及范围，不采用修改锁的范围方式，采用如下检测修改方案

 synchronized (key) {holder = ActivityManager.getService().getContentProvider(getApplicationThread(), c.getOpPackageName(), auth, userId, stable);if (holder != null && holder.provider == null && !holder.mLocal) {synchronized (key.mLock) {if (key.mHolder== null) {//这里需要加个再判断是否这个mHolder还为null，才进行等待key.mLock.wait(ContentResolver.CONTENT_PROVIDER_READY_TIMEOUT_MILLIS);}holder = key.mHolder;}if (holder != null && holder.provider == null) {// probably timed outholder = null;}}