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
If the lock screen is not shown, then let activities keep running
while dozing. This is important to support ambient mode on watches
since it allows the home app to keep running.
To make this possible, we need to inform the activity manager about
the exact wakefulness state, not just the overall boolean
interactive state.
Bug: 18284212
Change-Id: Ia35c99127ce51ffc178f3a2f51fca67d24061c71
It seems we were sort of trying to do this by forcing the AsyncTask
static initializer to run at certain times but it was not sufficiently
reliable. In particular, this resulted in occasional system
server crashes.
Bug: 18192406
Change-Id: Ief73210c60e7680fbed6df74e3e58809b7ec7e4d
We're now shipping devices with several partitions which may end up
mismatched, causing subtle runtime issues. To help manufacturers and
users catch this case, show wanring when we detected mismatched
fingerprints.
Bug: 18357469
Change-Id: I897d7ee8cbf3b8042d3d7d282afab277d242ed3f
There are many cases in real world applications where it is desirable
to continue processing messages on the Looper even when most other
messages have been suspended by a synchronization barrier pending
completion of the next drawing frame on vsync.
Internally the framework is able to mark certain messages as being
independent of these higher level synchronization invariants by
flagging them as asynchronous.
This change exposes the existing function and improves on the
documentation so that it is clearer what is meant by asynchronous.
Bug: 18283959
Change-Id: I775e4c95938123a364b21a9f2c39019bf37e1afd
installd can then clear the ".booting" marker from the dalvik-cache
(owned by root). This marker is used to detect boot loops.
bug: 18280671
Change-Id: I878f1463c7f523892605c17b980a51ac3b6645e2
The setting was previously exposed in IPowerManager but it
doesn't need to be there.
Bug: 17656076
Change-Id: If3ed0cbe89f67c60aa00376be0c54b1bd9656144
