Whether the backup service supports multi-user is now configured in a
Global setting: backup_multi_user_enabled
This allows us to develop multi-user support hidden behind a flag. In a
future CL, we'll also gate the types of users we support.
Also create basic infrastructure for starting the service for a newly
unlocked user (currently a no-op).
Bug: 120212806
Test: 1) atest TrampolineTest
2) adb shell settings put global backup_multi_user_enabled 0;
unlock system user -> verify service started;
unlock user 10 -> verify service not started;
3) adb shell settings put global backup_multi_user_enabled 1;
unlock system user -> verify service started;
unlock user 10 -> verify service started;
Change-Id: I048e017cfa6148097cebe2eb2916d1b53c53d3b0
In the new isolated storage world, apps can "contribute" media that
belongs to the user, which normally means it won't be deleted when
that app is uninstalled. However, we're anticipating that some apps
might abuse this API to preserve data the user actually wants to
delete during uninstall.
This set of changes introduces new APIs to measure and delete these
contributed media items, along with tests to verify.
Bug: 116344240
Test: atest android.provider.cts.MediaStoreTest
Change-Id: Ib740e0ea74378569572cb17640ef607aaa6baf1f
Accepting only ContentResolver arguments was quite limiting, so use
the newly created super-interface ContentInterface, which lets
callers use a ContentResolver, and ContentProviderClient, or even a
specific ContentProvider.
This is a safe API change, since we're accepting a more-general
argument, and existing API users can continue passing ContentResolver
to these methods.
Bug: 117635768
Test: atest DocumentsUITests
Test: atest android.appsecurity.cts.DocumentsTest
Change-Id: I8f0cd1335c9b763dd81eeb237fb0517e9073b625
Existing APIs that accept a ContentResolver are too restrictive when
the caller has their own ContentProviderClient already bound and
configured, so we're in the market for a solution to open those
existing APIs to accept a wider range of inputs.
The solution we've come up with is to introduce a super-interface
which contains the common ContentProvider APIs, and then make
ContentProvider, ContentResolver, and ContentProviderClient all
implement that interface for consistency.
After this change lands, we can then safely relax existing APIs to
accept this new ContentInterface, offering a clean path to solving
the problem outlined above.
Bug: 117635768
Test: atest android.content.cts
Test: atest android.provider.cts
Change-Id: Ic5ae08107f7dd3dd23dcaec2df40c16543e0d86e
Exempted-From-Owner-Approval: keep tests working
Update ANGLE developer options to allow selecting the OpenGL driver
(default, ANGLE, native) for each app as well as forcing ANGLE for all
apps.
Bug: 118384925
Test: Verify the default/ANGLE/native values are saved and applied and
used by the loader.
Change-Id: I189889b9b780eabe812298c0dd02838f70f97a03
Bunch of changes:
- Split public SmartSuggestionsService info ContentCaptureService and
AugmentedAutofillService
- Renamed 'intelligence' packages to either 'contentcapture' or
'autofil.augmented'
- Renamed internal packages and classes.
- Changed permissions, resource names, etc...
- Moved Augmented Autofill logic from IntelligeceManagerService (R.I.P.) to
Autofill.
- Optimized IPCs by passing a String instead of the InteractionSessionId
(that also solves the view -> service dependency).
Test: atest CtsContentCaptureServiceTestCases \
CtsAutoFillServiceTestCases \
FrameworksCoreTests:SettingsBackupTest
Test: manual verification with Augmented Autofill Service
Bug: 119638877
Bug: 117944706
Change-Id: I787fc2a0dbd9ad53e4d5edb0d2a9242346e4652d
support command line debug tool.
Test: atest FrameworksCoreTests:SettingsProviderTest
Further tested manually via command line (see ag/5613024)
Bug:109919982
Bug:113101834
Change-Id: Ib0d9e4c6d806ec3521ac49b8c05fbdad8b5b13d7
Create Global.SMART_SUGGESTIONS_IN_NOTIFICATIONS_FLAGS. This will
contain flags that control the automatic generation of suggestions in
notifications (smart actions and smart replies).
Bug: 111437455
Test: atest SettingsBackupTest
Change-Id: I91252d3e0f3d51000f6115a520d7054832fda1ce
Grant tests the "write_settings" appop they needs to run, and test
against well-known key.
Move away from FileCopyHelper, which uses deprecated
MODE_WORLD_READABLE mode. Define TestSRSProvider to get a valid
provider to notify against.
Bug: 120429729, 120577010
Test: atest CtsProviderTestCases
Change-Id: I5b78ee2df66562f1356aa36c3c92781c5aca5d43
1. Expose @Public for query arguments and flags.
2. Expose @SystemApi for related manageMode apis and some
related storage flag in Root.
3. Add new isChildDocument method to support ContentResolver
parameter and expose it @Public.
4. Expose @Public for getDocumentMetadata related methods.
Bug: 117634543
Test: make, make api-stubs-docs-update-current-api,
Change-Id: Ib172d46ba9727c35277fb285d3a09380fe106697
Use the argument to decide whether the files that have been
added to MediaStore should be excluded. If the value is true,
exclude them. Otherwise, include them.
Bug: 119390918
Test: manual
Change-Id: I245e4303a265a95b30400083841c593b66c4d960
In terms of the feature of USB overheat warning, SettingsProvider needs the implementation for the integration.
Bug: 118794842
Test: Build, flash and boot, verify
Change-Id: I41aacd5a7ed7ab1ce0212e7d2520e3c51d7d3bc1
Initially it was defined as secure Settings, but the proper way is to let the
OEMs set it by overlaying a framework resources, which an option to temporarily
override that setting using a Shell cmd (so it can be changed on CTS tests).
This CL also changes how the service can be explicitly enabled / disabled at
the time the system starts, so it can be disabled by a server-push in case of
emergencies (and also manually enable by developers when running the CTS tests
on AOSP builds).
Bug: 119776618
Bug: 111276913
Bug: 117779333
Test: adb shell settings put global \
smart_suggestions_service_explicitly_enabled true && \
sleep 10s && \ adb shell stop && adb shell start \
atest CtsContentCaptureServiceTestCases
Test: atest FrameworksCoreTests:SettingsBackupTest
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break
Test: m -j SettingsProvider
Change-Id: Ibd1bba0c0d534b4b6344516d8ff893142785a57a
The new ACCESS_MEDIA_LOCATION permission is designed to protect
the location metadata of items the caller doesn't own, but we can't
easily perform partial filtering of metadata from returned Cursor
objects based on per-row ownership, so we're forced to outright stop
indexing and returning location metadata via queries.
Apps can still easily obtain location metadata using ExifInterface.
Bug: 111892141
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I4d99e6aa7d94bb0e7a50ce86eb1ab0f1ed142d4a
AJUR can't support mixed filters of class and package. There are 2 other
TEST_MAPPING files containing about 6 tests using filter on package.
Once b/117880789 is fixed, we can add this TEST_MAPPING file back.
Bug: 120462824
Test: None
Change-Id: Iafa0286c18f2c6fd77c5b603a72882e710cef6ee
When the caller doesn't hold the ACCESS_MEDIA_LOCATION permission,
any location Exif tags should be redacted for privacy reasons. We
still allow unredacted raw file access if the media is owned by the
calling app, since they should be able to see data they contributed.
Certain backup apps really want to see the original contents without
any redaction, so provide them a setRequireOriginal() API so they
get a strong exception whenever the original bits can't be provided.
Add the ability to open a redacted file for read/write access by
stopping redaction for any ranges that have been overwritten with
new data, along with tests to verify this behavior.
Extend "content" tool to bind null values.
Bug: 111892141
Test: atest android.os.RedactingFileDescriptorTest
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I47b220036a712d9d49547196b90e031b10760f84
Change this constant to @SystemApi for SUW unbundling.
Bug: 117749852
Test: a11y CTS & unit tests, and SettingsProviderTest
Change-Id: I3b88a024d009a28fa8e7c02fe2ef292c657b44be
The settings are used to reduce the runtime of the location access
permission controller tests.
Bug: 120303361
Test: atest CtsPermissionTestCases:android.permission.cts.LocationAccessCheckTest
atest --test-mapping frameworks/base/core/java/android/provider/:presubmit
Change-Id: I47ed218dc0a300f73a1c0308fce60b61e6a423b0
A toggle will be added in Settings -> Work profile settings for user
to control this setting.
Bug: 118445542
Test: .manual
Change-Id: If8b882dd101688f35fb117d83a801b5c80aab367
and basic rules for enforcement
The setting is on by default. It can be switched off with
a developer option (see accompanying commit) or
"adb shell settings put global background_activity_starts_enabled 0".
The setting is wired into ActivityStarter. When it's switched
off, all unsupported background activity starts are aborted and
it's currently manifested with a toast for quick feedback.
Only basic policy rules are added for now:
0) is it one of the most important UIDs?
1) does the calling app have any foreground activity?
2) is the calling process important enough to always be able
to start an activity?
3) does the calling uid have any visible window?
The policy rules will be extended to allow for more use cases
in forthcoming CLs.
Most notable use cases not currently covered:
1) Notifications
2) Widgets
3) Shortcuts
4) Some of the most important system apps (e.g. com.android.vending)
5) Accessibility services and similar (IMEs covered thanks to
visible window exemption)
6) Recents button double tap to open the previous app
See bluedoc for some more.
Bug: 110956953
Test: atest WmTests:ActivityStarterTests
Manual test:
(on) observe all activities are started as they used to be
(off) starts not satisfying one of the above rules are aborted,
a toast specifying callingPackage is shown instead
Change-Id: I1a3e14828c96f005d975ef6998f3bda678ccab29
add native_flags_health_check_enabled to Settings.Global. It is used
to receive the corresponding experiment flag from P/H.
Bug: 119627143
Test: manual on device
Change-Id: I980f73925818a5cb6f756d78bad324bafefc3784
If dns resolver on a network get consecutively timeout then it
is a strong signal that the network is no longer usable.
Reevaluate the network once it's data stall suspected
Test: 1. runtest frameworks-net
2. SettingsBackupTest passes
2. Run on wifi w/o internet capability
Bug: 112653893, 113916551
Change-Id: I74287b174d933f97a91fa1529b1809856ac3b38d
