This is useful when we want to write an APK and keep the same
compression parameters as the original APK.
Test: Unit tests pass.
Change-Id: I3afcae1c8727e429b08c9ac7359cf0789ff4abfc
- Add <feature-group> to ManifestFixer.
- Support <meta-data> in <instrumentation>
- Add support for <bag> and type="configVarying". Some CTS tests use this
old notation, we need to support it (even though configVarying isn't
anything supported by the framework convention).
Change-Id: I6946fa633ce513ea8437c1496db883cf27dcf6de
Test: make aapt2_tests
The strip command takes an APK as argument and a --target-densities flag which
contains the list of screen densities for which to optimize the APK. All
the resources that would be unused for a device having the given
densities are stripped from the APK leaving only the ones actually being
used.
Test: Manual.
Change-Id: I68368b00876a18ccdbbfc0a8dd265bd361117933
In Change Icbfab2fa, a new justified alignment for text is implemented.
We make layoutlib compatible with those changes without implementing
the new alignment.
Test: layoutlib tests
Change-Id: Ic8254f0f4b2915d654124874fee72c90fd8aa6c6
This change adds APIs for instant apps to store cookie data
that is presisted across instant installs and across the
upgrade from an instant to a standard app. Standard apps
can use the cookie APIs but when they are uninstalled the
cookie is also deleted. The cookies are kept longer than
the instant apps as they are much smaller - 16KB by default.
We can change the cookie size via a system setting i.e.
after we ship we can increase size if needed.
We also add internal APIs to surface information about
installed and uninstalled instant apps which should be
used for showing them in the UI. For this puporse we store
the icon, permissions, and label of uninstalled apps. If
the app is re-installed we drop this meta-data but keep
the cookie around. If we have cookie data stored and the
signing cert of the app changes when it gets re-intalled
we wipe the cookie.
Test: CTS tests pass; hiddent APIs tested manually
Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5
As a preparation CL to work on Bug 7254002, this CL simplifies
the layoutlib mock class of TextServicesManager, which was mostly
as-is copied from the real one by a previous CL [1].
Although keeping maintaining one real class and one stub class is
still painful, it should be much better than maintaining the real
one and mostly the real one.
[1]: I8c25f4919a2e97b56f705b59747e81cb6f45b07b
f149ca784dd09bd97bd479ae254935ff3edaa617
Test: make layoutlib-tests layoutlib
Test: No new test failure in the following command.
java -Dtest_res.dir=frameworks/base/tools/layoutlib/bridge/tests/res -cp .:/usr/share/java/junit4.jar:prebuilts/tools/common/m2/repository/junit/junit/4.12/junit-4.12.jar:prebuilts/tools/common/m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar:prebuilts/misc/common/tools-common/tools-common-prebuilt.jar:prebuilts/misc/common/sdk-common/sdk-common.jar:prebuilts/misc/common/layoutlib_api/layoutlib_api-prebuilt.jar:prebuilts/misc/common/kxml2/kxml2-2.3.0.jar:prebuilts/tools/common/m2/repository/com/google/guava/guava/15.0/guava-15.0.jar:out/host/linux-x86/framework/layoutlib-tests.jar:out/host/linux-x86/framework/layoutlib.jar org.junit.runner.JUnitCore com.android.layoutlib.bridge.intensive.Main
Bug: 7254002
Change-Id: I03e95bae15dc04cc0df20c4fb7cc86c5f3c6ccde
This should affect only builds that call clang-tidy.
Without this change, clang-tidy has segmentation fault
when compiling several files in the incident_* directories.
Bug: 34740546
Test: build with WITH_TIDY=1 and
DEFAULT_GLOBAL_TIDY_CHECKS="*,-readability-*,-google-readability-*,-google-runtime-references"
Change-Id: Idfd46f36c01ccdd401eb54b750bc9d962c29ddeb
Some apps may want to check whether they are trusted to install apps on
the device, so they can prompt the user to go to settings and mark them
as trusted before they do an intensive operation like downloading an
apk.
Test: cts-tradefed run cts -m CtsExternalSourcesTestCases
Bug: 31002700
Change-Id: Icd9d04daa157e6733decba245ec251ce4acd4122
When in pointer capture mode, mouse pointer disappears and
further mouse events are dispatched to the focused view
in the window which has requested capture.
The captured events have the source SOURCE_MOUSE_RELATIVE
belonging to SOURCE_CLASS_TRACKBALL. They are
dispatched through dispatchCapturedPointerEvent /
onCapturedPointerEvent. There is also a new listener.
Pointer capture mode may only be granted to a currently
focused window, and will be canceled upon a window focus change.
Test: cts-tradefed ... --test android.view.cts.PointerCaptureTest
Bug: 30897034
Change-Id: I6e5934aa415ac2b6dda1cee173d0f23e5021af84
Apps can now declare in their base APK AndroidManifest.xml
that they want to have their split APKs loaded in isolated
Contexts. This means code and resources from the split
get loaded into their own ClassLoader and AssetManager.
<manifest xmlns:android="..."
...
android:isolatedSplits="true"
...
In order to make this more useful, splits can declare dependencies
on other splits, which will all get pulled in to the Context
and run as expected at runtime.
A split declares its dependency on another split by using the
tag <uses-split> in its AndroidManifest.xml:
<manifest xmlns:android="...">
...
<uses-split android:name="feature_split_1" />
...
A split can have a single parent on which it depends on. This is
due to the limitation of having a single ClassLoader parent.
All splits depend on the base APK implicitly.
PackageManager verifies that no cycles exist and that each dependency
is present before allowing an installation to succeed.
The runtime will then load splits based on the dependencies.
Given the following APKs:
base <-- split A <-- split C
^----- split B
If an Activity defined in split C is launched, then the base,
split A, and split C will be loaded into the ClassLoader defined
for the Activity's Context. The AssetManager will similarly be loaded
with the resources of the splits.
A split can be manually loaded by creating a Context for that split, defined
by its name:
Context.createContextForSplit("my_feature_split_1");
All installed Activities, Services, Receivers, and Providers are accessible
to other apps via Intent resolution. When they are instantiated, they are
given the appropriate Context that satisfies any dependencies the split they
were defined in stipulated.
Test: WIP (CTS tests to come)
Change-Id: I8989712b241b7bc84381f2919d88455fcad62161
The color mode lets an application request a wide color gamut for
a specific window. This will also be used in the future to request
HDR. The color mode is currently either default (sRGB) or an undefined
wide gamut color space chosen by the platform. These attributes could
later be used to choose a specific color space if we deem this important
or useful.
This change also renames the various "colorimetry" attributes and
constants to "color mode" for consistency. These symbols were
added in O and can be safely renamed.
Test: CtsColorModeTestCases
Bug: 32984164
Change-Id: I4d4691dd12dbe3f3aa6a5cf893cff39aa16c739e
For linking ActivityStack in AMS to TaskStack window container in WMS.
Change-Id: I8b9eaef49e62854d59b22d27f80f5935a5a4d7fc
Bug: 30060889
Test: bit FrameworksServicesTests:com.android.server.wm.StackWindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: Existing test pass and manual testing.
This is 2nd attempt of Id10ca97f6f6f5bbe4999c1ad2736423a204d6e87.
The root caus of crash is due touching null pointer in nUnrefFamily.
After above change, native object may not be created on error case.
In that case, nUnrefFamily can not be called. In addition to this issue
there is also memory leak on error case. This fixes it by introducing
abortCreation method.
Also this contains fix of layout lib breakage done by jgaillard@.
Originally submitted by Ic8872a43993bcb0a157c5e3f0ce423af9b47f606
Here is original commit message of reverted change.
minikin::FontFamily no longer has addFont function, instead it accept
vector of Fonts in its constructor. To follow this signature change,
holding minikin::Font instance in native and build minikin::FontFamily
instance in FontFamily.freeze() method.
Bug: 34042446
Bug: 28119474
Bug: 34378805
Test: hwui test has passed
Test: m layoutlib layoutlib-tests
Change-Id: Ic34ebaa8191273d4c9f49c43124f15a1da5f7b78
Add a new flag to disable versioning of Transition related XMLs.
Transition support library will use this to handle these XMLs on older
API levels.
Test: make libaapt_tests AaptTestAppOne
Bug: 34427868
Change-Id: I66e81cca049e71ef6704177b2ca21c9cdeaff78f
This change creates a new FontManagerService, in charge of providing
font management data. It exposes a public API to retrieve the
information in fonts.xml without accessing it directly. To do this,
it also refactors FontListParser's internal classes into a new public
FontConfig class holding all the font data.
getSystemFonts() returns all the available information in fonts.xml
as well as file descriptors for all the fonts. This allows us to
share the memory consumed by these files between all clients.
Bug: 34190490
Test: See attached CTS change in topic
Change-Id: I0e922f8bcc9a197a1988d04071eb485328d66fb7
This change adds support for static shared libraries that
emulate static linking allowing apps that statically link
against the same library version to share a common
implementation. A library is hosed by a package in a standard
APK.
Static shared libraries have a name and a version declared
by a dedicated manifest tag. A client uses also a new tag
to refer to the static library it uses by specifying the
lib name, version, and the hash of the signing certificate.
This allows two apps to rely on two different library versions
and prevents impersonation of the shared library by a side-loaded
app with the same package name.
Internally apps providing static libs use synthetic package
name generated from the manifest package name and the library
version. This allows having different "versions" of the same
package installed at the same time.
An application cannot be installed if a static shared lib it
depends on is missing. A used shared library cannot be uninstalled.
Shared libraries can rotate certificates like normal apps. The
versions of these libs should be ordered similarly to the version
codes of the hosting package. Such libs cannot use shared user
id, cannot be ephemeral, cannot declare other libraries, cannot
rename their package, cannot declare child-packages. They must
target O SDK. Also they cannot be suspended or hidden or their
uninstall blocked. Generally, speaking policy regarding code in
static shared libs should be applied to the packages using the
library as it could have just statically linked the code.
We now have APIs to query information about the shared libraries
on the device in general. To clients static shared libraries are
presented as multiple versions of the same package which is how
they are declared and published. Therefore, one can have two
versions of the same package which means we need way to query
for and uninstall a specific version of a package. Also static
shared libs can depend on other static shared libs which are
versioned packages. To ease representation we add the concept
of a versioned package which should be used in the case of
static shared libs.
A client can see only the static shared libs it depends on and
more specifically only the versions it depends would be retrieved
by using the standard package manager APIs. There is a new
dedicated API to get info about all shared libraries which
would provide data about all static shared lib versions. Also
these libraries must use v2 signing scheme.
Test: CTS tests pass
bug:30974070
Change-Id: I4f3d537ee7a81f880950377b996e1d9d4813da5c
Reason: The changes that this CL depends on, had to be reverted.
This reverts commit 7a1cab2c9606ca5aab0f030c0022b864d5c05888.
Bug: 34378805
Change-Id: I6bd05082060199c1907743b9f72d4c2438371aa6
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Icc19b2fbc05f40dcf8c3fc4abf718c373dc8d4f6
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Ib444829a2d222125f64ff19e8218823fa78373f9
