The stack currently holds a reference to resuming and pausing
activities. These are usually cleaned up when the activity ends or
the task is reparented. However, it is possible for an activity to
lose its reference to its task in other areas (such as
ActivityStarter), which can lead to the stack not being updated
correctly.
This changelist adds a method to the ActivityStack to disassociate
the stack from an ActivityRecord. In addition to places where this is
called when an activity ends, this method is invoked on the children
of a task when the task is reparented. The task member variable of
ActivityRecord is also now surrounded by a setter/getter, with the
setter always invoking the dissociation logic on a previous stack.
Test: bit FrameworksServicesTests:com.android.server.am.ActivityRecordTests
Change-Id: Iffeccdb6f011958896271673946acfed28856f53
Fixes: 36387417
- When the PiP menu activity was brought forward, we were inadvertently
setting the auto-enter supported flag for the PiP base activity as
well, which would trigger auto-enter PiP once the activity is moved
back to fullscreen and then subsequently finished.
Bug: 36352343
Bug: 36364010
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Id1b800bf392d03b55562fb13374e33a5ff0ebda6
This problem was not detected by CTS tests because the exception is
"harmless" (it's just ignored), but it can be verified at logcat:
W Binder : Caught a RuntimeException from the binder stub implementation.
W Binder : java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.IntentSender android.service.autofill.FillResponse.getAuthentication()' on a null object reference
W Binder : at com.android.server.autofill.ViewState.maybeCallOnFillReady(ViewState.java:159)
Bug: 35707731
Test: CtsAutoFillServiceTestCases pass
Test: manual verification
Change-Id: I58330a7e91b2c186bf97897b7d39640010ca630b
System API for an external audio focus policy. Extends
the system focus listener with interception of
focus requests and abandons. Adds method for the focus
policy to dispatch focus grants and losses.
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases -t 'com.google.android.gts.audio.AudioHostTest#testFocusPolicy'
Bug: 30258418
Change-Id: If408569a2dce07a774e0e2f1be9f1af8e426d2d3
There are two separate overrides for display metrics in DisplayManager
and WindowManager:
- In DM - LogicalDisplay#mOverrideDisplayInfo, in most cases not null.
- In WM - DisplayContent#mBaseDisplayWidth/Height/Density, different
from #mInitialDisplayWidth/Height/Density values when some metrics are
forced.
When display was resized its windows weren't updated because of
two problems: old LogicaDisplay#mOverrideDisplayInfo was preventing
WM from detecting the change and override (base) display metrics were
never updated by resize.
When display size changes:
- Before this CL:
DM receives DISPLAY_CHANGED event, it updates internal values and
WM is notified about them with a message. In most cases there is an
override obtained from WM and WM doesn't get new values from
LogicalDisplay#getDisplayInfoLocked().
- With this CL:
WM will requests real updated values from DM without any overrides
and will decide whether to apply them or not: if there is no override
in WM - it will apply values from WM, otherwise it will keep the
override. Also it will always update initial display metrics if there
is a real change detected.
Bug: 35258051
Bug: 34164473
Bug: 36518752
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testDisplayResize
Test: #testForceDisplayMetrics
Change-Id: I2495c27797f11f9aaee4ea06648a8ccd29ac5b62
- Don't clobber the state if we are deferring resizing due to finishing
activities.
- Fix issue with PiP tasks being visible after the stack is removed, due
to it being put below a non-fullscreen task in the fullscreen stack.
Instead just move it to the back of the stack.
Bug: 36592307
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ia18fe155b8a045a8ffea84612fd08af3ef3982d8
When resolving activtities for the USB device/accessory connection UI a
special intent that allows to switch between profiles get added. This
also gets added if there is no activity in the secondary profile that
can be started.
Fixes: 36544815
Test: Added work profile. Add USB handling app only to personal profile
and plugged in USB device -> no crash anymore
Change-Id: I311ddd53b3ff0c8406e62bac57972d4b790ebddc
If the snapshot starting window has different dimensions than the
snapshots we have taken, we do the following:
- Create a child Surface that has exactly the dimensions of the
snapshot.
- We fill the parent surface with the app background color, as well
as all screen background decorations (status bar background,
navigation bar background).
- We also clip of the status bar/navigation bar background in some
cases, as it looks ugly if it's not behind the system bars.
- Furthermore, we inherit all layout flags on the window and all
layout relevant SystemUI flags on the window such that it's very
likely that the size will match, and the system bars are drawn
correctly.
- In order to make the transition from the snapshot to the real
window a bit more predictable/less messy, we enforce a minimum
duration the snapshot is visible, which is slightly more than our
app transitions.
Test: TaskSnapshotSurfaceTest
Test: Open app, go home, go landscape, open app again
Test: Go to multi-window, open app from recents with a snapshot
taken in fullscreen.
Fixes: 36703868
Change-Id: Ia2d4add6971a18ab7aa2942d2b644d6e87a402af
UserManager may not have been started yet, so discover users by
looking at filesystem.
Fix disabled bug where default should be "false."
Test: builds, boots
Bug: 36794413
Change-Id: If91fd27b955175072228a93aab4b8ac3b27df0bf
It's confusing, but f_bsize is not the value you're looking for; the
real block size is f_frsize. Fix all those bugs.
Also, the vast majority of clients are interested in the usable
disk space, not including reserved space.
Test: builds, boots
Bug: 36840579
Change-Id: Ib1470389afd49c14cab62282ec1e978ebb2c4791
Some system services are offering package usage data through both
public/system APIs and through dump() calls. In principle, usage
data hould always be protected with PACKAGE_USAGE_STATS, so start
enforcing that. (Otherwise if a user blocked PACKAGE_USAGE_STATS
access to an app, that app could still obtain the data via dump()
if they held the DUMP permission.)
Bottom line, let's respect the user's wishes.
Protecting the entire output like this is pretty blunt, but future
CLs can add more nuance to the output if desired.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: I46173562713bea7d89e12a4313c78eb52ea8d77d
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
The system previously overrode the display size for a specific scope
(task/activity/etc.) by setting the associated Configuration's
screenWidthDp/screenHeightDp. This leads to two issues. First, the
conversion of screen size from pixels to display independent pixels
and then upconverting later on leads to rounding errors. Secondly,
the screenWidthDp and screenHeightDp values account for insets, such
as the status bar. These however are not reflected in the display
size when returned from Display#getMetrics/getSize.
This changelist addresses the issue by adding a Rect value to
Configuration which stores the app display bounds. This is always set
at the display level and overridden as appropriate. As the proper
app insets are accounted for at the root configuration, all overrides
(outside of specific exceptions) are the result of the intersection
between the requested bound and the parent bound.
Change-Id: I2c4fcd0bee92af12aabbca258de05b4ec061d0e1
Fixes: 34338931
Bug: 36812336
Bug: 36676979
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsAppTestCases android.app.cts.AspectRatioTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerDisplayTests
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
WindowFrameTests#testLayoutNonfullscreenTask and
sizes because test assumed that frame for window was always
bigger than screen size. Now we calculate all frames relative
to real display size.
TestWindowManagerPolicy used in WM unit tests reported incorrect
value from rotationHasCompatibleMetricsLw(), which lead to
DisplayContent#mAltOrientation set to "true" after any rotation
and resulted in shrinked display metrics.
DisplayContentTests#testDefaultDisplayOverrideConfigUpdate was
not restoring the config applied to default display because
it was trying update values in config from non-empty to empty,
which is considered a no-diff.
Test: com.android.server.wm.WindowFrameTests
Test: #testCalculatePolicyCrop
Test: #testLayoutNonfullscreenTask
Test: com.android.server.wm.AppWindowTokenTests
Test: #testLandscapeSeascapeRotationByApp
Test: com.android.server.wm.DisplayContentTests
Test: #testDefaultDisplayOverrideConfigUpdate
Change-Id: Ia0ed46307f67f6b47859209ebcf13253b59b8002
