Symptom:
When sharing an image from Album, ChooserActivity can be shown.
But then the app to be located to the bottom part of the list may not
be started even if user tap it.
Root cause:
ChooserActivity uses ResolverDrawerLayout. And ResolverDrawerLayout
can display only some items on the list (known as "Collapse mode").
When the item clipping along the bottom edge is tapped by the user,
ResolverDrawerLayout tries to expand the list and scroll it to a
better position, instead of starting an application.
In this problem case, ResolverDrawerLayout continues to try to expand
the list whenever tapping, so an application will never start.
Solution:
Change a condition so that mOpenOnClick becomes true only when the list
has been collapsed (mCollapseOffset > 0).
Bug: 30153542
Change-Id: I576fb6c8b6a91d79c1e0d46d069146779f4dbd17
(cherry picked from commit 4f3a843ea9)
Use application context to get the screen's display metrics.
Bug: 30127070
Change-Id: I2c453c494ef210c12d89fc7e3ff026728f9ecb0f
(cherry picked from commit afb38c5cc4)
View attachment calls jumpDrawablesToCurrentState(), so the view state
needs to be set up prior to attachment. For views that are already
attached but are being moved to a new position, manually jump.
Cleans up comments in methods that were modified.
Bug: 29978498
Change-Id: Ica27b2c60ad7ee98b9d1e4912c4f8b8c248af88d
(cherry picked from commit 26489e1688)
There was a short period of time where KeyguardScrim already went
away but status bar wasn't drawn yet, so we didn't consider it as
a wallpaper target so the wallpaper was invisible for a couple of
frames. Now only remove the scrim after the status bar has fully
drawn.
Change-Id: Ibf23b9e1277b6ce06e4ce70c9b7a5db9cbefce00
Fixes: 29643498
With sensitive notifications a user could get into
a situation where the groupsummary would not be cleared
because its dismissability was never updated and based
on the visibility of the veto button. This is now corrected.
This Cl also cleans up the veto button handling overall and
ensures that there's no stale state arond it.
Change-Id: Ic7df8d382146d7863ee551c1daa8ba5ed384c7b5
Fixes: 30056258
(cherry picked from commit 9e624e732a)
The grow logic in SpannableStringInternal#setSpan assumes that the
size of mSpanData is consistent with that of mSpans, in particular
that if the latter doesn't need to grow, neither does the former.
The copySpans() method didn't enforce this, creating an mSpanData
array only big enough to hold the data.
This patch documents the invariant in a comment and enforces it.
Bug: 30359314
Change-Id: Ie25db70a76836e97af8476a7f5c10cb4b976c1cf
(cherry picked from commit 83549088c6)
- Sometimes there is no window attached to the app token during a
rotation. In this case, we also want to return a valid dock side, so
we check for hiddenRequested instead of traversing the windows
of an app window token.
- The logic to notify SystemUI about rotation changes never really
worked. Remove the dock side check as the dock side is guaranteed
to change if we change the screen rotation
- Also clean up visibility methods a bit.
Test: Manually tested the interaction when in docked state landscape,
and going home with locked home rotation like 20 times. Also tested
multi-user interaction with docking.
Change-Id: Ibcd181cadc9bc5a97dbd20e67d15bb1c88de5b97
Fixes: 29569499
When activity is finished we first looked for next activity to
show in focused stack. If real next activity to show in place
of finishing one is in the same non-focused stack, we didn't
fully complete the dismissal process and activity was stuck in
FINISHING state.
This CL checks if we're trying to finish visible activity in
paused state and destroy it immediately if top running activity
is visible - same as we do for pinned activities.
Bug: 29458854
Change-Id: I0d5ceb2daa45c0628d89417c8456e132996bcea9
(cherry picked from commit 7318d63ba6)
Some apps rely on their drawables not getting not-visible hints via
setVisible when the window visibility changes. This manifests as
additional animations, such as crossfading from placeholders when the
window becomes visible again.
Apps should be able to handle this case in the future now that we have
more detailed reporting via onVisibilityAggregated, but to keep
existing apps working as-is, ImageView now operates in a compatibility
mode for targetSdkVersion < N and will only dispatch visibility
signals based on the same triggers used in M. New apps get the more
detailed signals.
Fix a bug where window visibility dispatch via onVisibilityAggregated
would double-dispatch "not visible" when the window is transitioning
from GONE => INVISIBLE or INVISIBLE => GONE.
Make the growing set of compatibility check fields in ImageView
static, matching the pattern from View.
Bug 30216207
Change-Id: I88875260bf6aaa23687c7d51353de8d633383531
Log the error messages when trying to mmap the remote
cursor's ashmem file descriptor.
Bug: 31046363
Change-Id: I52839d1246f84a0a2d7b1e850933fcdf6056b884
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug: 31055479
bug: 27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
(cherry picked from commit ad24f96def)
For Germany (T-D) 73240 and 3011 is added to whitelist
For Macedonia (TMMK) 129005 and 122 added to whitelist
Bug: 30908153
Change-Id: I892a172994de62d90df313e9f7aaa17356092448
Fixing problem (mismatched <div> tags) that caused the page text to be
obscured. See first comment for doc stage location.
bug: 31046432
Change-Id: I82227fd29764755885458c1c011db534325fcde3
The "allow hold" carrier config option was added to meet new carrier
requirements. However we do not wish to enforce this option on older
devices.
Bug: 30449352
Change-Id: I4bf6dab0a200bdd2511c67b8134c6c0dc4b7e5a8
Bypassing work challenge in freeform mode was trivial by just keeping
work apps open in freeform mode and then switching focus to them from
another app.
Because the only interception point is startActivity this never
triggered work challenge.
The solution is to trigger the check on focus change events and also to
allow passing the result back into the freeform stack instead of dumping
our user out into the homescreen.
Change-Id: I141ecf90b5f0e708a21d27141b6fec6074e5d475
Fix: 30693465
Add QS tiles to the backup list. Non-system tiles will get removed
since they won't be installed when restore happens.
Change-Id: Iccf6e773384c45bd4d1f10c21aa8af356b3920d2
Bug: 28782938
To workaround b/30808791 without changing the NanoApp API,
we make the assumption that if the most significant byte
of our four-byte app ID is a lower-case 'L', then this
is a Google Nanoapp and thus we should use "Googl" for
our vendor ID, and set the most significant four bytes
of our eight byte app ID accordingly.
Bug: 30922112
Change-Id: I155dff58cdda1ef36a68e6d25df1e9059b1252f1
We avoid ever using uninitialized stack for the value of a handle
which we pass up to the Java layer.
In cleaning up this code a little, we make more explicit a failure
case which already existed: The Context Hub properly loading a
nanoapp, but our Service code failing to set up the infrastructure
to track it. We chose to tell the Java layer we failed in this
case, and more importantly, provide a consistent handle value.
Note that the INVALID_APP_ID is not known by the Java layer, but
it is consistent so future Java code could react to it. At
the very least we will now always have consistent behavior when
this situation happens.
Bug:30795236
Change-Id: Id4eada529aa1b223867a47985ef1d5c1ba346ea3
