This change partially reverts the back button behavior change introduced
in: I48ec35f841ab3b306fe80845150000c390908f5e
Instead of always moving the task to the back when the back button is
pressed on the root task, we only do it when the activity that is open
is a "launcher activity". These are activities that act as the main
entry points into an application, indicated with an intent filter with
ACTION_MAIN and CATEGORY_LAUNCHER.
Bug: 176235889
Test: atest WmTests
Test: atest CtsWindowManagerDeviceTestCases
Test: manual: flash crosshatch, press back button on a launcher activity,
observe task is moved to back; press back on non-launcher activity,
observe task is finished.
Change-Id: I1cbf85f1a007aeedcb66b9343d182188bacc78e7
TODO:
* Color the new header icon
* Special style for phishing smart actions
Test: manual with notify2 app (for now)
Bug: 161333455
Change-Id: If6fdfe8347f06994662521d63fec64f2ee15ae8d
The logic in ag/5108931 was intended to suppress the next return
animation if it would cross a task boundary, while preserving return
animations in all other cases. However, it accidentally caused
excessive suppressions in the case of repeated back button presses. The
reason is that although the sending activity is indeed only topOfTask
when moving forward cross-task, it's *always* topOfTask when pressing
back, so the state of the sending activity doesn't contain sufficient
information to feed this logic.
This patch changes to suppress when the receiving activity is task root,
which is a more direct and reliable signal. (By definition, the return
transition from an activity will cross a task boundary if and only if
it's the task root.)
Fixes: 177780499
Test: New test in ag/13593522
Change-Id: Ia5751da6122dc1ddb557f45318712185fa0b3df9
Add hidden ConversationListener and registration in PeopleManager
for People Tiles to register a listener to individual
conversation storage changes for targetted updates.
Test: DataManagerTest, PeopleServiceTest, PeopleManagerTest
Bug: 178792356
Change-Id: I0cab6913c138d6ac515fed74741dd62bf967772b
Added public APIs to call into WindowManagerService, which will then
call into DisplayHasherService in mainline. Also, renamed to DisplayHash
Test: atest DisplayHashManagerTest
Bug: 155825630
Change-Id: I1e10a773fba9471dff41894389e0a9508446d3cc
Revert "Implement local color extraction"
Revert "Implement local color extraction"
Revert submission 13553866-wallpaper-local-color-extraction-sc-dev
Reason for revert: b/180490435
Reverted Changes:
I5755525f9:Wallpaper Local color sampling
I5487881c0:Implement local color extraction
Icbab7c6c2:Implement local color extraction
Change-Id: I1cf02a24555167165959e5c4f0bd25b655bd6b6e
Added a new permission to protect the alarm manager APIs setAlarmClock
and setExactAndAllowWhileIdle. The change will apply to apps targeting
API S and above.
- The permission will be granted by default to apps that request it.
- This will be a user facing permission as these APIs allow for exact
scheduling, and an app should generally only use them when scheduling
work on behalf of the user. This means the user can revoke it when they
want.
- Alarms set with this API will also be allowed to start FGS from the
background.
- Quota on exact, allow-while-idle alarms has been relaxed generously,
while alarm-clocks remain totally uninhibited.
- Apps that are exempted from battery via <allow-in-power-save> in the
sysconfig, can still use exact, allow-while-idle alarms without the
permission, but with lower quota.
- Inexact, allow-while-idle alarms do not require this permission, but
will *not* be allowed to start FGS from the background.
- A new API to query the state of this permission is included.
Test: atest FrameworksMockingServicesTests:com.android.server.alarm
atest CtsAlarmManagerTestCases
BYPASS_INCLUSIVE_LANGUAGE_REASON=Existing APIs
Bug: 171306433
Change-Id: Ifb6a3f3c42316b1c83fe6960920501f5e0ee51f2
