There was a hole in the getAuthToken logic that allowed notifications
resulting from getAuthToken requests using notifyOnAuthFailure=true to
launch arbitrary activites on the device. This is because the
getAuthToken session overrode onResult (unlike addAccount, updateCreds,
or confirmCreds).
Bug: 13787929
Change-Id: Ife1d48835f48416c2f0690f1413a076b69215190
We don't screenshot the IME in multi-window mode because the frame
of the IME might not overlap with that of the app. E.g. IME target
app at the top in split-screen mode and the IME at the bottom
overlapping with the bottom app.
Bug: 28446505
Change-Id: Iae4f7eafa582779a4cf2aba3d83c4d9f76a4ccca
This created extra churn in the system during resize due to
the activity relaunching.
Bug: 28614747
Change-Id: I148b6fca3dad7e10c90085a04bccb99587397912
WindowState.mInsetFrame is used to represent a temp. offset of a task
due to something like docked stack resizing or IME currently on screen.
In the case of pop-up windows (or any child window that wants to layout
in the parent frame) we were incorrectly setting the containing frame
because we were checking to see if the mInsetFrame wasn't empty. This
check isn't needed for child windows that want to layout in parent frame
because the parent frame will already have the mInsetFrame applied to
its frame which will automatically trickle down to the display and content
frame it forwards to its child windows to use.
Bug: 28389714
Change-Id: If89d40845a5a14aa60abcdedef2385b1fe7bfee3
A workaround change for supporting support lib 23.x in N release.
This change should be reverted in some point before O release.
Bug: 28572934
Change-Id: I7e6afc0293688e425736bc93da0ea10233c07e9a
We didn't dispatch the change, but still set the field. This lead to
issues where SysUI disagreed on the minimized state. To fix this, we
only check for state changes if the docked stack is visible, but then
dispatch the change always.
Bug: 28445644
Change-Id: Ie460135049c78e11c97f3160994ca4069bf82e6c
Fixes: 28432088
Ensure a transparent region on a saved surface is reset for future use,
since the surface should be like-new if used again.
This prevents an issue where the region - used to signal a portion of
content doesn't need to be composited - is persisted when a saved
surface is reused. The client assumes it's new and in default
state (composite everything), but the window is clipped when composited.
Change-Id: Icf2ec94c735679d715aded58de7eab12e9c43367
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
Another scenario that is not properly handled is when a UID whitelisted
for Data Saver is brought back to foreground: although the proper
firewall rules are set, CS is not notified, and the apps state would be
DISCONNECTED / BLOCKED.
This CL introduces many changes that fix this issue:
- Fixed updateRuleForRestrictBackgroundLocked() to invoke
onUidRulesChanged() when the Battery Saver status changed.
- Fixed updateRuleForRestrictBackgroundLocked() to invoke
onUidRulesChanged() when an app whitelisted for Data Saver is brought
back to the foreground.
- Added a new API (onRestrictPowerChanged() and getRestrictPower())
to notify external services about Battery Saver mode changes.
- Fixed CS logic to properly handle the Battery Saver changes.
Externally to this change, the CTS tests were also improved to verify
the apps get the proper connection state; they can be verified running:
cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests \
-t com.android.cts.net.HostsideRestrictBackgroundNetworkTests
BUG: 28521946
Change-Id: I8eaccd39968eb4b8c6b34f462fbc541e5daf55f1
- If a task fails to dock, animate the stack back to original state so
that the layout is not stuck in a "docked" state.
Bug: 28577229
Change-Id: If927b898a48cd5949764cb3b0c0798d22efd850a
Activity was not stopped when device went to sleep if it was covered by
another translucent activity. The issue appeared after ag/864253 which
disabled stopping for visible activities.
Bug: 28191555
Change-Id: I39f0c5579ee3e5a16db888c72ace5dc43aa307bd
Calling Objects.hash with a byte[] will call the identity hashCode on
the byte[] and this doesn't agree with the use of Objects.deepEquals
in equals.
Bug caught by error prone.
Also, replaced usage of Objects.deepEquals(mServiceDataUuid, ...) with
Objects.equals(mServiceDataUuid, ...), because mServiceDataUuid
is an Object of type ParcelUuid.
Bug: 28585195
Change-Id: Id92734874339985fedafe1a28286a6a4dcd88d3b
This will ensure that they are in the correct configuration. Needed since
recycler view will be re-using views.
BUG:28632740
Change-Id: Icdaa48696e198cfeb8c37718fec05f7f9b195842
- This CL removes the dependency on the last-active-time of the task
record, since that is dependent on the current system time (which can
be changed by the user). Instead of working around the previous
behavior in ActivityManager which moves all affiliated tasks to the
top when one task is launched, we change the behavior in the AM
directly, and prevent re-sorting the list of recent tasks improperly
(aside from the stable sort which puts the freeform tasks first).
Bug: 27398177
Change-Id: I9fa9b3497d08082fe00aa724538255de87e746d6
It's a protected broadcast, so sending it directly from 'am' is
no longer an option. This is needed for CTS as well as being
generally useful during app development.
Bug 28406044
Change-Id: I101915a8c6f19454330a8db2079a75023c112582
In one phase, we make the new password work, and in the second we make
it the only one which works ("fixation"). This means that we can set
the password in Gatekeeper between these two phases, and a crash
doesn't break things. Unlocking a user automatically fixates the
presented credential.
Bug: 28154455
Change-Id: I18812f9ce753486ce4e33b4fe2cca392b006b39c
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
This change refactores the mUidRules to use bitmasks, in preparation for
another change that will fix the issue.
It also fixes a minor bug that was preventing removed packages to be
removed from the whitelist.
BUG: 28521946
Change-Id: I9f0e1509a6192cad403f740c1cd76a6b7dab7d26
mButtonDispatchers contains ButtonDispatcher for ime_switcher and menu;
however, in #inflateButton, we tried to find ButtonDispatcher for
menu_ime, which is a FrameLayout containing ime_switcher and menu.
Therefore, after #clearViews and #inflateLayout, ime_switcher and menu
KeyButtonView are not in the corresponding ButtonDispatchers.
It means NavigationBarView#getImeSwitchButton and
NavigationBarView#getMenuButton returns empty ButtonDispatcher.
As a result, we can't control ime switch button and menu button via
NavigationBarView after then. e.g. We can't control ime switch button
visibility.
This CL fixes that issue by calling #addToDispatchers recursively for
ViewGroup children if corresponding ButtonDispatcher is not found. This
behavior is aligned with #addAll.
Bug: 28580774
Change-Id: Ibe724753390b7bbb395a6d53d00bc6d06d00aa9a
Includes all updates to App Translation API content/text. Also
includes "Related Resource" cards.
Bug: 27729402
Change-Id: I0385f448b7b92fe420f3b51394d9a659e7b6df81
Original-Change-Id: Ibcde400fe8b340f032d1c458c83deb828450c9a5
Under some circumstances we never go through the activity lifecycle
if we call startActivity before it gets stopped, so we never notified
the divider about that we have drawn.
Bug: 28531536
Change-Id: I6a13527d52bf40a87f89de4b2799bd0833c6612a
It is risky/complicated to try to put the activity showing on-top of
the lock screen in the right fullscreen configuration with the current
architecture. So, we just dismiss for now.
Bug: 28195260
Change-Id: I29a0350993ce8fe548d4a465b06d877cde151c78
This API was using a oneway aidl call, which meant that the
service was disabled some time after the method returned. That
confused tests that were turning a service off during tearDown
and then turning it back on again in setUp.
Bug: 28621277
Change-Id: I75984df0613bdbb1bc876e2a15caf59106027337
ag/990438 allowed for stack focus not to be adjusted when the currently
focused stack is removed since the caller will be moving the focus to
the right stack next. This was incorrectly enabled for the positionTask
call were the stack will not be moved to the front since the functionality
is used to move task within stacks we don't want to gain focus.
Bug: 28616824
Change-Id: Ia6aea17c0335d036a17b83fed28799428ca58eda
