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
| Test | Result | Details |
| android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert | fail | java.lang.AssertionError: on-device tests failed: com.android.cts.usespermissiondiffcertapp.AccessPermissionWithDiffSigTest#testDirectGrantReceiverRevokeUriPermission: java.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) |
- Check if there are Google bugs already
- Check if the newest security patches already merged in the project
- Remove 3rd party applications to see if it is OK when system environment is clear
- Check if it can be reproduced in driver only version
- Disable reboot when reboot exists in testing to see if it OK
| //Enqueuing log for action "verifyOutgoingPersisted"
01-01 12:08:05.397 642 934 I ActivityManager: Enqueueing broadcast cts = verifyOutgoingPersisted … 01-01 12:09:05.562 642 3816 V BroadcastQueue: Processing ordered broadcast [background] 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} |
What we can see in this log –
-
- Ordered broadcast verifyOutgoingPersisted is background broadcast
- It happens early in bootup time or reboot (android.intent.action.BOOT_COMPLETED not finished)
- Previous 45 ordered broadcasts already exist before enqueuing ordered broadcast verifyOutgoingPersisted
- It costs about 1min (01-01 12:08:05.397~01-01 12:09:05.702) to enqueue and finish bg ordered broadcast verifyOutgoingPersisted
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 } … 15003 if (DEBUG_BROADCAST_LIGHT) Slog.v(TAG_BROADCAST, 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.