Now that we have a nice Clock abstraction, we can use it to represent
a clock backed by an NTP fix. (This makes testing logic much easier
to write.)
We now rely completely on NetworkTimeUpdateService to keep our NTP
fix up to date, instead of trying to refresh in the middle of
critical paths which could trigger random ANRs.
Add internal FallbackClock to make it easier to handle missing NTP
fixes. Add internal SimpleClock to let implementers focus on single
millis() method.
Test: bit FrameworksNetTests:com.android.server.net.NetworkStatsServiceTest
Test: bit FrameworksServicesTests:com.android.server.NetworkPolicyManagerServiceTest
Bug: 69714690, 72320957
Change-Id: Ic32cdcbe093d08b73b0e4b23d6910b23ea8e1968
Exempt-From-Owner-Approval: approved in previous PS
Added parameters for local transport in secure setting for setting up
local transport to test transport flags GTS test.
Test: GTS test in topic CL.
Bug: 73100304
Change-Id: If654175d91fdf1ea68db0f3320d59b2b770a4db3
Schedule the read with a delay and ignore any
proc state changes during this delay duration.
Bug: 73437192
Test: atest com.android.internal.os.BatteryStatsTests
Change-Id: Ica6ec3f16ed911091e79102a2a62210edcaddf94
* Changed the remoteId -> userValue API to userValue -> categoryId so the
category could map to multiple values (for example,
"email" -> "email1", "email2")
* Added method and settings for maximum number of category ids.
* Tuned the default value of some settings.
Bug: 70407264
Test: atest CtsAutoFillServiceTestCases:UserDataTest \
CtsAutoFillServiceTestCases:FieldsClassificationTest \
SettingsBackupTest
Change-Id: I27f348c500077937c0f4bf65db6a899fa3c41cf6
* Add a new API to allow Telecom to inform ConnectionServices when the
RTT text stream changes
* No longer set the RTT property from ConnectionService. Client apps
should be setting properties themselves.
* Add Dialer-side RTT property in order to remove the dependence on
checking the RTT streams, which have a complex lifecycle
Bug: 72951201
Bug: 72648661
Test: manual, with real RTT calls and Dialer's SimulatorConnection, also
cts
Change-Id: Ic4c7d883d2dc6baf8e8c0eaa4df58d7de8762b9e
Just support "*" for now, meaning disable all API blacklisting for all
apps.
Test: Manually verified by:
- installing test app that accesses hidden API
- manually blacklist the API
- $ adb shell settings put global hidden_api_blacklist_exemptions \\*
Change-Id: I9a41a104742c9aaaf3a753e7b0f3a1106e37d4d3
- When an one-shot sync with app-standby exempt fails too many times in a row,
drop the "exempt from app-standby" flag.
- Also obtain some constants from global settings so we can change them
in CTS.
Bug: 72443754
Test: Manual test (CTS WIP)
Change-Id: Ibdbb348a7ff26a0be04b8f2c256e1f6ead39907d
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: I68853e134e1e31fa9b91a83af6c491a2a8cca971
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 CL logically reverts the following CL to stop restoring
Settings.Secure.ENABLED_INPUT_METHODS during the new device/user
setup.
* If0104151b3526da6ecc669adde3119a239ecafeb
7b9a28c7f0
This CL also partially reverts the following CL because part of that
CL is no longer necessary.
* I94b4039c9f54c341aec72b62579be3dd8bd84dbb
964943ab98
In theory we should have been able to revert most of the following CL,
but other team it is already used by other projects so we cannot
revert it right now, unfortunately.
* I01f5fafbbcfe3e3f5313829162ec011eaf2ad991
2028ddaa50
Reason for revert:
At high level, we doubt restoring
Settings.Secure.ENABLED_INPUT_METHODS still benefits restore
experience for the user.
* Anecdotally almost all IMEs maintain enabled languages with their
per-app settings such as SheredPreference. This observation leads
us to think that we should focus more on stabilizing per-app
backup/restore scenario at least for IME migration scenarios.
* The code is not that simple and cost to maintain it is not that
low. If we reverted this code, we could spend our resources for
other tasks, including improving restore experience for the user.
* Stopping restoring ENABLED_INPUT_METHODS reduces chances to
conflict with what the device policy says [1].
* We have had a strict rule about what IMEs can be enabled
automatically, and the rule has been that only pre-installed IMEs
can be automatically enabled by the system, unless some system
components that have WRITE_SECURE_SETTINGS permission overrides it.
Mechanically enabling an IME just because it was enabled in the
previous device does not fit this model well.
* Since Android O MR1, we also backup/restore user languages
specified in the global settings [2]. The default selected IME
should be able to automatically enable language support based on
the restored system locales.
[1]: DevicePolicyManager#setPermittedInputMethods()
[2]: I1e6c7ba5b7abb6bde8b01ce0f647c04a5caa81a6
0f19cc779f
Fix: 72978240
Test: atest FrameworksCoreTests:android.provider.SettingsBackupTest
Test: atest FrameworksCoreTests:android.provider.SettingsValidatorsTest
Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest
Change-Id: I122a8f69b2f75a9af85e14b66db764c5d153040e
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
