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
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
Apps delivered as multiple split APKs must have identical package
names, version code, and signatures. However, developers may want
to iterate quickly on a subset of splits without having to increment
the version code, which would require delivery of the entire app.
This change introduces "revision codes" which can vary between
split APKs belonging to the same app. An install is valid as long
as the normal version code is identical across all splits. Splits
can be added/removed to an app over time, but if a split is present
across an upgrade the revision code must not decrease.
Since system apps could have been updated with splits, only revert
to the built-in APKs if the version code is strictly greater than the
data version. Also fix bug to enable inheriting from system apps
when adding splits.
Bug: 18481866
Change-Id: I34d8e14c141a8eb95c33ffe24b4e52d6af5c8260
Bug 18399514
Adjust the contentUri to contain the caller's userId so that when
the phone process tries to open the Uri, it will open the provider
on the correct user.
Also make sure the Uri grants are properly qualified. We only need to grant
permission for sending. Receiving an MMS is always done by the primary
user and doesn't need special permissions. Move various permission grants
from the SmsManager to here.
Change-Id: Ib192f651ab05db9f07e9e6245bb343ed7a55b18e
