[STS_8.1-202009] RuntimeException in android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert


Broadcast timeout happens in customer MT6580 projects. Reproducing ratio = 100%.

It’s OK in customer MT6739 projects.

Not reproduced in Mediatek internal projects.


Testing Condition
STS Tool Version: 8.1-202009/6731883

TestCase: CtsAppSecurityHostTestCases

Fail Type: android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert fail

Host Error Log
Test Result Details
android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert fail java.lang.AssertionError: on-device tests failed: com.android.cts.usespermissiondiffcertapp.AccessPermissionWithDiffSigTest#testDirectGrantReceiverRevokeUriPermissionjava.lang.RuntimeException: Timeout at com.android.cts.usespermissiondiffcertapp.AccessPermissionWithDiffSigTest$GrantResultReceiver.assertSuccess(AccessPermissionWithDiffSigTest.java:474) at com.android.cts.usespermissiondiffcertapp.AccessPermissionWithDiffSigTest.assertPersistedUriPermission(AccessPermissionWithDiffSigTest.java:1417) at com.android.cts.usespermissiondiffcertapp.AccessPermissionWithDiffSigTest.testDirectGrantReceiverRevokeUriPermission(AccessPermissionWithDiffSigTest.java:1615) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:115) at android.support.test.internal.runner.junit3.AndroidTestResult.runProtected(AndroidTestResult.java:77) at junit.framework.TestResult.run(TestResult.java:118) at android.support.test.internal.runner.junit3.AndroidTestResult.run(AndroidTestResult.java:55) at junit.framework.TestCase.run(TestCase.java:124) at android.support.test.internal.runner.junit3.NonLeakyTestSuite$NonLeakyTest.run(NonLeakyTestSuite.java:63) at android.support.test.internal.runner.junit3.AndroidTestSuite$2.run(AndroidTestSuite.java:111)
Checkpoint Suggestion from CTS/STS Team

  1. Check if there are Google bugs already
  2. Check if the newest security patches already merged in the project
  3. Remove 3rd party applications to see if it is OK when system environment is clear
  4. Check if it can be reproduced in driver only version
  5. Disable reboot when reboot exists in testing to see if it OK
Device Error log with AMS debug log on

//Enqueuing log for action "verifyOutgoingPersisted"

01-01 12:08:05.397 642 934 I ActivityManager: Enqueueing broadcast cts = verifyOutgoingPersisted
01-01 12:08:05.397 642 934 V ActivityManager: Broadcast: Intent { act=verifyOutgoingPersisted flg=0x10 cmp=com.android.cts.permissiondeclareapp/.GrantUriPermission (has extras) } ordered=true userid=0
01-01 12:08:05.398 642 934 V ActivityManager: Enqueueing broadcast: verifyOutgoingPersisted replacePending=false
01-01 12:08:05.398 642 934 I ActivityManager: Broadcast intent Intent { act=verifyOutgoingPersisted flg=0x10 cmp=com.android.cts.permissiondeclareapp/.GrantUriPermission (has extras) } on background queue
01-01 12:08:05.398 642 934 V ActivityManager: Enqueueing ordered broadcast BroadcastRecord{df92529 u0 verifyOutgoingPersisted}: prev had 45
01-01 12:08:05.400 642 934 V ActivityManager: Enqueueing ordered broadcast [BroadcastRecord{7f44c73 u0 android.intent.action.BOOT_COMPLETED}, BroadcastRecord{6e72e8d u-1 android.intent.action.SIM_STATE_CHANGED}, BroadcastRecord{64dd4fd u-1 android.intent.action.SIM_STATE_CHANGED},

01-01 12:09:05.562 642 3816 V BroadcastQueue: Processing ordered broadcast [background] BroadcastRecord{df92529 u0 verifyOutgoingPersisted}
01-01 12:09:05.563 642 3816 V BroadcastQueue: Submitting BROADCAST_TIMEOUT_MSG [background] for BroadcastRecord{df92529 u0 verifyOutgoingPersisted} at 200484
01-01 12:09:05.563 642 3816 V BroadcastQueue: Need to start app [background] com.android.cts.permissiondeclareapp for broadcast BroadcastRecord{df92529 u0 verifyOutgoingPersisted}

01-01 12:09:05.701 642 1155 I BroadcastQueue: Finishing broadcast [background] verifyOutgoingPersisted app=ProcessRecord{19d4c3a 2781:com.android.cts.usespermissiondiffcertapp/u0a106}
01-01 12:09:05.702 642 1155 V BroadcastQueue: Cancelling BROADCAST_TIMEOUT_MSG
01-01 12:09:05.702 642 1155 V BroadcastQueue: Finished with ordered broadcast BroadcastRecord{df92529 u0 verifyOutgoingPersisted}

What we can see in this log –

    1. Ordered broadcast verifyOutgoingPersisted is background broadcast
    2. It happens early in bootup time or reboot (android.intent.action.BOOT_COMPLETED not finished)
    3. Previous 45 ordered broadcasts already exist before enqueuing ordered broadcast verifyOutgoingPersisted
    4. It costs about 1min (01-01 12:08:05.397~01-01 12:09:05.702) to enqueue and finish bg ordered broadcast verifyOutgoingPersisted
Root Cause
Reboot is necessary in this testcase, and system is busy in reboot phase.

STS issues background ordered broadcasts set 30s timeout, but there are lots of background ordered broadcasts to enqueue and process. Broadcast timeout happens in STS testing.

Maybe Google does't take customization and performance drop into consideration.


If checkpoint is taken and there are no solution to solve this kind of error, please take this workaround to check:

// /frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java 14981    final int broadcastIntentLocked(ProcessRecord callerApp,

14982        String callerPackage, Intent intent, String resolvedType,

14983        IIntentReceiver resultTo, int resultCode, String resultData,

14984        Bundle resultExtras, String[] requiredPermissions, int appOp, Bundle bOptions,

14985        boolean ordered, boolean sticky, int callingPid, int callingUid, int realCallingUid,

14986        int realCallingPid, int userId, boolean allowBackgroundActivityStarts) {

14987     intent = new Intent(intent);

//workaround broadcast performance issue in CTS @{

//find the intent and add fg flag before enqueuing

                ComponentName GRANT_URI_PERM_COMP = new ComponentName("com.android.cts.permissiondeclareapp", "com.android.cts.permissiondeclareapp.GrantUriPermission");

                if (intent.getComponent() != null && GRANT_URI_PERM_COMP.equals(intent.getComponent()))               

                { intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND); }

//ALPS05322216 }


15004        (sticky ? "Broadcast sticky: ": "Broadcast: ") + intent

15005        + " ordered=" + ordered + " userid=" + userId); ...

15495    if (DEBUG_BROADCAST) Slog.v(TAG_BROADCAST, "Enqueueing broadcast: " + intent.getAction()

15496        + " replacePending=" + replacePending);

15611        if (DEBUG_BROADCAST) Slog.v(TAG_BROADCAST, "Enqueueing ordered broadcast " + r);

15632            queue.enqueueOrderedBroadcastLocked(r);

There are many intents configured as foreground broadcast in CTS codeflow, such as

388          final Intent intent = new Intent();

389          intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);

390          intent.setComponent(new ComponentName(pkg, UtilsReceiver.class.getName()));

Why is not the same configuration in this testcase ?

You can try proposing to Google if they can modify their intents’ type in testcase.





邮箱地址不会被公开。 必填项已用*标注