This CL adds new code to handle the support preferences classes. If the
support library is not installed in the project, it will use the regular
inflater as fallback.
This also ports the hotfix that used to live in Android Studio to
support "*Compat" preferences to the regular BridgePreferenceInflater.
Change-Id: I8ff34455d46b6188f0931e821d329224f6a0a343
(cherry picked from commit 90110d50f4c48ea7ec196a068f55b0eb86114c46)
The pointer to the root group in the VPathRenderer is not freed anywhere
in the Java side so we need to take care of it on the "native" side.
Change-Id: I2ca60b1f0e975a0b5d29799c5f6f31b5f8d42b9d
(cherry picked from commit ffdb1b241d9458196403c8f16264aa7053487323)
When activity transition triggers a rotation change, the starting
window will normally be the top window at the time we try
to select the window animation. However, these layout params won't
have the apps rotation animation set (as the client code will set that
on the real window, not the starting window). Eventually we would
like to add API to specify rotation animation via manifest to solve
this problem cleanly. In the mean time, we can force a specific rotation
animation from the double tap gesture, and clean up some camera
ugliness. We accomplish this by attaching an animation hint to
ActivityOptions.
Bug: 28838855
Change-Id: If052cd8cbae76651da43f3b4c590cd9dcc1afc0f
More efficient than an ArrayList since we do a lot of remove operations.
Change-Id: Ic4c89df4560066f1a3ab0e71a3b180a9734f9cd6
(cherry picked from commit 12754d621b20e6a925999096ab6f21c4cbfe594a)
This is a follow up CL to my previous CLs [1][2] that introduced
InputConnection#commitContent(InputContentInfo, Bundle) API to enable
IMEs to send a content to the target application.
With this CL, IME developers are able to temporarily expose
InputContentInfo object to the target package without permanently
granting URI permission. Although calling IMS#exposeContent() is
allowed only for the IME that is currently selected, the client is able
to request a temporary read-only access even after the current IME is
switched to any other IME as long as the client keeps InputContentInfo
object.
Here is a sample code snippet about how to use this mechanism.
[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
exposeContent(contentInfo, getCurrentInputEditorInfo());
getCurrentInputConnection().commitContent(inputContentInfo, null);
[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}
[1]: Iaadf934a997ffcd6000a516cc3c1873db56e60ad
152944f4909c47917473293b258d266435c6ab35
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588b098a1af678d4e33a234ef1ce783b2
Bug: 29450031
Change-Id: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
Commit 028029730b copies tree properties when mutating a vector
drawable. Layoutlib does the same.
Bug: 28974071
Change-Id: I5075b35e517df4ce32a91e2926d9caa02a0c2606
(cherry picked from commit 5ee73b3466090828acdc87fffd95247b6ace6440)
tools:minValue and tools:maxValue can now be used to specify
the min and max values of a NumberPicker in the layout editor.
Bug: http://b.android.com/205084
Change-Id: I10037726346c82ca3cf84d255727b84a12ac0349
(cherry picked from commit 3c2b1c65c907fa4f2cae102507688fd0bffd1b24)
We used to only calculate the default property value if the attribute
was not set in the XML. The properties palette can make use of the
default property values even if the value is manually set so adding code
to support that use case.
Bug: http://b.android.com/210957
Change-Id: Iaade37cbe78329f7be3d34ffbf8fc8e7449cfcaa
(cherry picked from commit 1a6c26f66fd355822a0fa7e08c9ca93582e9fc8d)
Path_Delegate.reset was not clearing the last point when called. This
caused some vector drawables that relied on relative position to fail to
render correctly.
Bug: http://b.android.com/91383
Bug: http://b.android.com/203797
Change-Id: Id250ecf8a5a5c66671aa8d3ddd213996f824fd56
(cherry picked from commit d6db7133af7b5aed76d83c17b60b27742608a2df)
This allows previews to use appcompat attributes like
app:backgroundTint.
Bug: http://b.android.com/211349
Change-Id: Iaa5f1612c58a6a27d3948bfe1bc0373098c57720
(cherry picked from commit 2ddddbc86314fa16c51d0e5f0d6e55e0a6676d26)
Manually setting the encoding makes kxml to ignore the BOM at the
beginning of the file and fail to parse some files. If null is passed,
kxml will check if there is a BOM and default to UTF-8 if there is none.
Bug: http://b.android.com/38055
Change-Id: I170d8fbb7567d2266f36a7768d4e63d9c2fa8286
(cherry picked from commit 89a5812b9eb8c62411a88f472468f3c978b8cfcd)
If the radius is 0, do not try to paint the shadow. In some views, a 0
radius for the outline might be returned causing an exception when
painting the gradient. In those cases, simply disable the shadow.
Bug: http://b.android.com/207664
Change-Id: Idb937083d42ca02bbace843b881f61aa88fe47f2
(cherry picked from commit 5bc40214817fc6bd4ee541763d40522ae94f1d82)
When painting a vector drawable, alpha transparency can come from
the path color, or from the overall android:alpha attribute.
Include both when drawing.
Bug: http://b.android.com/206667
Change-Id: Id946fdeaf72b981597787f5357ef3a90a471c584
(cherry picked from commit 8cae3b0ce6f527e7b90d46755ffaf6d3d4d65114)
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
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
