- When the window for the activity enters PIP, update the outline provider
to override the alpha of the shadow (to be opaque) to ensure that is is
visible. Only applies to the task root activity.
Bug: 36741700
Test: Launch YT, ensure that there is a shadow when after it enters PIP
Test: go/wm-smoke
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: If089dae84e4916d3d0e7bbeb316215b46e522e05
- This can happen either if an app creates an ActivityOptions without a
thumbnail, or if the call to create a hardware bitmap fails for any
reason. Just ignore the thumbnail for the transition in this case.
Bug: 62296016
Test: Have not been able to reproduce, but this is just a logical change
Change-Id: I30776b651df1f42118fe1d317fa4817261a6e977
This is done on wear power button doesn't turn off the screen,
when the device wakes from keyguard UI isn't visible yet, so
it needs to react to power press in some way.
Bug: 35147955
Change-Id: I22619ea446770d09b53370e9244215646b60a9db
- It is possible for the session to be requested to be hidden before it
gets the message to be shown and completes showing. This leads to an
inconsistency where the voice interaction service implementation will be
in a different state than the system for the session. Instead, we can
cancel any pending show messages, and also clean up the pending show
callback list immediately when the session is hidden.
- Also fixing up some error message codes when starting the assistant
activity.
Bug: 38379130
Test: android.server.cts.ActivityManagerAssistantStackTests
Test: CtsVoiceInteractionTestCases
Test: CtsAlarmClockTestCases
Change-Id: I0d0e9c024367a47bda82d6a29ca89e18b7d69527
This allows tooltips to work even in a context where they don't belong
in any activity (and therefore no window token to use). It also
simplifies a tiny bit the logic of how to get the view to show up.
Test: Checked tooltip behavior in and outside an app
Bug: 62065980
Change-Id: I6c02009c4fdd6d4bc4fa2cf8019955360506f0ee
- focusAfterDescendant ViewGroups that were also clusters would
continue to be remembered for restoreFocusedInCluster after
gaining focusable children. This caused undesired cluster-focus
loops
- focusableViewAvailable wasn't being called in all cases (specifically
when views were added). This meant focusAfterDescendant views
wouldn't transfer focus to children in some cases.
- 0-area views which became focusable weren't reporting
focusableViewAvailable. Since views gaining area doesn't report
focusableViewAvailable, this was another case of state change not
being accounted for. Also, this restriction doesn't exist for
gaining focus so these views are actually focusable despite having
0 area.
- focusableViewAvailable was reporting focusable views even when
ancestors (and therefore the new focusables) were not visible.
- restoreFocusNotInCluster tried to focus invisible views
- restoreFocusNotInCluster was sending focus to focusAfterDescendant
viewgroups which had focusable children IN a cluster.
Bug: 38010274
Bug: 38009598
Bug: 38352147
Test: cycling works in situations reported in bugs.
Added CTS tests around focusableViewAvailable and
FOCUS_AFTER_DESCENDANTS
Change-Id: I77f214f5384dcf9092324e08fc1daa3f1155bbad
* splits the auto-size setup part from the execution
function:
** in TextView CTOR we only setup and we leave the
actual auto-sizing execution to happen in the
view||text layout phase
** encapsulated the conditions needed to start
applying auto-size in the execution function
* introduces a private way to set the text size
without requesting a new layout pass; auto-size
always uses this practically setting the text
size on the paint object and creating a new
layout
* calls execution autoSizeText() from within
TextView#checkForRelayout() if not requestLayout()
is needed => this makes sure that auto-size will be
performed even if a view layout is not requested,
but only a text layout
* fixes the calculation of the sizes available for
auto-size when configured via granularity
Bug: 62050646
Bug: 38409622
Bug: 38440435
Bug: 62109627
Test: run cts --test android.widget.cts.TextViewTest -m \
CtsWidgetTestCases
Test: manually tested the new behaviors in demo apps
Test: new test attached in topic
Change-Id: I4ccaa0a0afa3b5aa47213442d0029da2c74e7eb4
With my TimePickerDialog change to support keyboard based input I
accidentally broke TimePickerDialog#onClick as it was no longer being
called, instead it was calling TimeSetListener directly. This CL changes
the logic back to use onClick again.
Bug: 36042834
Test: Locally tested FitBit app.
Change-Id: I47d5563c99cc46eaaf2b1d4a96483d6825fc5805
On watches, multi-window is used to present essential system UI, and thus it
must be supported regardless of device memory characteristics.
Bug: 37482466
Test: Manually, on a watch
Change-Id: I7929a090b7fd46de019d237ce771c82a6d7fd3f3
Moves the network stats collection under a different lock to
prevent the main BatteryStatsImpl lock from being held while doing I/O.
Bug: 37645919
Bug: 38296815
Test: manual
Change-Id: I0d6b4a7b12b234939cb6eb3a32658b28f61dff4f
- This reduces the copy of the hardware bitmap when it is
parceled/unparceled.
Bug: 38507414
Bug: 62021436
Test: Launch Overview to/from app, ensure that the header bar shows
Test: go/wm-smoke
Change-Id: I85a9a59a0a3699d1642158061d10fddef34393c3
Signed-off-by: Winson Chung <winsonc@google.com>
When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes(). That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.
This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations. Callers freeing cached data need to
now explicitly request defiance of the reserved cache space. (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)
Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand. It
also now handles cached data on adopted storage volumes, which had
been ignored until now. Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9
We are caching unused static shared libs and instant apps
(installed and uninstalled) opportunistically. If space is
needed we delete these to free up space.
Test: manual
bug:62045000
Change-Id: Id992dee5c7c6e36b8e8b81050602dbc4eeafb0f9
When the device is unlocked using the fingerprint sensor in an
orientation opposite to the lockscreen orientation, the app that
will be visible is first relaunched in the current lockscreen
orientation and then later relaunched in the correct orientation.
If the keygaurd is going away then:
- Don't let keyguard affect device orientation. We want to use the
orientation of the app that will be visible.
- Allow the rotation sensor to be enabled even though draw isn't
complete so window manager can get the updated or last rotation
reading.
- Don't clear the previous proposed sensor reading to allow
window manager to use the information to update the orientation as
needed vs. falling back to the previous orientation.
Change-Id: I8369723d6a77f2c602f1ef080371fa7cd9ee094e
Fixes: 38494778
Test: Launch an app that doesn't fix orientation like clock, hold
the device in landscape, press the power button, unlock the device
using the fingerprint sensor, and verify the the app isn't
relaunched.
