We were thrwing undocumented runtime exception when
one gets the permission flags - now we just return
default result of the package is gone.
bug:28657926
Change-Id: I42554a86b9304ff83fe9385f3eea930b8ebf0c63
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: Icf38e72403b190a8fa9d0554b8dd83ce78da3bc8
Children where not removed from the stackscrollstate as
their removal was blocked when removing a group.
Change-Id: I0a3bbb91d0df2693e1ec7e89276c8714636a34ad
Fixes: 28670320
Scrolls the NotificationStackScrollLayout in response to movement
to ensure that the focused view stays visible. Also makes sure that
the action list is always aligned at the bottom of the notification
to avoid jank during this scrolling when the height changes.
Fixes: 28193862
Fixes: 26919632
Change-Id: I911a873367fe26eafd9fae4bca4e693d0827eba7
Those notifications could get into a group with higher priority
because they were autobundled or if the app said so.
This could lead to invisible views on the lockscreen and a crash
when this happened in an animated fashion.
The bug was triggering old code that wasn't needed anymore that
removed the viewstate.
Change-Id: Ic86c2f03d55f2e98e352cdbfbb3ca80d8e676765
Fixes: 28611831
Because notifications could become isolated when
the group is suppressed it could lead to concurrent
modifications while looping.
Change-Id: Ifd4fe0cc24110455de0d3edf2da0be0773eb8c67
Fixes: 28652038
When a child got set not be a heads up after it was already
removed (When for example it was clicked on shortly after
it got posted) then it got orphaned leading to bad bugs
like the next notification not being visible. This
could happen often with WhatsApp who set the head up flags
on the summary instead of the children.
Change-Id: I52c8f5d9bc50080e4ece530255236d36f998372e
Fixes: 28565942
This created extra churn in the system during resize due to
the activity relaunching.
Bug: 28614747
Change-Id: I148b6fca3dad7e10c90085a04bccb99587397912
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
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
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
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
