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代码：

@UnsupportedAppUsage
    public 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查询又没有改provider
                holder = 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 out
                        holder = null;
                    }
                }
            }
        } 
        //省略
        return holder.provider;
    }
//ams端回调app进程通知provider已经准备好了
     @Override
        public 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 out
                        holder = 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 out
                        holder = null;
                    }
                }

发现aosp 13已经有官方修复的patch，和上面修改方案差不多：