Methods were moved from TimeZoneDetector to TimeManager in commit
02d943f44d. This commit updates comments
to track.
Bug: 159891384
Test: None - comment change
Change-Id: I96c4c248f98041f88ff3372b575114c277b80620
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
Revert "Revert "Hide long-press home animation when disabled by ..."
Revert submission 13998375-revert-13958909-mrcasey-lph-GNUFFHLQXH
Reason for revert: Reverting these CLs did not fix the test b/183684181
Reverted Changes:
Iac13fc450:Revert "Hide long-press home animation when disabl...
Ieb43607a8:Revert "Add setting for touch gesture and long-pre...
Change-Id: Ia92b0a1f19dc7423fe1b3796e14582169e58d203
Revert "Hide long-press home animation when disabled by setting"
Revert submission 13958909-mrcasey-lph
Reason for revert: Possible test breakage b/183684181
Reverted Changes:
Iaaf39e76a:Hide long-press home animation when disabled by se...
I24ee67cf1:Add setting for touch gesture and long-press home ...
Change-Id: Ieb43607a8010b843fc643979953a266cbb84788f
Added new APIs to DisplayManager to set the user disabled HDR formats,
and get/set if user disabled formats should be ignored or not.
These new settings are stored in Settings.Global.
Modified the implementation of Display#getHdrCapabilities to not return
the formats disabled by user.
Bug: 172905874
Test: atest CtsDisplayTestCases
Change-Id: I4841af251ee0e4938614b154d0c5239814ea7cd9
Merged-In: I4841af251ee0e4938614b154d0c5239814ea7cd9
This is configured by the system config resource,
config_systemSpeechRecognizer, which also provides the default
VoiceRecognitionService and the holder for the SYSTEM_SPEECH_RECOGNIZER
role.
InputMethodManagerService updates the new DEFAULT_VOICE_INPUT_METHOD
setting and handles changes to the config_systemSpeechRecognizer value.
No updates are made through the Settings UpgradeController because any
updates that would be needed are already handled by the logic for config
value changes.
Testing:
1. Enable DEBUG logging in InputMethodManagerService.
2. $ m -j && adb remount && adb shell stop && adb sync && adb shell start
3. $ adb shell settings get secure enabled_input_methods; \
adb shell settings get secure default_input_method; \
adb shell settings get secure disabled_system_input_methods; \
adb shell settings get secure default_voice_input_method
4. Check logcat to make sure nothing looks suspect.
Cases tested:
- IME wasn't already in the enabled IME list
- IME was already enabled
- no value for config_systemSpeechRecognizer
- new user added
- locale changed
- config package doesn't have an IME
- update without config value, then set a config value
- config value updated (when both values had valid IMEs)
- combinations of the above cases, as appropriate
Bug: 175480456
Test: manual - see above
Test: atest InputMethodUtilsTest
Test: atest CtsInputMethodTestCases --retry-any-failure
Change-Id: I1abdc145e3d5969fbb69811df2ca2e35c7a177e1
This will enforce the readable tests for changes made to Settings.java.
Test: atest
BUG: 183530680
Change-Id: Ie91350b29c10868cecd2c2fe4eba378278b3cb23
With the changes for app links v2, apps need a way to link users into
the domain selection screen if the app relies on opening web links
for some functionality.
To achieve that, this exposes the existing action,
ACTION_APP_OPEN_BY_DEFAULT_SETTINGS, from android.provider.Settings
and removes the permission needed to launch the relevant Activity,
since it's no longer required.
Note that this will also require a change to remove the enforcement
from the Activity declaration, which will be a follow up.
Bug: 178648367
Test: none, unhide API
Change-Id: I73231b9b4686ee67490ffe1526542b2f59c8089b
This allows them to be accessed by test apps.
BUG: 183223092
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.ReadableSettingsFieldsTest#testSecurePublicSettingsKeysAreReadable
Change-Id: I2bdcab2d9279f5ef944b17896c7b31b84ca8dc81
No UI, just setting storage and the code to honor that setting.
Bug: 182216673
Bug: 182220287
Test: manual + atest NavigationBarTest
Change-Id: I24ee67cf196d7ae698a731e00a9eb5a726eddb24
Secondary volumes are FUSE mounted, whereas Android/data and Android/obb
on primary volumes are not FUSE mounted. Access to these private app
directories on primary volumes is restricted using the mount modes, but
access for these on secondary volumes need to be regulated by
MediaProvider.
Make getExternalStorageMountMode as SystemApi so that MediaProvider
can leverage the same mount logic for Secondary volumes.
Expose relevant mount modes as SystemApi as well.
This change saves us the maintenance overhead for Secondary volumes for
Android S+. Otherwise we would have to check if an app is a signature
app through APIs which would basically be the duplication for the
logic in StorageManagerService.java.
Expose ExternalStorageProvider and downloads Authority for MediaProvider
to rely only on APIs. This is also required for CDD modifications that
these 2 providers are given exceptional access to private app dirs.
Bug: 175796984
Bug: 173505864
Bug: 173505864
Test: atest DownloadProviderTest
Test: atest CtsScopedStorageHostTest
Test: atest android.scopedstorage.cts.host.PublicVolumeHostTest#testCheckInstallerAppAccessToObbDirs
Test: atest android.scopedstorage.cts.host.PublicVolumeHostTest#testCantAccessOtherAppsExternalDirs
Change-Id: I51bc7bd3f355fadd9de56ac267469c2352eb0ffa
Merged-In: I51bc7bd3f355fadd9de56ac267469c2352eb0ffa
Uses the atom MagnificationModeWithImeOnReported in westworld to log
the activated mode when the IME window is shown on the screen.
Adding a new callback API in the MagnificationCallback to monitor the
IME window visibility changes. The A11y framework registers the
callback when the magnification is enabled. It logs the related
data when it receives the IME window visibility changes through
this callback and the magnification is in the activation.
Bug: 154021596
Test: a11y CTS & unit tests
Test: make statsd_testdrive && ./out/host/linux-x86/bin/statsd_testdrive 346
Merged-In: I49b02e00d5a1131b388eeb923440f59a2b4f81a6
Change-Id: I49b02e00d5a1131b388eeb923440f59a2b4f81a6
(cherry picked from commit 1aa113d8dd)
Adds a new namespace to DeviceConfig for features
relating to AppSearch.
Bug: 173532925
Test: build
Change-Id: I5887899d9292bf88ea5007d94c20b8690ee73872
