ID resources that get generated on demand with the
notation @+id/name were previously not given the
appropriate type ID offset when being built as feature
splits.
This change declares an ID type ahead of time so that
the type ID offset is applied before IDs can be generated.
Bug:30607637
Change-Id: I122a9133cb01b35e9892103ec52fc228dc65bf1a
This changes the default implied feature of 'android.hardware.touchscreen'
to 'android.hardware.faketouch' if no 'android.hardware.touchscreen'
feature is requested, required or otherwise.
Bug:30571641
Change-Id: I1e41242d4b1dc549cf69741d2a309baf476d084e
Use the same name for the static and shared libraries so that the module
definitions can be shared.
Change-Id: I1578ee7044689194ae1baea4d71f1b0e8737505f
When quickly toggling between two apps, app could be resumed while
it's stopping but not yet stopped. Upon resuming, it could have
surfaces that's marked mDestroying and waiting for the stopped
to be destroyed.
We need to dispose these surfaces properly. If the window is already
removed, we destroy them. Otherwise, clear mDestroying flag so that
the window is ready to be used again. Leaving mDestroying=true makes
the window ineligible for certain things such as receiving wallpaper.
bug: 30255354
Change-Id: Id881653550595ab8e702d6950949bf202ac5a0d9
AAPT will continue ahead without reporting an error if a file
failed to be added to the ResourceTable. This would cause crashes
later when the file was assumed to be present.
Bug:30200166
Change-Id: Ieb2daf97ccf0345153b6f4598d130a38d108c937
This is temporary, until we have proper attribution for additional
emoji data.
Bug: 29939737
Change-Id: I5b97c8e055fa2ccf44b13bf801f681b860d47286
(cherry picked from commit f874a1949a)
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
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
152944f490
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588
Bug: 29450031
Change-Id: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
Previously, AAPT would match locales even if they had different
explicit scripts if the requested locale was just a languages. Now
we require explicit listing of the languages with different explicit
scripts in order for the locale to be included.
Bug: 29412034
Change-Id: Ia118a5a7f9aec49f6c3c53b9195a0ae1a57f53fd
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
