Settings is using a MemoryIntArray to communicate the settings table
version enabling apps to have up-to-date local caches. However, ashmem
allows an arbitrary process with a handle to the fd (even in read only
mode) to unpin the memory which can then be garbage collected. Here we
make this mechanism fault tolerant against bad apps unpinning the ashmem
region. First, we no longer unpin the ashmem on the client side and if
the ashmem region is purged and cannot be pinned we recreate it and
hook up again with the local app caches. The change also adds a test
that clients can only read while owner can read/write.
bug:28764789
Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
am: fec0d188c1
* commit 'fec0d188c166e5a2c517f4494e83c1db11b31c68':
Don't show new-window item in Downloads per Gabe.
Change-Id: Ic8d6afb5e38c1ded0ca7750be4ac4822aefbe6c1
Also, fix regression...don't show "internal storage" option in Downloads.
All other modes, fix inconsistencies in presentation of
internal-storage/new-windows commands by eliminating launch mode inference.
Update VolumeInfo and MTP provider to send correct launch mode extra.
Bug: 28691735,28695347
Change-Id: Ic480925f4c8f1beee4da104a2259c1ce5f28a6a1
For secondary users, a SecurityException is thrown instead of UnsupportedOperationException.
BUG: 28294786
Change-Id: I6402b856eeb02c4c1d940606ae7e69f3ae9cb45d
Adding missing items about MIME type and account type to the
"integration with the Contacts Provider" section.
Bug 28295510
Change-Id: I890458e62a714519be70e930fd53315c141ba354
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
am: 1d3c594
* commit '1d3c59457c9bcf30e6ecb898e64d9d9725e7803e':
Make isCaptivePortal perform both HTTP and HTTPS probes.
Change-Id: Ic58f5be8dce42c17213ef261f348eda31c6c11e7
am: f71d7fe
* commit 'f71d7feef22db9e0cab2f32edc7440aedb86fdfe':
Ensure local settings caches are not stale
Change-Id: I356b9ad0b6dc1e91bfad140de1b9fc79ab6efef3
We used the system proterties as a shared memory mechanism
to propagate information to local settings caches when the
content has changed and the cache should be cleared. The
system properties are unfortunately updated asynchronously
leading to cases where clients may read stale data.
This change adds a simple int array data structure backed
by shared memory which guarantees individual values are
atomically read and updated without memory tear. Multi-
index opearations are not synchronized between each other.
The settings provider is using the new data structure to
propagate the settings generation which drives when caches
are purged.
We have a single memory array keeping the generation for
different settings tables per user. Since memory array is
not a compact data structure and the user space exceeds
the memory array size we use an in-memory map from keys
to indices in the memory array where the generation id of
a key is stored. A key is derived by the setting type in
the 4 most significant bits and the user id in the 28 least
significant bits.
The mapping from a key to an index is cleared if the user is
removed and the corresponding index in the memory arry is
reset to make it available for other users. The size of the
memory array is derived from the max user count that can be
created at the same time.
bug:18826179
Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
To support moving DownloadManager, add new JobScheduler network type
constraint that matches "any network except roaming." Also add an
API to get a specific JobInfo by ID.
Since the default network can be different on a per-app basis, and
individual apps may be blocked due to app standby, evaluate job
connectivity constraints on a per-UID basis. To implement this
cleanly, add NetworkInfo.isMetered() to match the isRoaming() API.
Add new DownloadManager APIs to support charging and device idle
constraints, which are plumbed through to JobScheduler under the
hood when scheduled.
Add filtering to JobScheduler dumpsys to omit noisy details for
packages the caller isn't interested in.
Bug: 28098882, 26571724, 19821935
Change-Id: I09ca7184ef7ce6adba399f579d415a5fb2ea6110
am: 790699d
* commit '790699db64ee18d143cd9813e91044fcc5a26713':
Doze settings example not matching real keys
Change-Id: I5c1a0757f5db2ba3ca2fcf37e77641ac820fbe6f
This undoes the automerger skip which occured in
commit e740c84dc3 and
replays it as a standard (NOT -s ours) merge.
Change-Id: If5a47be26f73d6a0735c425cd66310a3e2a89086
The keys used in the example for the Doze timeouts does
not match any real key. To avoid confusion the example
should match the existing keys.
Change-Id: I0306c542dac9e38aea7d172a3e0f7472d327c73c
Per feature council decision, the multi-endpoint APIs will be @hide for
the N release.
Bug: 28196918
Change-Id: Ia80b089bc754ce87ca208382eb79442b5265844d
