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();
                }
            }
        }

乍一看好像代码没有问题,代码想要实现流程如下:
aosp12 framework重大bug:contentprovider获取低概率偶现延时10s问题修复经验分享_第1张图片

但是为啥有会有这个等待10s问题,而且等了10s后确实有相应的provider值
问题关键,多线程并发,没有注意锁的范围控制:
aosp12 framework重大bug:contentprovider获取低概率偶现延时10s问题修复经验分享_第2张图片

同时看看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();
                }
         
        }

但是呢?大家看看
aosp12 framework重大bug:contentprovider获取低概率偶现延时10s问题修复经验分享_第3张图片

那么也就存在可能

     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,和上面修改方案差不多:
aosp12 framework重大bug:contentprovider获取低概率偶现延时10s问题修复经验分享_第4张图片

你可能感兴趣的:(Framework,低概率偶现问题,ContentProvider,aosp原生bug,桌面空白10s,多线程并发)