MediaStore has long suffered from race conditions around creation
of new media. For example, if developers write raw files before
inserting the MediaStore item, an in-progress media scan might pick
up the file before they could insert it. Conversely, if developers
insert the item before writing the files, backup apps get confused
about the file not existing yet.
In addition, the new storage model in Q means that apps can't write
raw files directly to disk, so they need to insert the MediaStore
item first.
To solve this collection of issues, this CL introduces first-class
APIs for contribution of new "pending" media, which includes hiding
the pending media until explicitly published. Apps can safely
resume pending sessions if they crash and restart, which is useful
when the media item is coming from a flaky network. Apps can also
publish progress information about pending media, such as when a
panorama is taking several seconds to process.
Bug: 115377970
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I6adee3c4ad1fb9db94906dd1293caaa1a09c6da0
This allows loading layers for GLES and Vulkan at the
same time by adding a GLES specific setting:
GPU_DEBUG_LAYERS_GLES
which mirrors the existing setting:
GPU_DEBUG_LAYERS
The Vulkan and GLES loaders now scan distinct layer
lists, correcting an issue that would prevent Vulkan
from loading when it failed to find GLES layers.
Bug: 110883880
Test: Load a GLES layer when running ANGLE with Vulkan backend
Test: cts-tradefed run singleCommand cts -m CtsGpuToolsHostTestCases
Change-Id: I370be4ce6fdde9e95989eb1f274add8b5790263e
Add a flag to enable/disable this feature.
Bug: 64312268
Test: compile
Test: First use "adb shell settings put global wifi_pno_frequency_culling_enabled 1" to test turning on the feature.
Test: Then test "adb shell settings put global
wifi_pno_frequency_culling_enabled garbage" does not turn the feature
off.
Change-Id: Ia6cd0d3c9888d7b2e0513b51fc4ad92c3eb171de
As part of creating a "default gallery" app in Q, we need to define
the expected contract of how recently captured media can be reviewed
by the user. Mirrored off the existing CAPTURE intents.
The Q storage work will start calculating SHA-1 hashes for each
media item to identify them in a stable way.
API to list all available volume names on the device, which includes
all attached shared storage devices, like SD cards.
Clean up all Uri creation to use Uri.Builder to ensure that incoming
volumeName values are escaped correctly.
Bug: 111268862
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ib7e5bf814b407f4d611767d2a5d26ccfe6d8d034
The existing queryRecentDocuments have a hard limit 64. However, case
like ARC++ wishes to have a more flexible limit that can be passed as an
extra parameter. This new API will gracefully degrade to the old API to
maintain backward compatibility with old providers.
Bug: 111288304
Test: manual test (patched the MediaDocumentsProvider, and test calling
the new API):
1. Test that passing Bundle with QUERY_ARG_LIMIT=5 is honored and
returned is limited to 5.
2. Test that passing null will release the limit to default 64.
3. Test that removing MediaProvider implementation for new method and
implement the old method will automatically redirect the call to old
method (backward compatible with old providers).
Change-Id: I37b1785b94f3e9cf09128fbf1e8779a4447fe7a9
As part of creating a "default gallery" app in Q, we need to define
the expected contract of how recently captured media can be reviewed
by the user. Mirrored off the existing CAPTURE intents.
The Q storage work will start calculating SHA-1 hashes for each
media item to identify them in a stable way.
API to list all available volume names on the device, which includes
all attached shared storage devices, like SD cards.
Clean up all Uri creation to use Uri.Builder to ensure that incoming
volumeName values are escaped correctly.
Bug: 111268862
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I460593466d85ff052fd157d8fd784e7ac5b25d78
User Setup related fields in Settings indicating the setup
personalization state are now exposed.
Global Settings fields indicating whether the device is in demo mode,
a password is required to decrypt the device, and if mobile data is
enabled for provisioning are now exposed.
Various Secure Settings fields are also now exposed. They indicate
information about doze, user setup information, lock screen
notification settings, assist gesture setup, and whether a suggested
action was completed.
All of the exposed fields require the WRITE_SECURE_SETTINGS permission.
Bug: 116689780
Test: manual (run setup wizard)
Change-Id: If8a96cca216b1d3e3b9329a3f4695caf9f3f248a
API refactoring:
- Replace Font.getWeight()/getSlant() with Font.getStyle().
- Change Typeface.CustomFallbackBuilder.setItalic() to setSlant()
Implementation refactoring:
- Add hidden builder API for asset manager with cookie. The cookie is
internal, so hide the API as well.
- Replace createFromResources with Typeface.Builder
- Reimplement Typeface.Builder with Typeface.CustomFallbackBuilder
Ground work for b/114479228
- Keep list of FontFamily in the Typeface.
Bug: 114479228
Test: atest CtsTestCases
Test: atest CtsGraphicsTestCases
Test: atest CtsWidgetTestCases
Change-Id: Ifaaa58ddea147644a93158aa075394c2f645617c
Also create a new MANAGE_ACCESSIBILITY permission to
perform the shortcut.
Bug: 116118615
Test: make, activate accessibility shortcut
Change-Id: Ic65a0cdf7393429e14cb98f4fb0734d20069b05a
The API is hidden.
The intent opens digital wellbeing properties for an app.
Bug: 118319143
Test: Building Android
Change-Id: I0579f8bd024fd8eaae46d1b387e993992dabc455
As part of the storage changes in Q, we're removing the ability for
apps to directly access storage devices like /sdcard/. (Instead,
they'll need to go through ContentResolver.openFileDescriptor() to
gain access.) However, in several places we're returning raw
filesystem paths in the "_data" column. An initial attempt to simply
redact these with "/dev/null" shows that many popular apps are
depending on these paths, and become non-functional.
So we need to somehow return "_data" paths that apps can manually
open. We explored tricks like /proc/self/fd/ and FUSE, but neither
of those are feasible. Instead, we've created a cursor that returns
paths of this form:
/mnt/content/media/audio/12
And we then hook Libcore.os to intercept open() syscalls made by
Java code and redirect these to CR.openFileDescriptor() with Uris
like this:
content://media/audio/12
This appears to be enough to keep most popular apps working! Note
that it doesn't support apps that try opening the returned paths
from native code, which we'll hopefully be solving via direct
developer outreach.
Since this feature is a bit risky, it's guarded with a feature flag
that's disabled by default; a future CL will actually enable it,
offering a simple CL to revert in the case of trouble.
Bug: 111268862, 111960973
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ied15e62b46852aef73725f63d7648da390c4e03e
Add new string in Settings. To indicate which app is default
call screening, similar to default dialer application setting,
store this in the system settings provider.
Bug: 118416082
Test: atest SettingsBackupTest pass.
Change-Id: I39f81b31a68ee2dbb056ff935f8dea0f51720017
Upcoming changes will prevent apps from reading "_data" columns
directly, which is required to convert between DocumentsProvider and
MediaProvider Uris. To solve this, delegate the call() through
MediaProvider, where it can perform the "_data" lookup on behalf
of the caller.
Also add new getMediaUri() call to offer symmetry.
Bug: 111960973, 117627072, 110961701
Test: atest android.provider.cts.MediaStoreUiTest
Change-Id: I53c640704d86047d7a4bf1702aca027873395abf
Add keys for color aspects to VideoColumns in MediaStore.
And standard, transfer and range is stored to database.
Bug: 114329709
Test: put hdr/non-hdr contents and check media db
Change-Id: Id4bf27a35720f5cf5a60f08eb3f30314e1a1a167
This is disabled by default and leaves time (1 min) for processes to
finish running only if there are processes currently running, otherwise,
it goes into deep doze immediately.
Bug: 79955941
Bug: 109934270
Test: Turn on Battery Saver, enable quick doze feature, turn off screen
also run `atest BatterySaverPolicyTest`
also run `atest com.android.server.DeviceIdleControllerTest`
Change-Id: Iec0c8436134e18debfa4c71a8322a6c9cdb10846
* For some carkit will get the call history name to show its screen, But
the caller name is not into call history database.
* Add caller name into call history database for the carkit get correct
caller name.
Bug: 111968310
Bug: 117627934
Test: build pass, verify pass, Check call history after received different
type call (save number, not save number, private number)
Change-Id: Ic28320c0184e33aa934a9c9c82a6062f5ef44e2a
This allows TV Setup to refer to LAST_SETUP_SHOWN.
This is part of the migration of TV Setup into google.
Bug: 117955028
Change-Id: I71a4e276ee4dbcd3c878278d8ce870ede4430a07
Mark "_data" columns as explicitly deprecated, since they'll only
work for pre-Q apps.
Bug: 111268862
Test: manual
Change-Id: I86f597f1245cc255f6ee114957829763b1a76e4c
Obtaining a thumbnail for a Uri requires opening it with the slightly
obscure openTypedAssetFileDescriptor(), passing in "image/*" with the
right Bundle of EXTRA_SIZE to hint the target area on screen, and
defensively scaling any returned results.
This is pretty tedious to get right, so offer a convenience method
that does all this for the developer. Internally uses ImageDecoder
to follow best-practices, and replaces older getDocumentThumbnail()
implementation by delegating to this one.
A future CL will teach ImageDecoder about how to read any embedded
EXIF thumbnails, including any required rotation.
Bug: 111268862
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I5c9c09ddf9b480f3b5c6ade0a078cccb68de2f2b
If a calling package does not meet the new requirements for device identifier
access the calling package and method will be logged and the previous
READ_PHONE_STATE permission check will be performed to grant access to the
requested identifier. This is to prevent additional breakage for apps that
currently require device identifiers but have not yet been granted the
privileged permission or carrier privileges.
Bug: 117585389
Test: cts-tradefed run cts -m CtsPermissionTestCases \
-t android.permission.cts.TelephonyManagerPermissionTest
Test: Manually invoked an app targeting pre-Q and verified access
to device identifiers with the READ_PHONE_STATE permission.
Change-Id: I03339486a2d6971b93472479b79959c888beba1e
