Upcoming platform features need to cluster apps together into broad
categories to help summarize information to users. (For example,
when presenting battery, network, and disk usage.)
We are tightly limiting the set of categories to keep them easily
presentable to users when summarizing information. This feature is
not designed to be a general-purpose taxonomy, nor should it be
allowed to become one.
Older apps may not have defined a category in their manifests, so
allow the installing app to define a category on their behalf.
Test: builds, boots
Bug: 33815939
Change-Id: I785b882ee7c18072ef47d56e0fc19ad72888e1b7
Support a system property on debugable builds to
override the max number of managed profiles to
allow easier dogfooding of multiple profiles.
Support 3 different badge colours for managed profiles.
Bug: 30473760
Test: runtest -c com.android.server.pm.UserManagerServiceCreateProfileTest frameworks-services
Test: runtest -c com.android.server.pm.UserManagerServiceUserInfoTest frameworks-services
Test: manual - attempting to create 2 profiles with adb fails, passes once I set the property.
Change-Id: Ie7fb19048a04a01572666f229283152254d0ffc3
Shadows could be painted outside of the allowed drawing region
for the components for which they are the shadow.
Bug: http://b.android.com/215402
Change-Id: I2d2821b745147f3723e8f11d648094fcd684fe51
(cherry picked from commit 9702fffc768db43d0aba4fb1bea54af50af11361)
Settings needs to access a variant of getInstalledApplications() which
takes a |userId| argument. Since this is not currently exposed by
PackageManager, Settings calls into PackageManagerService directly. This
is ugly and breaks the regular abstraction layer hierarchy.
The CL fixes the problem by exposing the required variant of
getInstalledApplications() as a hidden API, analogously to what was done
before with getInstalledPackages().
Bug: 32692748
Test: Will be CTS-verifier-tested together with Settings
Change-Id: Id9c4e8e18524d312159821f1a4d5527263c7e950
On layoutlib, requestApplyWindowInsets wasn't being passed up to
ViewRootImpl so onApplyWindowInsets wasn't being called.
Test: Added new test testApplyWindowInsets
Bug: http://b.android.com/169308
Change-Id: I8f3174dc2879a7e6c3db1628a1bfb1c023d88efc
This introduces a new feature of the IBinder command protocol
to allow the shell command implementation to call back into
its caller to ask it to open files in the calling context. This
is needed so that commands that have arguments specifying files
can open those files as the calling shell, not the system (or
whatever) process.
To test this all out, move the "am start" implementation over
to ActivityManagerShellCommand, in particular along with its
option to specify a file in which to write profiling data.
Test: Manual
Change-Id: I0c1e3857defefbd19a2ac29413aafbb34b1e48a3
If an attribute is not an actual theme reference, the call to
Resources.Theme.resolveAttribute will fail in layoutlib. This would
happen for example for color values.
The call in the Android framework simply returns the value.
Bug: 31553972
Change-Id: Idda768a659d94a6c3f848dc960303cf4241325c3
Before this CL, only vertical offset was used when calculating the view
bounds in the ViewInfo object. This caused that in some cases where padding
was used, the bounds didn't match the actual output.
Bug: http://b.android.com/222231
Change-Id: I4889caee2811556442dc6ec97c1307661a798392
When we are displaying menus we do not care about that theme setting as
we always want to display the actionbar and the menu.
Bug: http://b.android.com/212320
Change-Id: I3b6200cc42e3c525a3763d14d423ee8371acc2f1
(cherry picked from commit 71eb800c0bb21b0e4cea3b29235ac4e544e765b2)
It turns out that although the method was public, the class is package
protected and hence the "Accessible" call
Change-Id: Iec69ad15db4c22d472a941dd335b6cf7789eea09
(cherry picked from commit ff78c344e63c8665ab7b0773b91e473b4fe650ff)
Make the release of all the VGroups deterministic once the root group
has been freed by a finalize call.
Also, free and clear the children array.
Disable assert in DelegateManager that would slow down layoutlib when
there are many delegates and assertions are enabled (dev and canary
builds).
Bug: http://b.android.com/214026
Change-Id: Ic7775d360ae4997f54f30fb75851879acaf8d824
(cherry picked from commit f6d8bba638baedc39d1d8f7bd3c69f4956819c71)
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)
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
152944f490
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588
Bug: 29450031
Change-Id: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
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)
