Now both KeyEvent and MotionEvent will contain displayId. This will help
with dispatching input events to specific displays. There are use cases
where a particular input device is used for a specific display only, and
it sends key events to the system. This will help with those usages.
Test: atest view.MotionEventTest view.KeyEventTest
Bug: 64258305
Change-Id: I75891037617ed60820d60736216a0d615ab5e3b0
The CL was intended only for P as a temporary solution.
This reverts commit f0800fa3bd.
Test: switch wallpapers, observe theme
Bug: 110758454
Change-Id: If10e4d87b6ddac10063b2671abd99e0baccdf92e
Track changes in libcore to remove a constructor + lint
import order changes. Instead of the constructor a utility
method is introduced.
Test: Build / boot
Bug: 111055375
Change-Id: Id683a9d9d6e27d4c8df623dae189da9e74a6d410
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
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
Enable API user to create their own URLSpan for Linkify operations.
Test: atest android.text.util.cts.LinkifyTest
Test: atest android.text.util.LinkifyTest
Bug: 28536972
Bug: 32613009
Bug: 29150779
Change-Id: Ia4495dc7e656044b91a79804d3b50a30cae98225
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
Before applying this patch, when a show-when-locked immersive app is
showing, the system bars would quickly show and hide, which are
redundant to the user.
The root cause is that, for nav bar, we have a policy to show nav bar
if the width and height of status bar are MATCH_PARENT and status bar
has no PRIVATE_FLAG_KEYGUARD. When keyguard is becoming status bar,
its keyguard flag would be removed first, and then the height would
be changed to the bar height. So the nav bar would be shown between
these events. For status bar, we force showing it when it is expanded
by checking its width and height are MATCH_PARENT or not.
To fix the issue, this change introduces a new private flag which
indicates that the status bar window is now in an explicit expanded
state. We check this flag instead of checking the width and height of
status bar.
This change also fix a bug that: when AOD is enabled, if the
foreground app has FLAG_SHOW_WHEN_LOCKED, FLAG_TURN_SCREEN_ON, and
FLAG_FULLSCREEN, clicking on the power key would make it show the app
again instead of AOD. (not 100%, but chances)
Bug: 80147982
Test: 1. go/wm-smoke
2. Launch a show-when-locked turn-screen-on immersive app on
AOD, and see if any system bar flashes.
3. Launch a show-when-locked turn-screen-on immersive app on
lockscreen, and see if any system bar flashes.
4. a. Enable AOD in Settings.
b. Open a show-when-locked turn-screen-on immersive app.
c. Click on power key, and see if AOD shows.
5. Launch an immersive app and drag down the status bar, see
if nav bar keeps there as long as status bar is expanded.
Change-Id: Ie885d504eb73ae8a86736b2c3ed4fb03eb9f739e
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)
