libziparchive-host is no longer necessary, and mixing libziparchive-host
and libziparchive can cause ODR violations.
Change-Id: I623c0c5579e28f26a6e1db7bd953f33ed1ca68cd
Doing so is likely to trigger log messages in the future, and will
hinder diagnosis of other problems.
Bug: 30292538
Change-Id: I2cb8c507e43d06d4afa7e35b564416c1474c81d1
Use the same name for the static and shared libraries so that the module
definitions can be shared.
Change-Id: I1578ee7044689194ae1baea4d71f1b0e8737505f
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
2977eb7b6ce82309a1bb1ba4ab698f503cb0388a
[2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16d319e874a1d633f964a78266d5f3f2
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
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
