【调试篇3】Android 应用调试问题(执行notifyCha

2020-11-09  本文已影响0人  农民工Alan

无论是任何类型的开发工作,出错都在所难免,而错误报告对于找出和解决问题至关重要
https://source.android.com/setup/read-bug-reports?hl=zh-cn

本文记录Android应用调试问题,并将持续不断更新

1、Caused by: java.lang.IllegalArgumentException: Parameter specified as non-null is null: method kotlin.jvm.internal.Intrinsics.checkParameterIsNotNull, parameter savedInstanceState

【解决方法】Fragment中的override fun onCreatePreferences方法参数savedInstanceState加上可空标识,如:savedInstanceState: Bundle?

2、java.lang.IllegalArgumentException: Parameter specified as non-null is null: method kotlin.jvm.internal.Intrinsics.checkParameterIsNotNull, parameter convertView

【解决方法】参数convertView指定为非空的,实际为空了,将contentView:View改为contentView: View?

3、注册ContentObserver,更新完数据库,执行notifyChange延迟问题

【原因】在优化MediaProvider的操作时,Google注意到许多后台应用注册ContentObservers,当发生改变进行通知时,会影响相机应用程序做持久重度操作例如:a burst capture。为了达到平衡,将延迟逻辑移入到了ContentService,仅将即时通知发送到前台应用,后台应用会延时10秒收到有关更改的消息。详见google的修改记录:https://android.googlesource.com/platform/frameworks/base/+/462062c91cc2bad6d289ded27d3d5d7b53e224fb%5E%21/#F0
【解决方法】
通过下面这笔可知,https://android.googlesource.com/platform/frameworks/base/+/9d475e958df9ea0f558458de6629733d5b1fd3e1%5E%21/#F1,可以知道Google后续增加了flag解决此问题

final boolean noDelay = (key.flags & ContentResolver.NOTIFY_NO_DELAY) != 0;

只要noDelay返回true,则不会延迟通知,而flags是notifyChange时透传过来的,此处更改flag为:

int flag = (syncToNetwork ? NOTIFY_SYNC_TO_NETWORK : 0) | ContentResolver.NOTIFY_NO_DELAY

即可让通知不延迟

4、ActivityManager调用getRunningAppProcesses()无法获取到当前运行App List

【原因】调用上述接口时,需要申请android.Manifest.permission.REAL_GET_TASKS 权限

boolean isGetTasksAllowed(String caller, int callingPid, int callingUid) {
        if (getRecentTasks().isCallerRecents(callingUid)) {
            // Always allow the recents component to get tasks
            return true;
        }
        boolean allowed = checkGetTasksPermission(android.Manifest.permission.REAL_GET_TASKS,
                callingPid, callingUid) == PackageManager.PERMISSION_GRANTED;
5、View 的 按键响应延迟100ms,setPressed回调延迟100ms执行的原因

【原因】View的onTouchEvent 可知,响应Down事件时,会取判断当前view的父view是否可滑动,如果可滑动,延迟100ms处理setPressed状态

// Walk up the hierarchy to determine if we're inside a scrolling container.
boolean isInScrollingContainer = isInScrollingContainer();

// For views inside a scrolling container, delay the pressed feedback for
// a short period in case this is a scroll.
//判断当前父view是否可滑动
if (isInScrollingContainer) {
    mPrivateFlags |= PFLAG_PREPRESSED;
    if (mPendingCheckForTap == null) {
        mPendingCheckForTap = new CheckForTap();
    }
    mPendingCheckForTap.x = event.getX();
    mPendingCheckForTap.y = event.getY();
    postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());
} else {
    // Not inside a scrolling container, so show the feedback right away
    setPressed(true, x, y);
    checkForLongClick(
            ViewConfiguration.getLongPressTimeout(),
            x,
            y,
            TOUCH_GESTURE_CLASSIFIED__CLASSIFICATION__LONG_PRESS);
}
break;

6、Long monitor contention with owner
7、应用本地实现的接口不会回调

【原因】系统与应用解耦,为了兼容Q与R版本,加了add-on-adapter层sdk适配,适配时接口未实现框架的接口,故应用实现的接口类型是add-on-adapter中的,framework中执行的代码接口类型是add-on中的,类型不一致,判断有问题导致不会回调。

8、Binary XML file line #38 in com.android.contacts:layout/item_group_membership

布局文件未设置为public

上一篇下一篇

猜你喜欢

热点阅读