am: f975b74c0c
* commit 'f975b74c0c60160092262fbc05f42f7e2584f0bd':
docs: Updates to multi-window and related docs.
Change-Id: I74022d22deb99d5cd83d7ed73658d65f7aa05fb3
am: d29c26073e
* commit 'd29c26073e97e4c6e7825641cf6e76720df395e3':
docs: Updates to multi-window and related docs.
Change-Id: Ic4be60debb41d074d717bfb0989125299428831a
am: c88130c572
* commit 'c88130c5724227b3ba7ef0b5ef4476fedabca650':
docs: Updates to multi-window and related docs.
Change-Id: I308c988e3a93737a478f9f2445b512e86f218643
am: 8263d6c0a3
* commit '8263d6c0a35a5467764ed12d6586ab176fdc15ff':
docs: Updates to multi-window and related docs.
Change-Id: Ia571cf3a38f1cd621bba6bc35d9b2b836361d7b5
am: 4d93a21980
* commit '4d93a21980f7e82bd346ad9c3a18c0c932d09253':
docs: Updates to multi-window and related docs.
Change-Id: Ie12e3c25417943582aa1db1bf476e53a41838745
Continuing work from CL http://ag/1010439 , addressing comments on
that CL that were left after it was submitted.
See first comment for doc stage location.
bug: 28588696
Change-Id: I9d92008ed30582657d97f162958b8efd5c317999
...cannot be cast to LocalBinder after a crash
Turns out, if you called removeProcessLocked() with an old ProcessRecord,
we could get in to a bad state -- if we had a new process with that same
name already running, we would kind-of blow it away as a process name,
but not as much else. So the next time we wanted to run a new thing
in the process, we would start a new second process and the two could
get mixed together.
Change-Id: I05e0463bd55f57f5e07f0b804ed9fd8c4f98a5a5
am: e1293b7d07
* commit 'e1293b7d07f5854337fef35a2e3b4338df90866e':
Remove task based on object rather than position
Change-Id: I101dd1a8be5423a9fa7280d0b0a6f8361a9b001e
am: 0f6a6c4bc1
* commit '0f6a6c4bc15fee726ef9aeb0d99b1204767f431d':
Don't allow any app to specify rotation unless in home task
Change-Id: Ie7f0065543addcf51df5b24b8b67d7f12d9001aa
Since the transition is picked from layout params from the activity
below, we need to manually override it.
Bug: 28750938
Change-Id: I7351c7d8bd14a393cba51d6afb1e644204217440
The previous logic was racy/buggy in a sense so that the non-home app
could still force the orientation when the divider was still minimized.
The logic is cleaned up so only the home task can force the orientation
in multi-window.
Change-Id: I9eccf86d9fa442375d6eca400cb6ac0815c9fa10
Fixes: 28675152
Framework edition
Add a matching onAttachFragment method to Fragment to match the
fragment host version.
Bug 28760393
Change-Id: I5f50b3446449cae7110da6b4e468ee80f413e1e5
Clarified behavior when activity is resized or put in fullscreen
mode, per b/28580007 . Also (per email from o-o) removed misleading
statement about when onStop() might or might not be called.
Both changes can go live now (multiwindow update applies to DP1 & 2,
and onStop() clarification applies to all versions of API), so I'll
submit as soon as this is approved.
See first comment for doc stage location.
bug: 28580007
Change-Id: Ib008f24e5796ec7810b67c91e512e679680d4afd
Messages with a "null" sender indicating a message from
the local user did not correctly unparcel.
Change-Id: I7d42d5dc407ebd8d1e3b5451f72f52cc1543a32d
Fixes: 28763122
This change fixes the issue where
getChildVisibleRect(View, Rect, Point, boolean) call isn't recursive.
The method was introduced in I49550ed4082bcbdcfe4643b962b50f3308092525
Bug: 28514727
Change-Id: Ib6b0fb67ca6c700b44f645319c23b1213a2742d4
Rotation could change again after updateDisplayInfo is called. We
need to set stack bounds even for fullscreen stacks in this case.
Otherwise the bounds will be incorrect until it's rotated again.
bug: 28611814
Change-Id: I31289524a9ceacaaaa66924e9bf6cbe88fd83f99
