Make sure the core parts of JobSchedulerService are initialized
before we start creating the controllers.
Change-Id: I497df12f7e6fbd93581291ec691c4b45104d67d0
They don't need to be cleared and will remain valid as long as
the application itself hasn't changed.
bug: 28998083
bug: 29067239
Change-Id: I2e4a4ee1b168da81073b8e70b12918db592fe691
We now have a new settings key that provides all of the existing
tuning parameters, plus some newly redone ones for dealing with
different memory levels.
Changed the minimum batching for overall jobs from 2 to 1, so
we will never get in the way of immediately scheduling jobs
when the developer asks for this. We should now be able to rely
on the doze modes to do better batching of jobs for us when it
is really important.
Also work on issue #28981330: Excessive JobScheduler wakeup alarms.
Use a work source with scheduled alarms to blame them on the app
whose job they are being scheduled for, and add a check for whether
a job's timing constraint has been satisfied before considering it
a possible candidate for the next alarm. (If it is satisified,
the time is in the past, so we should not schedule an alarm for it.)
Finally clean up a bunch of the dumpsys output to make it easier
to understand.
Change-Id: I06cf2c1310448f47cf386f393e9b267335fabaeb
In override config for task we set Configuration#screenLayout field based on
initial global config + shrink to fit the area on screen given for this task.
However this field also contains information (like layout direction) that we
do not intend to override and it can be changed in global config separately.
In this case we need to update the override config with changes from global
config.
Bug: 28616488
Change-Id: I22673257621b3f9ae7933b37bd0fb9446c6042ea
We're seeing this a bunch, but the overhead from the WTF is concerning.
So turn it off. It means that somewhere there is a race in tearing
down the app, or maybe some place fails to call back in some scenario.
Bug: 28932059
Change-Id: Ice14ade95bb9377ad622d440fb022953ad51c34c
cause: ConfirmDialog is shown when prepareVpn(package, null)
returns false when the package is in always-on mode
We added the code in ag/949136 to stop app replacing app currently set to always-on.
Bug: 28941235
Change-Id: I370e56ad59332cc3fb722a98730fa73a97e26831
- Make sure to retain the state when divider goes through a configuration
change in order to avoid that nothing happens when entering multi-window.
Save the state in DividerState and use a handler that's independant of the
attached state.
- Don't allow home task to dictate orientation unless the docked stack is
minimized. This caused a lot of weird bugs because when docking a task,
home stack gets moved to front, and if home task is front of stack, it
temporarily might dictate the rotation but later not anymore so this
causes two rapid configuration changes which may cause a lot of weirdness.
Change-Id: I6a2308af893cd8413ee8801e5b964f6ddc0abd51
Fixes: 28943853
Also disables app pinning when the "return to call" button is pressed
and brings up the in-call screen when app pinning is stopped if there is
an existing call.
Bug: 28558307
Change-Id: I7672123bfa6ba6b5e960bd5166876c50425d3f76
bug: 28763785
related-to: 27989717
related-to: 28887408
Revert "Fix wallpaper crop during unlock animation"
This reverts commit 616c7c10b9ca461da44a1eead2a6cb8260c82b22.
Revert "Fix wallpaper cropped too soon when unminimizing dock"
This reverts commit f0b76b071c8434fbf4a76798e9cdd56ab67e523d.
Revert "Set final crop on wallpaper instead of intersect clip with stack bounds"
This reverts commit dcf0183cea1f93f20073cb04fa64f111ea880005.
Revert "Crop wallpaper windows to their current target stack bounds"
This reverts commit e6cb450b0db119d71601a8329bed380bb2b4e275.
In phone landscape, when the navigation bar is on the right,
and when the status bar is forcing the IME and NavBar, make
sure that the nav bar and IME don't overlap, even if the
NavBar is only transient.
Bug: 28914905
Change-Id: I22921f1aca7970c2d02dfd88408eb15c5b17151f
This scenario typically happens when the device is on Doze Mode and a
notification action is triggered from a Wear device.
In a nutshell, the workflow is:
- ProcessRecord has a flag telling whether a process has "whitelist
management" privileges.
- When NotificationManager binds a new NotificationListenerService, it
sets the BIND_ALLOW_WHITELIST_MANAGEMENT flag.
- On bind(), ActiveService asserts that only system apps can set that
flag.
- On computeOomAdjLocked(), ActivityManagerService sets the
ProcessRecord flag if necessary.
- Upon creating a notification, NotificationManager calls AM to mark its
PendingIntents as coming from a notification.
- When PendingIntentRecord sends it to the target, it checks if it's
from a notification and if so calls AM to do the temp whitelist.
- On unbind(), ActiveService removes the ProcessRecord flag if necessary.
Fixes: 28818704
Change-Id: I00d46036a2cbb73f7f733fd35bf0b743a02807a1
Force stopping the bound scoring service would not automatically
reestablished the binding.
Replaced the custom BroadcastReceiver with a more standard
PackageMonitor implementation that handles the same actions in
addition to force stop.
Also added a few more debug log statements as they were helpful
during my development.
BUG: 28930592
Change-Id: Ic36ea77deb5e2117edc201e97d71be63bdd4230d
IPv4 broadcast packets can be very common (e.g. every 2s) so they
need to be dropped in the general case. They also may be critical
for certain discovery protocols, so allow them through with APF
when the WiFi multicast lock is held.
Bug: 26238573
Change-Id: I03e09a2b9c779da5da775e78b95e9e0339720eaf
Always use the packages' derived instruction sets.
This fixes a bug where otas and background dexopt would only
look at one instruction set.
bug:28994818
Change-Id: I730b59d24943c71de30adb485a823fd79c6806a6
