There may be strange states where the user is already authenticated
but still on the lockscreen. The user should be able to dismiss
keyguard in that state.
Fixes: 29306222
Test: unlock phone
go back to keyguard
swipe up screen half way
touch fingerprint sensor (icon should change to unlocked)
then touch fingerprint sensor again (keyguard should be dismissed)
Test: unlock phone and go to settings -> Pixel Imprint
lock phone, unlock phone with fingerprint
touch sensor again and make sure Pixel Imprint page also responds to FP
do this test at least 10 times
Change-Id: I86acd520a06a68fab3548dd4cf6153a7833114fe
Previous logic relied on the returnTo type of the task of the activity
we are launching which can get the wrong signal at times because the
original task might have been started from home, but since we are
already in docked mode it shouldn't cause recents activity to be
launched.
We now decide if recents ability should be shown based on if the home
stack is currently visible at the time we started the new activity.
Also, renamed ActivityStack.getStackVisibilityLocked() to
ActivityStack.shouldBeVisible() since it is used to determine if the
stack should be visible and also so it isn't confused with the new
method ActivityStack.isVisible() which returns true if the stack is
currently visible.
Test: manual
Change-Id: I051e72ce93c886d25526af2afef851c95812ab3e
Fixes: 37005549
We create a new thread on which everything is running that
directly impacts window animations, i.e. layout, anim tick and
starting window creation. This is such that any work on
android.display can not lead to jank in the window animation,
specifically lock contention on activity manager lock that blocks
callbacks from android.display into AM can not lead to window
animation jank.
Test: Run animation, take systrace, make sure animation is on
android.anim
Test: AppWindowContainerControllerTestTest: AppWindowContainerControllerTestss
Fixes: 36792959
Change-Id: I5d41419a709b7984724e7053a3afdcc1ffe1aaa2
Change-Id: I342a133ae8d7f38008cb03706d160e6f2e2cca97
Fixes: 37002720
Test: Start instant app [adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d http://www.realestate.com.au/property-apartment-nsw-pyrmont-124879602] and see that hitting the 'share' icon works
As far as I can tell this has always been broken. We've always had
intermittent reports of buffer-queue-abandoned as well (a recent bug
came with some reports from N). During onStop SurfaceView relies on
onWindowVisibilityChanged, to trigger a visibility change. At this
point SurfaceView will emit the SurfaceDestroyed callback in order to
stop the client from further use of the Surface. The contract we've
been using with ViewRootImpl is at any point following
Activity.performStop returning the WindowManager was free to destroy
the Surfaces. This is why in setWindowsStopped we destroy the hardware
resources for the ViewRoot. However we aren't dispatching anything to
the SurfaceView. The WindowManager will send an app visibility
notification, but that would go through the handler. This means by the
time we return from Stop, there is no guarantee that the
onWindowVisibilityChanged callbacks have been invoked at all. It
seemed most sensible to dispatch the visibility callbacks directly. We
also ensure that getHostVisibility will return false after this point,
so that performTraversals will not reverse our visibility request if
it occurs again prior to the window visibility notification from the
WindowManager. We also guard against emitting a second window
visibility changed callback in the traversals. I don't know at this
point what value the window visibility notification provides but I
don't feel excited about removing it in this CL at this point in
the development cycle.
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: Id1673561b2299d477b2761b3ac6afa14eabbf7fb
This reverts commit 2d2315a66d81d29896e6a0ffedbfbbed3981b9ed.
Reason for revert: possible cause for b/37156733
Change-Id: I02d468449f0632d1281ab5ad2a381e7e36a5b0ea
Added ActivityManager#supportsMultiDisplay() to check if system
supports running activities on secondary displays.
Bug: 36776777
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testMultiDisplayDisabled
Change-Id: I18f98f2f6a9e865ad8dc63a470210190536d3271
Reuses already existing infrastructure. The mMDNSFilteredDiscovery lambda
is called for every network service that supports #PRIVET_SERVICE. Then
the plugin checks the txt fields to make sure the printer is valid. The
check is not complete but good enough to make sure this is either a
cloud print capable printer or something that tries really hard.
Test: Connected to network with three printers, 2 GCP capable. Found the
two printers
Fixes: 35766193
Change-Id: I7c9180c8c154fa092fec5b943a94bad77da74c86
Implement missing color management pieces for bitmaps:
- Bitmap.createBitmap(Bitmap src, ...) now creates a bitmap
in the same color space as the source bitmap
- Bitmap.createScaledBitmap() now creates a bitmap in the
same color space as the source bitmap
- Bitmap.createBitmap(..., ColorSpace colorSpace) to create
bitmaps in a specific color space
- Fix copy from A8 to F16
- Copying bitmaps in F16 or with a color space does not work,
it's currently a limitation in Skia
Bug: 36905374
Test: BitmapColorSpaceTest
Change-Id: I0092fe4432511db50daa3a9393389a9db05e0c2a
If thread was boost priority already before boosting we reset it
to default priority after.
Test: Open app, run systrace, make sure priorities are right
Bug: 36631902
Change-Id: I763be06c0dc68db73548b22f96dd07864a6ace1f
We have already removed the non-functional WebView stub, so we can now
remove the logic ensuring that a primary device user could use any
valid WebView package even when a secondary user did not have any
WebView package to choose from (since all device users should always
have a valid package to use as WebView implementation).
Bug: 34730873
Test: run WebViewUpdateServiceTest tests.
Test: Create new user, disable Chrome for that user, ensure WebView
loads for that user and for the primary user.
Change-Id: Ia77cc2efd9e40a157fb5b68a988425ef15508033
Add a new permission that only allows other system services to call
networking related methods. This permission is intended to prevent
other apps from calling these methods that might leave networking
services in intermediate states.
Bug: 36538042
Test: build, run wifi unit tests, boots, wifi connects
Change-Id: Icba6ad5280e9a8863bd1c706ca34b7add8de5294
(cherry picked from commit fa84050a7e51e2a6643ea242b43f16cd6e3114dd)
This CL removes the strong reference added for mapping display ids
and Resources to Displays. Instead, the key pair is now the display
id and ResourcesKey, and the mapping is pruned when key is
invalidated.
Change-Id: I60d767b52de7bbf769f6761f5a3301dd7aff6ddf
Fixes: 36625868
Test: make -j32 cts; cts-tradefed; run cts --module CtsAppTestCases --test android.app.cts.DisplayTest#testRotation