summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorLorenzo Colitti <lorenzo@google.com>2021-02-15 09:36:55 +0900
committerLorenzo Colitti <lorenzo@google.com>2021-03-31 18:28:14 +0900
commitaa7de1bfcd95f1c9731767ac7d704c7294188cdb (patch)
treefb5a4b9f0af5030fbdc62eea3e723dcd9681e104 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent0c69c63107951d7fe9e716bc4c8d105fe9a7f021 (diff)
BroadcastInterceptingContext: use passed-in broadcast Handler.
Currently, BroadcastInterceptingContext always runs broadcast receivers on the thread that called sendBroadcast. This means: 1. Receivers might run on the wrong thread, making the test less realistic. 2. If any receiver checks what thread it's running on, then either the check needs to be modified or deleted, or the test must call sendBroadcast on the thread that the receiver expects to run on. The latter is impossible when there is more than one receiver that needs to run on more than one thread. This CL adds a setUseRegisteredHandlers method that allows tests to say that they want each receiver to run on the Handler specified at registration time. This CL also enables the new mode for ConnectivityServiceTest, and resolves a TODO to re-enable a disabled thread check. The new mode cannot be enabled by default because it would break most of the tests. [This is a partial cherry-pick of an AOSP change that also made changes to ConnectivityServiceTest, and which conflicts in mainline-prod. This CL only includes the changes to BroadcastInterceptingContext.] Bug: 173331190 Test: atest TetheringTests Merged-In: I3303bb14516f07a55d82a16b59c111ab3f8b0389 Change-Id: I95c2371d4e9f51aab2bc6e6368d133e8a75987cd
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions