Android 4.3 Monkey自动化测试工具被killed的原因分析

最新推荐文章于 2024-11-26 00:15:00 发布

zhao3546

最新推荐文章于 2024-11-26 00:15:00 发布

阅读量5.9k

点赞数

CC 4.0 BY-SA版权

分类专栏： Android 常见问题

本文链接：https://blog.youkuaiyun.com/zhao_3546/article/details/19193277

Android 同时被 2 个专栏收录

55 篇文章

订阅专栏

常见问题

11 篇文章

订阅专栏

本文记录了一次使用Monkey工具进行自动化测试时遇到的问题及解决过程。问题表现为Monkey启动后导致Activity Manager异常终止，通过分析日志和源代码定位到空指针异常，并给出了修复方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

原创链接：http://blog.youkuaiyun.com/zhao_3546/article/details/19193277，转载，请注明。

测试组使用Monkey在Android上想对APK进行自动化测试，但在启动Monkey测试工具时，一直无法正常启动，

shell@android:/ $ monkey -p com.android.calculator2 -v 100
monkey -p com.android.calculator2 -v 100
:Monkey: seed=1393356259515 count=100
:AllowPackage: com.android.calculator2
:IncludeCategory: android.intent.category.LAUNCHER
:IncludeCategory: android.intent.category.MONKEY
Killed

一执行就会被killed，无意间测试说起这个问题，说是因为这个系统我们定制过，应该是定制的原因导致的问题。

我较真了，怎么可能是我们定制的原因呢？一般的APK在这个系统上都是可以正常运行的，并且也没有出过问题，所以我对定制这个说法完全不认同。

让相关人员重新执行后，让他同时提供相应的logcat的日志。

日志如下：

02-13 10:02:24.604 D/AndroidRuntime(14430): Calling main entry com.android.commands.monkey.Monkey
02-13 10:02:24.614 D/dalvikvm(14430): Note: class Landroid/app/ActivityManagerNative; has 168 unimplemented (abstract) methods
02-13 10:02:24.614 D/AndroidRuntime(14430): Shutting down VM
02-13 10:02:24.614 W/dalvikvm(14430): threadid=1: thread exiting with uncaught exception (group=0x416a5700)
02-13 10:02:24.614 E/ActivityManager(  605): Activity Manager Crash
02-13 10:02:24.614 E/ActivityManager(  605): java.lang.NullPointerException
02-13 10:02:24.614 E/ActivityManager(  605):     at com.android.server.am.ActivityManagerService.registerReceiver(ActivityManagerService.java:11867)
02-13 10:02:24.614 E/ActivityManager(  605):     at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:308)
02-13 10:02:24.614 E/ActivityManager(  605):     at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1809)
02-13 10:02:24.614 E/ActivityManager(  605):     at android.os.Binder.execTransact(Binder.java:388)
02-13 10:02:24.614 E/ActivityManager(  605):     at dalvik.system.NativeStart.run(Native Method)
02-13 10:02:24.624 E/JavaBinder(14430): Unknown binder error code. 0xfffffff7
02-13 10:02:24.624 I/Process (14430): Sending signal. PID: 14430 SIG: 9
02-13 10:02:24.624 E/AndroidRuntime(14430): *** FATAL EXCEPTION IN SYSTEM PROCESS: main
02-13 10:02:24.624 E/AndroidRuntime(14430): java.lang.NullPointerException
02-13 10:02:24.624 E/AndroidRuntime(14430):     at android.os.Parcel.readException(Parcel.java:1437)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at android.os.Parcel.readException(Parcel.java:1385)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at android.app.ActivityManagerProxy.registerReceiver(ActivityManagerNative.java:2237)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at com.android.commands.monkey.MonkeyNetworkMonitor.register(MonkeyNetworkMonitor.java:88)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at com.android.commands.monkey.Monkey.getSystemInterfaces(Monkey.java:979)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at com.android.commands.monkey.Monkey.run(Monkey.java:586)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at com.android.commands.monkey.Monkey.main(Monkey.java:509)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:235)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at dalvik.system.NativeStart.main(Native Method)
02-13 10:02:24.624 E/AndroidRuntime(14430): Error reporting crash
02-13 10:02:24.624 E/AndroidRuntime(14430): android.os.RemoteException: Unknown binder error code. 0xfffffff7
02-13 10:02:24.624 E/AndroidRuntime(14430):     at android.os.BinderProxy.transact(Native Method)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at android.app.ActivityManagerProxy.handleApplicationCrash(ActivityManagerNative.java:3525)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at com.android.internal.os.RuntimeInit$UncaughtHandler.uncaughtException(RuntimeInit.java:76)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)
02-13 10:02:24.624 E/AndroidRuntime(14430):     at dalvik.system.NativeStart.main(Native Method)

我了个去，这个程序一运行，居然把 Activity Manager 给搞挂了，从现象来看，应该是Framework层的bug，即使应用有问题，ActivityManger也不应该挂。

分析了一下代码，看看 com.android.server.am.ActivityManagerService.registerReceiver 的实现：

    public Intent registerReceiver(IApplicationThread caller, String callerPackage,
            IIntentReceiver receiver, IntentFilter filter, String permission, int userId) {
        ...
        synchronized(this) {
            ProcessRecord callerApp = null;
            if (caller != null) {
                callerApp = getRecordForAppLocked(caller);
                if (callerApp == null) {
                    throw new SecurityException(
                            "Unable to find app for caller " + caller
                            + " (pid=" + Binder.getCallingPid()
                            + ") when registering receiver " + receiver);
                }
                ...
                callingUid = callerApp.info.uid;
                callingPid = callerApp.pid;
            } else {
                callerPackage = null;
                callingUid = Binder.getCallingUid();
                callingPid = Binder.getCallingPid();
            }

            ...

            BroadcastFilter bf = new BroadcastFilter(filter, rl, callerPackage,   // 日志显示，挂在这里
                    permission, callingUid, userId, callerApp.info.flags & ApplicationInfo.FLAG_SYSTEM) != 0);
            ...
    }

从代码上看，出现空指针异常的这个点，确实是有缺陷的，如果 caller 为null，则 callerApp 就是 null。

Google发布的代码，也会有bug，是人写的代码，就有缺陷啊。

修改成为如下：

            BroadcastFilter bf = new BroadcastFilter(filter, rl, callerPackage,
                    permission, callingUid, userId, 
                    (callerApp != null && (callerApp.info.flags & ApplicationInfo.FLAG_SYSTEM) != 0));

重新编译出相应的 services.jar，替换 /system/framework/ 下的同名文件，再让测试重新验证，问题解决。

其实在测试给我说了Monkey的作用后，我就在想Monkey的实现原理，如下纯粹个人猜想，未进一步找资料验证。

集成Android开发SDK的Eclipse中，提供了DDMS的功能，通过点击如下“红框”圈住的按钮，就可以得到右边的视图，即当前手机屏幕上显示的内容，以及View对象树，

我个人分析Monkey也是使用类似的原理，通过DDMS获取当前屏幕上显示的View对象视图，有了这个，其实也就有了哪个区域可以被点击，再通过脚本来控制相应的点击区域即可。

我经常想起我之前PL在我给他解释某问题的可能原因时他经常问我的一句话，为什么是这个原因？你有证据吗？你有重现吗？

跟着他，我也学会时常问自己或别人为什么，为什么这样，为什么那样，通过多问为什么，也让我会去不断思考一些更深层次的东西，好的习惯给我带来的帮助真的难以估量。