The goal is to figure out if it would be worth monitoring these
exceptions. If exception types are only caller issues like
SecurityException and IllegalArgumentException, it is probably not worth
it. If we can find NPE or internal exceptions it would be worth
uploading the exceptions through dropbox.
Test: unit test
Change-Id: I779d43a0e6ca1a33535b90809491675420a51726
Make calls from activity classes go through ActivityManagerInternal
interface to case UserController instead of calling AMS.mUserController
object directly. Note that calls to UserController should not hold the
AMS lock.
Bug: 80414790
Test: Existing tests pass
Change-Id: Ie56f08d10b62d609e9b5e31f45b5f0d6eed3a9d4
This CL logically reverts the following CL (and some subsequent
changes) to stop restoring spell checker related secure settings.
* Ib8382f0296f0726b64494d3b1fd8237e13adb540
06cbaddb87
Reason for revert:
Although we believe it would be great if we can seamlessly migrate to
a new phone with keeping spell checker related settings, there still
remain several tricky scenarios.
* We are not ready to distinguish whether a certain spell checker
related setting was explicitly set by the user or programmatically
set by some components in the previoud device. This includes the
case where TextServicesManagerService (TSMS) itself automatically
updates those settings e.g. by selecting a default spell checker
service from the pre-installed ones. We are not sure if trying to
migrate such an auto-selected setting to a new device actually
makes sense, especially if it happens without any user
confirmation.
* We have a strict rule about what spell checker service can be
selected automatically, and the rule has been that only
pre-installed spell checker services can be automatically selected
by the system, unless some system components that have
WRITE_SECURE_SETTINGS permission overrides it. Mechanically
selecting a spell checker service just because it was enabled in
the previous device may not fit this model well.
* Unlike IMEs, currently the Android OS allows only one spell checker
service to be enabled. This means that if the new device doesn't
have the corresponding spell checker service, the user will lose
spell checking functionality even if the device pre-installs
functional spell checker service. This problem is hard to notice
because unlike IMEs spell checker service does not have its own UI.
* Also unlike IMEs, spell checker related secure settings are still
hidden and not published as public APIs. Those settings do not
have no official compatibility story across devices yet.
* It is also possible that the default spell checker service in the
previous device is not published to all the devices thus there is
no way for the the new device to install it.
This CL therefore excludes spell checker related settings from
backup/restore, as a short-term answer to above scenarios until we
come up with better ideas to deal nicely with them.
Bug: 110367605
Test: atest FrameworksCoreTests:android.provider.SettingsBackupTest
Test: atest FrameworksCoreTests:android.provider.SettingsValidatorsTest
Change-Id: I8e4a0d4b3b758a84d5a075fa52851b1e8dd707eb
Otherwise there is a big performance hit in all kinds of
situations where we do operations with the region, specifically
when:
- updating input windows
- insetting the cutout during layout
- touch dispatch
Test: DisplayCutoutTest, WmDisplayCutoutTest
Bug: 110464019
Bug: 110452325
Change-Id: I94a25c3794ecd33b8b7204ca308ac91623498f13
Before this CL, when TextView's textSize attribute was set to 0sp in
XML, the text would still be visible on the screen, as the actual
textSize set was non zero. On the other hand, if the text size was set
to 0sp programmatically, the text would not be visible. This was a P
regression, as on O the text would be invisible in both cases.
This CL fixes the attribute reading stage in TextView, allowing the
application of a 0 text size on the view.
Bug: 110251171
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I3798361e182f45a67cd0a69d40e09e559375aa20
Half has a dependency on an internal sun.misc.FloatingDecimal
that can be replaced by an equivalent call on java.lang.Float
(which calls through to FloatingDecimal).
Any performance hit is worth it for a smaller API surface.
Bug: 111055375
Test: Build
Change-Id: Iecdf3aa9414922a77edbdc439b0c2b88033b3af8
- RemoteViews specify an ActivityOptions when calling startIntentSender()
(for click handling), but if the PendingIntent being started also has an
ActivityOptions, the merging of the two options will fail since the
ActivityOptions properties are always written into the bundle (regardless
of whether they are actually set). Instead, only write non-default
values to the bundle (the defaults will be read out if not set when
restoring the options from the bundle anyways).
Bug: 72459081
Test: atest FrameworksServicesTests:ActivityOptionsTest
change-id: i1d6718d9db4b3f7056412c5b4c5347a19ffa7c09
Moved more stuff related to activities out of the current service to the new one.
Bug: 80414790
Fixes: 110988007
Test: Existing tests pass.
Change-Id: Iceed1da8a7441a26d11efebc6d9f692fd053bc7f
Combination of moving to existing public API, tagging things as
@TestApi, and bringing utility methods into tests.
Bug: 13282254
Test: atest cts/tests/tests/os/
Change-Id: Ifd24c0d048d200e8595e194890cc1dc53ddc2b3e
- Add secure setting to enable/disable in call notifications
- Can toggle system setting using the following adb command:
adb shell settings put secure in_call_notification_enabled [0/1]
Bug: 71586014
Test: manual
Change-Id: I32e1d1d6dcae806e655ae6875a43d07ca83e77f4
The current issue is that Views that have either the horizontal or
vertical scroll bars enabled will intercept mouse interactions that
entire the region where the scrolling thumb would be even if the View
cannot actually scroll because it's content isn't larger than it.
This is fixed by only intercepting mouse interactions in the scroll
thumb region if there is something to scroll.
Bug: 110375792
Test: None yet
Change-Id: Ib638b4ac88375f55bc80ba2a66d945a16ecd6d22
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're reading data from credential
protected storage.
When a user is locked, credential protected storage is unavailable,
and files stored in these locations appear to not exist, which can
result in subtle app bugs if they assume default behaviors or
empty states. Instead, apps should store data needed while a user
is locked under device protected storage areas.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: Ia390318efa6fefda8f10ac684d0206e67aa1d3dc
Increase alpha from 15 to 30% for the track and use Google Material
Grey 200 for the thumb. Fix the geometry so that the track and thumb
don't extend off the edge of the screen.
Bug: 80258942
Change-Id: I43e603e5fffb8a05f486af35194c801060dd0b51
(cherry picked from commit 97b00cbc039a090659aed75e47a172a70222b02f)
Documentation is pretty vague:
https://developer.android.com/guide/topics/data/autobackup#XMLSyntax.
But there were a couple of issues:
* It was prematurely returning false without consuming the rest of the
includes (cause of the bug linked).
* It was using string comparison for checking if a file is in a
directory, which ended up flagging directories such as "a/b" as
containing files "a/b.txt".
Reviewers,
* Please, pay full attention to test cases.
* Since this is code move + code change, set diff as 2..latest to check
changes to the function.
Bug: 110720194
Test: atest BackupUtilsTest
Test: Backup and restore app w/ multiple directory includes, verify
everything restored
Change-Id: Ic0fea43156ce8fb641af69ae73679289a20c291c
Update docs to clarify that plugins are in fact not supported from K
onward and that enabling them doesn't do anything.
Test: m offline-sdk-docs
Change-Id: I8678ea716be0adc4cd3a6fae1b4776e312ec29e0
Using the Settings App-Developer Options-Feature Flag, allow the user to
enable or disable the Hearing Aid Profile.
Test: Manual testing using Settings App
Change-Id: I58a9d339941e235242c443c85b6f4194b5a296c9
