Add a listener to listen for changes in the Task stacks to preload thumbnails from the
system. In addition, reduce the amount of synchronous work done in activity creation
and first measure/layout passes.
Change-Id: I8bd9155d7a05e89c190a20429acff69a17808208
This makes the following changes in behavior:
-We will only cache a pending intent for a session if it reaches the
one of the playing states.
-If a previously priority session is removed the next session only
gets priority if it is in a playing state. Otherwise we use the removed
session's PendingIntent.
-The last session to have been playing or to have been added gets
priority after any currently playing sessions, but only if it is still
in the list of active sessions.
-We will only use a session that isn't playing and isn't the most recently
playing/added if we don't have a PendingIntent from the last playing session
to fall back on.
bug:18589421
Change-Id: I650c56a782bb1f1d5e64d7574a7d2387606f3b17
The code in place was inappropriately treating all recurring alarms
as non-wakeup for purposes of deferral. Worse, it was overriding the
"this deliverable batch of alarms includes a wakeup alarm" bookkeeping,
so could potentially cause inappropriate deferral of even standalone
wakeup alarms.
Bug 18591317
Change-Id: I2a62ed4badcaeb549c1ac4f086014aa829e45427
...not noon-or-midnight. Fix the initial fstrim delay to properly refer
to midnight rather than ambiguous 12-hour "zero" so that fstrim job
consideration always starts overnight rather than possibly at the following
day's noon, depending on when the device was booted.
Bug 18076397
Change-Id: Ife3cd5bdeb14c7832b6e2a2de88dcfd1ba731b67
In SQLite, if a sort order is not specified then the ordering is
undefined. In pre-L, SQLite would order accounts by the primary key.
But in L, the newer SQLite version appears to be ordering accounts by
the name.
Bug 18453759
Change-Id: I6bf2b0de59eca4c69472b4279b9e4194c3d3471e
The basic principle is: if an app's traffic could possibly go
over a network without the app using the multinetwork APIs (hence
"by default"), then the status bar should show that network's
connectivity.
In the normal case, app traffic only goes over the system's default
network connection, so that's the only network returned.
With a VPN in force, some app traffic may go into the VPN, and thus over
whatever underlying networks the VPN specifies, while other app traffic
may go over the system default network (e.g.: a split-tunnel VPN, or an
app disallowed by the VPN), so the set of networks returned includes the
VPN's underlying networks and the system default.
Specifically:
1. Add a NETWORK_CAPABILITY_VALIDATED bit to NetworkCapabilities.
2. Add a hidden API to retrieve the NetworkCapabilities of
all default networks for a given macro-user.
3. Modify the status bar code that used getActiveNetworkInfo to
determine which network was active, and make it consider all
validated networks instead.
4. Because the set of active networks depends on which VPN app
the user is running, make the status bar re-evaluate the
networking situation when the active user changes.
Bug: 17460017
Change-Id: Ie4965f35fb5936b088e6060ee06e362c22297ab2
Since we have a status icon for SoftAP, the persistent
notification is no longer necessary.
Bug: 17318034
Change-Id: I0c8acb643fc032c9b12feb3a9a155cf95e58eca1
Don't clear notification LEDs when seeing notifications on the
lockscreen.
Also fix a bug where the LED didn't continue flashing after
the screen turned off.
For devices with doze capability, ensure that the LED continuing
to flash after screen off doesn't cause an immediate pulses, but
delay the first pulse by 10s.
Bug: 15449039
Change-Id: Id34d51a2c91ceaf069e49add1ab690bb855f9638
When WiFi's score drops and then comes back up we would previously linger
WiFi but forget to cancel the linger timeout, so 30s later WiFi would
unexpectedly tear down. Also, make sure this is only done for created
Networks as "created" is the signal to initialy match Networks and requests.
bug:18169560
Change-Id: Ia69b110f6473371e556c60b950253758e023b7aa
When a listener requested HINT_HOST_DISABLE_EFFECTS,
fire ACTION_EFFECTS_SUPPRESSOR_CHANGED when it's removed.
Bug: 18578756
Change-Id: Ia20793f17fc376130f370e736efad8b15f0cfa6d
Describe the currently installed splits, both in normal dumpsys
output and in checkin output. Also include revisionCode of those
splits when defined (non-zero).
Bug: 18576300
Change-Id: Ie8140961fb7b9e0ed23fd6bc267157aab075dd78
Currently, TvInputManagerService notifies the initial state of each
input via TvInputManagetCallback#onInputStateChanged after TvInputManager
is created. However, this is racy because the client may call methods
like getTvInputState() before the initialization.
This patch makes sure that the client gets the control when the initialization
finishes completely.
Bug: 18419452
Change-Id: I5d8141c20984013e68f2809120710c670557c9ad
- Remove 'oneway' from IHdmiVendorCommandListener.
- Add flush() method to HdmiCecController.
- Use IoThread for HdmiCecController.
Bug: 18495592
Change-Id: I497f7b49e94dd4402058ecc89cb5b7a3d58bf1e1
If a whole-system restore operation failed at just the wrong point,
we'd wind up in the teardown code without a certain vital bit of it
having been initialized, and crash on the null pointer. Now we
recognize this failure mode and make sure not to do that.
Bug 18574450
Change-Id: Ifa2c10ce16bb3c6bc916ed7151c5fd51b7225691
Currently, if a network does not specify DNS servers, we default
it to using 8.8.8.8. This was done because the emulator did not
specify DNS servers. However, it causes queries to fail slowly,
instead of failing fast, on networks that do not have
connectivity to 8.8.8.8.
Bug: 18327075
Change-Id: I0df13ff4a17ee65e640be96695a3af31b020963a
When an app is moved from "/system/priv-app" to another location
during OTA update, the privileged flag should be removed.
(cherry picked from commit 76bf60ead8132b86436ebbba40eaa8f2c8bbe812)
Change-Id: I39feeac7ece89c28045d196ae69fc974b1c6510b
The display setting saved to disk were using a localized name for
the key. This is an issue if the user changes languages after the
display settings have been saved. We now use the non-localized
name for the display to access the settings if it is available,
else we fall back on the localized name.
Bug: 18190800
Change-Id: I837c06a8935df10727229a1aa2bb6eeb3953707f
If AppWindowToken.allDrawn is changed from true to false an
additional layout pass is required to change WindowStateAnimator.
mDrawState from READ_TO_SHOW to HAS_DRAWN.
Fixes bug 18456175
Change-Id: Iddac657e5303a4154309889417374c0c6994c4df
Drop the minimums back down to their old values.
Revert what I think was a mistake in bumping up the last two
maximums to the same value as was being forced for 64 bit.
Smarten the 64 bit adjustment to be relative to the values picked,
rather than hard-coded.
Change-Id: Ibee9625073469ad4722a1b6684c9fb2b9f0a4681
The current heuristics depend on devices being alive at midnight+ in
order to run periodic background fstrim operations. This unfortunately
means that people who routinely turn their devices off overnight wind
up with their devices *never* running fstrim, and this causes major
performance and disk-life problems.
We now backstop this very-friendly schedule with an increasingly
aggressive one. If the device goes a defined time without a background
fstrim, we then force the fstrim at the next reboot. Once the
device hits the midnight+ idle fstrim request time, then we already
aggressively attempt to fstrim at the first available moment
thereafter, even if it's days/weeks later without a reboot.
'Available' here means charging + device idle. If the device never
becomes idle then we can't do much without rendering an in-use device
inoperable for some number of minutes -- but we have no evidence of
devices ever failing to run fstrim due to this usage pattern.
A new Settings.Global element (type 'long', called
"fstrim_mandatory_interval") is the source of the backstop time. If
this element is zero or negative, no mandatory boot-time fstrim will
ever be performed. If the element is not supplied on a given device,
the default backstop is 3 days.
Adds a new string to display in the upgrading dialog when doing
the fstrim. Note it is too late for this to be localized, but since
this operation can take a long time it is probably better to have
it show *something* even if not localized, rather than just sit there.
Bug 18486922
Change-Id: I5b265ca0a65570fb8931251aa1ac37b530635a2c
This change is to start Mountservice before starting
performBootDexOpt, as in one case, in performBootDexOpt
when system upgrade happens, StorageManager will be started to
get the low threshold of DataDir. But, at this point, as
Mountservice is still not up, StorageManager will end up
having a null object of Mountservice.
Change-Id: If2b5e1b58e7d2a72c6313f196e98a68738295ec6
