During the PiP animation, we have two basic requirements:
1. We need to scale windows to the pinned stack bounds.
2. We need to halt resize and movement notifications to the client.
As we end the animation, we need to disable these states at differing
times. First we need to deliver a final resize and movement notification
to the client for it's new position. However, Surfaces may not
immediately resize (in particular in the case of child windows,
it may be some time!), furthermore Surfaces may resize at different
times so we need to persist scaling on a Surface by Surface
basis after reenabling resize notifications.
Bug: 28559097
Change-Id: I6d52a3e213e08a34f4c0eea892b2a84cd4c20e18
We want to calculate the scaling factor we need to have
the content area of the surface (not including insets) to reach
our desired size, otherwise we will seem to scale the insets
up or down over time.
Bug: 28559097
Change-Id: I86dbd5fc902b5d380d33dba626c6694b3c57ff25
am: 890101ccb3
* commit '890101ccb338fe0633b07f0197fe5c9957a4870d':
Updated link to material design page.
Change-Id: I6d88350c3f4681fa998c514e88532fe117c304dd
am: 26aea1383a
* commit '26aea1383afcaef13cedd5792088d3a3d6859f44':
Updated link to material design page.
Change-Id: Ia3e66198caff48e12fa03f471ecf80cb9bb4901e
am: ef033cd807
* commit 'ef033cd807e23643b160bcb2152ba36eb3b8a2ed':
docs: Updates to GIFs on WH home page
Change-Id: I13a20a619f9adf79901306585e2e17e28f6ebe84
- Do not override minimized state in SysUI when IME adjust change
comes in.
- Do not animate IME adjust if we are already animating for minimized.
This lead to problems that we animated the minimized state with the IME
adjust values.
- Make sure to update state after checking whether the IME adjust is
animating. This is to fix an issue where sometimes the IME adjust
animation didn't run because the old target was wrong.
Change-Id: Ie35e2f943a4cda99ffdc6f14663d892863759e46
Fixes: 28819201
...because the other in-VM reference to that FD means that it won't
get GC'd after we release our local reference to the containing object,
and we wind up with the feeder end blocking on write to a still-fully-
open pipe rather than being made aware that the read end has needed
to shut down.
Bug 28756668
Change-Id: I90b6aaeaabe7d912d96d7ef57c24f68d87d9d0ab
am: 5ca058d38e
* commit '5ca058d38ec22e0a160859aee8d774dc59bf759c':
docs: Updates to GIFs on WH home page
Change-Id: I280afb495fb816376e368ca16c2a401adfeeb3a2
am: 97fd87bd5f
* commit '97fd87bd5fbe4ccc1cca4f3eda2df7006fefecf3':
docs: Fix attr link in support lib docs.
Change-Id: I5b502a43efade5c85c8cd625e3d26f6200140362
am: 252b996fee
* commit '252b996feea8b9d5c9c0101ca35753099feba15a':
docs: Fix attr link in support lib docs.
Change-Id: I0164d7eed51b156767ddabc63804044db9e54be4
am: eea825d67e
* commit 'eea825d67e271ac4adc48fd696d8cf7f4cbe0dc5':
docs: Fix attr link in support lib docs.
Change-Id: I5901dcbd2ed759ea559dc071309329eb008950dc
This issue was breaking the build in nyc-docs; Michael made the fix
there, so I'm cherrypicking it back to our doc branches.
Change-Id: Ie15bd056ebf939270dfcd45dda56946ed41b56f0
(cherry picked from commit ae316f842431254ce364cda4f1edde6fe607ab43)
DD asked to pull this sentence out. See first comment for doc stage
location, but if it builds and stages without trouble I'll go ahead
and submit.
Change-Id: Ie9844cf60bfd723dea8dbfd42eb04465dde84ae3
The NPE is because createConfirmDeviceCredentialIntent returns a null
intent when it founds that user does not set a secure lock.
So the fix is we should check is the user set a secure lock screen as well.
The reason the crash only happens in multi-window flow because
we have null checking in
the normal flow (i.e. interceptWithConfirmCredentialsIfNeeded).
But I think we better check it explicitly.
Bug: 28716456
Change-Id: Ib204cd02c0007bd1df36908bb3b5254ec4ffb914
