* before the fix, the method would return false if the two bundles both
contains a nested bundle for the same key, and the nested bundles are
equal. i.e. the test case
InlinePresentationStyleUtilsTest#testBundleEquals_nestedBundle_equal
would fail.
Test: atest InlinePresentationStyleUtilsTest
Bug: 154957669
Change-Id: Ia2cf682619fa245d846972a8683d03333551df78
Otherwise the initial intents will be shown in the other
profile as share targets. This would cause a crash when
the user selects the app, as the activity cannot
be resolved.
Fixes: 155088755
Test: manual
Test: atest ChooserActivityTest
Test: atest ResolverActivityTest
Change-Id: I0604c15c35ecddf163460286b84c27daf6ca9a5b
Previously we would check for autolaunch the first time
onPostListReady is called, but that is too early in the case
when we start the async task for sorting the targets. In
that case onPostListReady is called twice - once before
task is launched, and once after task is finished.
We fix this by passing the rebuildListCompleted parameter to
the onPostListReady callback and use it to check for autolaunch.
Test: atest ChooserActivity
Test: atest ResolverActivity
Test: manual
Fixes: 154728817
Change-Id: Ib1b049af00d791898b908bdb65971c07c558f3ac
In ViewConfiguration, we use isUiContext to verify if a context
is an visual context. However, DecorContext uses Application
context as a base context and return false as intended.
This patch overrides isUiContext to report context#isUiContext
instead.
fixes: 153664027
Test: atest DecorContextTest#testIsUiContextFromVisualDecorContext
Change-Id: Ida26b9617c74dc6997fc2c00d97d3420a0978fc7
This error showed because DecorContext uses application context
to get WindowManager. This CL changes to use PhoneWindow to obtain
WindowManager instance. Also refactor ctr to obtain context from
PhoneWindow.
Bug: 152806048
Test: manual - enable strict mode and check the error log not shown.
Test: atest DecorContextTest
Test: atest MemoryTests#testActivityRecreation
Change-Id: I1d416b9cdb015c9bc3553571041f3b14bb9da5da
Currently, the screenshot process only remains bound to SysUI
(by ScreenshotHelper) until the screenshot finishes saving. This
makes it vulnerable to getting cached and frozen. Since the process
now includes UI with touch focus for longer than that, this can
cause ANRs in the screenshot process, if it is frozen while it's
supposed to be accepting touch input.
Retaining the binding for the entire lifecycle of the screenshot
UI fixes this problem.
Test: manual -- used the steps in b/153577093 to verify the
freezing behavior and verified that it no longer occurred after
the change
Bug: 153418099
Fix: 153418099
Change-Id: Idca24a69274af3d633e1243b46b602613cb04d50
Use PropertyInvalidatedCache to avoid redundant calls to
SubscriptionController getSlotIndex and getPhoneId.
Bug: 151953109
Test: Verified cache operated correctly when phone process is killed.
Test: atest SubscriptionControllerTest
Test: atest android.telephony.cts.SubscriptionManagerTest
Change-Id: I70552537af44f3e05b156cd190ebb28f0d940bf6
