Historically ViewRootImpl#mContext has been just pointing to the
Context instance associated with whatever first View instance that is
being added to a Window. In other words, ViewRootImpl#mContext is not
owned by ViewRootImpl.
This can become a problem if ViewRootImpl is moved from a display to
another display with ViewRootImpl#updateInternalDisplay(), which was
added last year to support multiple displays [1], because there is no
guarantee that the target Contaxt that is pointed from
ViewRootImpl#mContext is also updated to have the new display ID.
In order to support multi-display we need to use the right Context at
least when interacting with InputMethodManager. Hence as a short term
solution this CL introduces ViewRootImpl#mDisplayContext so that the
right instance of InputMethodManager can receive callback from
ViewRootImpl. In this way, we can make sure that the behavior change
in ViewRootImple is limited to how InputMethodManager instance is
obtained.
Longer term solution will be discussed in Bug 116349163.
[1]: I9a9501cab788623ada15a31efb53e4b2378639fe
b047b8bd7e
Bug: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ifa0ca24e9cf764caf492ee065606680b6a06751a
System server can post notifications that appear to
be coming from apps in other users (like when apps in
a work profile start a foreground service). Thus,
when resolving the uid of the notification, it's not safe
to use the calling user; instead the userid as resolved
by ActivityManager.handleIncomingUser() must be used.
Test: runtest systemui-notification
Test: start a foreground service in a managed profile for
an app that doesn't exist in the primary user.
Fixes: 116283798
Bug: 116019760
Change-Id: I568f1ed6fabe64a6c32ef0901f76b2baadc63f6c
The CL deprecates the old constructor for Magnifier instances in favor
of the usage of builder Magnifier#Builder.
Bug: 116116502
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I3daa9f066c77144e9d5c62bc666ecd37041f4bbb
Not a big win, but it makes it clearer that the data is never directly
changed by PackageManager etc. (We could extract the two nested
classes and then PackageDexUsage wouldn't need to be public at all.)
Test: Still builds.
Test: atest services/tests/servicestests/src/com/android/server/pm/dex
Change-Id: I0a5c0bff473a03178f730e354a2f60694729ba10
