Layoutlib currently does not implement menus for the support Toolbar.
When it detects that an AppCompat theme is being used, it will try to
use by default the support Toolbar which breaks the display of menus.
This works around the problem by forcing layoutlib
to use the framework toolbar in menu previews (regular activities
won't display the menu if they use AppCompat).
Bug: http://b.android.com/210946
Change-Id: Ic1d162c6d74119ef42895776c3bc3851a9549120
- Added ActivityOption to mark a starting activity as a taskOverlay
activity. That is the activity will always be the top activity of the
task and doesn't cause the task to be moved to the front when it is added.
- Only set the starting window state of the ActivityRecord to shown if
window manager actually showed the starting window for the activity.
Avoids incorrectly trying to remove starting window for an activity that
didn't show any.
- When starting additional activity in a task, transfer the starting
window from the top most activity with a starting window. It is possible
the top most window does have a starting window like in the case of the
forcedResized activity.
- Only ensure visiblity of an activity we are starting in a task whose top
activity is a task overlay. They need to start in the visible-paused state
and not the resumed state which just causes extra churn in the system.
- Always add additional starting activities in a task with an overlay
activity below the overlay activity.
Bug: 28751186
Change-Id: I3624a4313ae9c406d42c67a3537f67ad685791af
This is a follow-up to my previous CL [1] for Bug 15922840 so that we
can clear the following variables in a more reliable way.
- PhoneWindowManager#mLastInputMethodWindow
- PhoneWindowManager#mLastInputMethodTargetWindow
The idea behind CL [2] is that when InputMethodManagerService (IMMS) is
switching from an IME to another IME, IMMS can send a signal to
WindowManagerService (WMS) to remember the current IME's inset so that
the system can continue using it to reduce jank until the new inset is
specified by the next IME. As summarized in Bug 28781358, however, if
the next IME does not show the window after the IME switch, WMS (or
PhoneWindowManager to be precise) keeps using the previous IME's inset
unexpectedly until the new IME shows its window. All we have seen in
Bug 15922840 and Bug 26663589 fall into this category.
The idea of this CL is just adding a hidden API to InputMethodManager so
that InputMethodService#clearInsetOfPreviousIme() can surely terminate
the IME transition state managed in PhoneWindowManager, rather than
relying on a hack of calling SoftInputWindow#show() and
SoftInputWindow#hide(), which actually does not work for Bug 26663589.
[1]: Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
[2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
Note that addressing all the corner cases in [2] still requires lots of
non-trivial change. Hence this CL focuses only on Bug 26663589 (and
the case we handled in Bug 15922840).
Bug: 26663589
Change-Id: Ib567daa009c1139858dccadcfc6a04465ebecf36
Modify the nDraw call that has been changed in the framework to return
an int with the number of pixels allocated.
Modify the animation initialization render call to use the actual
measured size (instead of 0,0) so the DrawerLayout is setup
correctly.
Change-Id: I198de05206382c6489056f7c3d9a1d328864321c
We need the attributes to remain public because people might still be
linking against them, but we don't want them showing up in the
documentation any more. Them showing up in the documentation also had
the side effect that it would accidentally mark the parent class of
attributes as @removed, which was not intended.
Bug: 28663748
Change-Id: I2f6eb09455fddf1086e6b24bc3bea5292e8e32b7
am: ea162c3c79
* commit 'ea162c3c7992b01d8d56766a94e56a0cee3fe3b2':
Prepare to replace windows across recreate().
Change-Id: I3f78aa81d76e0a71f616037c531e7755760b41cf
When the activity locally recreates itself, nothing
on the server side is able to prepare preserving windows,
or replacing windows. The activity was trying to defer
removing the old window, but it was just waiting
until the new one was created, not until it was drawn,
thus resulting in a flicker. It's easy to backpack on the
existing replacement infrastructure.
Bug: 28221875
Change-Id: I55fc4ca78e9e11809473fedd8b30b6a6350cf852
Adds the diff command and various small fixes to issues
discovered when diffing old AAPT built APKs with new AAPT2
built APKS.
Bug:22775504
Change-Id: I682a7fe1cf4b3efa7cbd5d18b333cf2d1046fe1b
am: 4c5e7a740a
* commit '4c5e7a740a632829b48b2324f80a43ab94ac7551':
Add namespace before attr name in defPropMap
Change-Id: I93619d0e2a28ef30b43e1fe8361142da3122cdda
am: 1d58c18081
* commit '1d58c18081a2f17afc964de2f261a699e11d6f02':
AAPT: ProGuard config for components in main dex.
Change-Id: I156e1805ad64798be891747a81561589d9543424
am: 28d6c1e493
* commit '28d6c1e49313bcb4823541d0114b2ff04f8cb446':
AAPT2: Accept a file with arguments when argument list is too long
Change-Id: I85c1aaa9818e9331a458892898204617af453b02
