This patch replaces the recently introduced
Settings.Global.ENABLE_SMART_REPLIES_IN_NOTIFICATIONS boolean setting
with a new Settings.Global.SMART_REPLIES_IN_NOTIFICATIONS_FLAGS
key-value list.
Rationale: This will allow us to add and tweak smart reply parameters
without polluting the global settings namespace.
Bug: 67765414
Test: atest SmartReplyConstantsTest
Change-Id: I284bb6b31618a234c4772d16ad6190a713035f1b
Public EuiccManager and other related necessary files.
Mark EuiccCardManager and other related necessary files as @SystemApi.
Solve lint errors and warnings.
Bug: 35851809
Test: test on phone
Change-Id: Id7895f9b35ce9d4fb6fae42ba89ca9b29dbfa74c
NIGHT_DISPLAY_AUTO_MODE_VALIDATOR was incorrectly aliasing
BOOLEAN_EVALUATOR. As the valid values for this setting are { 0, 1, 2 },
when 2 (sunset-sunrise auto mode) was restored, the restoration would
fail.
Bug: 72992475
Test: B&R a device from the cloud with a sunrise-sunset auto mode.
Change-Id: I2dcb746847054e1f3d93731790a4d534f927ae28
This will help us run P/H experiments by controlling display panel low
power mode system property through P/H.
Bug: 72121774
Test: Compile, boot taimen.
Change-Id: Id4c95bcd5616e9749f9dcc9d9f4773ffdad3e994
1. ANOMALY_CONFIG_VERSION: version of the anomlay config
2. ANOMALY_CONFIG: a base64-encoded string of raw config.
Bug: 72385333
Test: Build
Change-Id: If990d2e00e019cc6d6a6c601de9a08bd5e649654
Add a system setting to store preferred RTT mode for calls. Add logging
for RTT in Telecom base classes.
Bug: 63934808
Test: manual
Change-Id: Ie26fac800931604379bbe7b8abfed7caa8c0236d
Autofill helps users fill credentials, addresses, payment methods,
emails, etc without manually typing. When focus lands on a fillable
element the platform captures a snapshot of the screen content and
sends it to an autofill service for analysis and suggestions. The
screen snapshot is a structured representation of the screen content.
If this content is composed of standard widgets, autofill works
out-of-the-box. However, some apps do their own rendering and
the content in this case looks like a single view to the platform
while it may have semantic structure. For example, a view may render
a login page with two input test fields.
The platform exposes APIs for apps to report virtual view structure
allowing autofill services to handle apps that have virtual content.
As opposed to apps using standard widgets, this case requires the app
developer to implement the new APIs which may require a fair amount
of code and could be seen as a processes that could take some time.
The most prominent typs of apps that fall into this category are
browsers.
Until most apps rendering virtual content and specifically browsers
don't implement the virutal APIs, autofill providers need to fall-
back to using the accessibliity APIs to provide autofill support
for these apps. This requires developers to work against two sets
of APIs - autofill and accessibility - which is incovenient and error
prone. Also, users need to enable two plugins - autofill and
accessibility which is confusing. Additionally, the privacy and
perfomance impact of using the accessibility APIs cannot be addressed
while autofill providers need to use thes APis.
This change adds an autofill compatibility mode that would allow
autofill services to work with apps that don't implement the
virtual structure autofill APIs. The key idea is to locally enable
accessibility for the target package and remap accessibility to
autofill APIs and vise versa. This way an autofill provider codes
against a single set of APIs, the users enable a single plugin,
the privacy/performance implications of using the accessibility
APIs are addressed, the target app only takes a performance hit
since accessibility is enabled locally which is still more efficient
compared to the performance hit it would incur if accessibility is
enabled globally.
To enable compatibility mode an autofill service declares in its
metadata which packages it is interested in and also what is
the max version code of the package for which to enable compat
mode. Targeted versioning allows targeting only older versions of
the package that are known to not support autofill while newer
versions that are known to support autofill would work in normal
mode.
Since compatibility mode should be used only as a fallback we
have a white list setting with the packages for which this mode
can be requested. This allows applying policy to target only
apps that are known to not support autofill.
Test:
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases
bug:72811034
Change-Id: I11f1580ced0f8b4300a10b3a5174a1758a5702a0
The majority of Manager-style classes already use Context.getUserId()
when making calls into the OS, so clean up the remaining callers to
unify behind this strategy.
This gives @SystemApi developers a nice clean interface to interact
across user boundaries, instead of manually adding "AsUser" or
"ForUser" method variants, which would quickly become unsustainable.
Test: builds, boots
Bug: 72863821
Exempt-From-Owner-Approval: trivial changes
Change-Id: Ib772ec4438e57a2ad4950821b9432f9842998451
This will help us run P/H experiments by controlling the
uid cpu power system property through P/H.
b/70517018
Test: Will manually test it later through opt-in P/H experiment
Change-Id: I2cb26f429e867acbed7ff553cc18b447932af655
Remove WIFI_WAKEUP_AVAILABLE config setting its available by default.
Remove check for NETWORK_RECOMMENDATIONS_ENABLED, the feature no longer
uses the recommender.
Test: make RunSettingsRoboTests RunSettingsLibRoboTests;
Test: atest SettingsBackupTest; manual/exploratory
Bug: 69624403
Bug: 67952636
Change-Id: I9e287b79d0da01bab00ed81295dcc1f266ca0851
I originally envisioned to keep this logic and the one in the
battery service (which decides when to send a LOW_BATTERY broadcast)
in sync.
However, because this PowerUI logic decides when to show the "battery low"
notification, and showing the notification when the battery level
is still 50% doesn't really make sense even when the battery saver
starts at 50%, so let's only cap the value in PowerUI.
So if LOW_POWER_MODE_TRIGGER_LEVEL is 50,
- Battery saver kicks in at battery level 50%
- LOW_BATTERY broadcast is also sent at 50%
- But we don't show the "battery low" notification until 15% still.
(I'll talk with the PM and we might tweak the details.)
Bug: 71707409
Test: build & boot
Change-Id: I162dc722a6f634e5844ed81385a8463797634a02
Instead of writing StatsLog.write(StatsLog.NAME, 1), we replace the 1
with the appropriate StatsLog constant.
Bug: 72749863
Test: still compiles
Change-Id: I68c8206de49df7e77ee66333dd633e4b70c7b226
Defaults to true by default. Some devices may override this to force the
restricted profile to stop when not in use to save all the memory it
consumes where that is an issue.
There is no framework / first-party code setting it, but since this
is checked every time a user switches into the profile rolling it out
should be relatively straightfoward.
Bug: 71626497
Test: make droid
Change-Id: I7a718c4fdd2d80131df083908129b715d94e824e
- Changed AM.getGrantedUriPermissions() API.
- Made DocumentsContract.PATH_TREE public.
Also fixed related AM methods to use explicit for on some loops.
Bug: 63720392
Test: manual verification
Change-Id: I33bdcb949f4301534bd8467c8018d6f03b4588a4
Controller by a feature flag, which this change also introduces.
Bug: 62390666
Bug: 70892390
Test: manual, via JobSchedulerTestApp
Test: CtsJobSchedulerTestCases
Change-Id: Ic7dfb7861f7987a1b6eeb4cf3851193e9ad7da84
Store location changer into Settings.Secure
Modify quick settings to identify itself as location changer
Bug: 68779883
Test: Manual
Change-Id: I2c7a599e1383102685994d876e7160e164436a08
Adds a setting allowing user to toggle Carrier Network Available
Notification on and off.
Bug: 69310016
Test: Verified manually
Change-Id: I209cd216dd5fd5c790aca8f74707a7ef831edd6a
This patch adds two distinct vibration control settings: one for
notifications and ringtones, and one for haptic feedback. Since we don't
always have the exact intent of a given vibration, VibratorService will
do its best to classify each VibrationEffect into one of these two
categories and then scale the vibration accordingly based on the
intensity setting.
Bug: 64185329
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.VibratorTest
cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.VibrationEffectTest
Change-Id: If16237f4782281aaab33e4a0f55c29f1a30ac493
SettingsSlicesContract added with constants including
- Authority
- Authority Uri
- Keys for major platform settings
Fixes: 72101207
Test: none, constants only.
Change-Id: I29fdd8391182e3c9a5abc063c56f18ed1f5f834b
And add unit tests for common validators as atonement...
Test: atest frameworks/base/core/tests/coretests/src/android/provider/SettingsValidatorsTest.java
Bug: 64988620
Change-Id: I561319356cbca70da326586c2a762293c4ade9ed
This will enable running experiments to determine the
effects on battery life of changing these values.
Bug: 71765044
Test: Just adding a key value here. This is basically a no-op.
Change-Id: I33a0b2da6e793ef508d020a3c2d321d5553c3fb1
Applications typically use this action to ask the user to revert the
"Do not ask again" status of directory access requested made by
StorageVolume.createAccessIntent(directory).
Test: atest CtsAppSecurityHostTestCases:ScopedDirectoryAccessTest#testResetDoNotAskAgain
Test: adb shell am start -a android.settings.STORAGE_VOLUME_ACCESS_SETTINGS
Bug: 63720392
Change-Id: I1ed1a018a54013d88260e11ef9646aaed3a3a318
