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
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: I6dec474266faa5de67449c1bbe6ef30791e5ecaa
Stabilize mapping between ringer-mode=silent and zen=priority
by keeping track of two ringer modes:
- Internal ringer mode: Used for underlying stream muting
- External ringer mode: Reported to clients
The mapping between external ringer mode + zen is:
- normal = all
- vibrate = all
- silent = priority (read-write) or none (read)
Changes include:
- Remove "zen check" from audio service, back to audio
service having no knowledge of zen.
- Maintain a new external ringer mode in audio service,
this is the ringer mode reported through AudioManager
to callers, also mapped to the change intent.
- Introduce a "ringer mode delegate" to the local
audio manager interface, responsible for observing
external / internal mode changes, and making changes
if necessary.
- Internal ringer mode changes are still interesting
to the volume dialog, wire up a callback through
the existing IVolumeController interface.
- On devices without vibration, the mapping is the same
but since no ringer mode change is possible, disable
the icon toggle and remove the mute icon when volume=0.
- On devices with vibration, volume down presses should
pulse the vibrate icon (and vibrate) as a hint that this
is as low as the device can go using the keys. Since
the mechanics are similar to the existing zen=none hint,
pull into shared helper.
- Log ringer mode changes to the zen log, include calling
package information for issue diagnosis.
- Include whether vibration is supported in the audio service
dump.
- Update the status bar icon policy to use the internal ringer
mode, not the external mode (for vibrate icon).
- Update the "Muted by <x>" logic, include current suppressor
in dumpsys, ensure suppression icon is enabled & !clickable,
regardless of zen mode.
Bug: 17884168
Bug: 15471679
Bug: 16824970
Change-Id: Ia7d3bb23ce6d1e37b24fb6521d1c1ab9bb8f60c0
Allows ManagedProvisioning to determine whether there's a
challenge and thus whether to disable NFC provisioning.
Other implementation option: new hidden boolean API method.
Can't think of benefit of new API method "isBlockInUse", other
than doesn't leak PDB size and is more explicitly tied to the
use case. Open to either impl if anyone has opinions on the matter.
Bug: 18508767
Change-Id: I28d2eb5a0837ff85cb91f140b17ce1dd843fe9d6
Setting up a managed profile should have included a step to warn about
this sort of thing already. As the user should trust the profile owner
anyway it's hard to argue this warning is needed.
Bug: 18224038
Change-Id: Ie86ba26851af726c0dec30eb9c32894ed6bb4a00
A recent change sets the active path ahead of calling
updateActiveInput. Removes the check between new and active
path as it is always successful thus stops the flow.
Bug: 18506537
Change-Id: I29471ffc6194baa1fad62063f1d192caa9000afd
Fix permissions on packages.list and package-usage.list to only
allow read access from the package_info GID.
Bug: 18473765
Change-Id: I9b9ef13f4a00a8355619bbcdacc836f9abfa0376
