On certain devices running Android M with unknown vendor
modifications. Setting the localeScriptWasComputed bit in
the resource parameters struct causes the translations
for many languages to fail to load. The app then
defaults to English.
This has been reported on the following devices:
Motorola XT1086, XT1096, and XT1586, HTC One, and Huawei
MediaPad 10 LINK.
This change works around the issue by never setting
localeScriptWasComputed in aapt and instead always
writing the default value of false.
Bug: 27872476
Change-Id: Id638d1d0e5f9dcb1c02e65d67667d76174c69b9e
Because there is a bug decoding paletted images in SDK_JELLYBEAN,
we need to avoid encoding paletted images for apps that support
SDK_JELLYBEAN and earlier.
BUG=27643907
Change-Id: Ib7d51ed87435cd36507915d62b0057c06f18b2b6
Previously, a bit was kept to find if the script of a locale was
explicitly "provided" in a resource. This was not backward
compatible, and failed in some edge cases when the package was
created with older versions of AAPT that did not set the bit.
The cases would happen when the old resource had an explicit script
specified in its locale, but since the "provided" bit was not set in
the package, we would assume that the script was computed by us.
This CL replaces the "provided" bit with a "computed" bit, so the
default value of the bit (set to "false" for old packages) would be
correct.
Bug: 27156990
Change-Id: I99e7f1ad8f70c90e25ab3640ed34cc1a6f8d1d64
This allows libraries to coexist a bit easier, since a lot of them
declare the same attribute. When used together they cause errors.
Bug:27101533
Change-Id: I649cf17bc587c4814f849d5ac522daf74495adcf
This allows libraries to coexist a bit easier, since a lot of them
declare the same attribute. When used together they cause errors.
Bug:27101533
Change-Id: I10327251636392e810637a79e7c9aa514f3f07a6
There are so many public resources that do not warrant comments
that having a warning that no one cares about is just producing
log spam.
Bug:21495023
Change-Id: I84e3b39c7139ee67fb5cb711d5ab466d8f4ef2e0
Many PNGs have multiple distinct pixels with zero alpha. This
CL allows us to treat all of those pixels as a single zero pixel.
This saves space in the color palette and also may help save
memory pages when we skip writing zeros.
There is also a potential disadvantage: if someone intended to decode
this image as unpremultiplied with particular transfer modes where
their color components have an effect even though alpha is zero,
this will prevent that. At the moment, we do not support unpremul as
a source, so this won't affect anyone trying to draw with the view
system.
This change originated in:
https://googleplex-android-review.git.corp.google.com/#/c/854580/
Change-Id: I702c7bd22d431cc7c775ed29bbd73c930f945ca3
Saves about 2 MB of encoded size across affected assets.
Also will enable more efficient decoding.
Specifically, encoded palette values are assumed to be opaque unless
alpha values are provided in a tRNS chunk. Before this change, we
would wastefully store many opaque alpha values in tRNS chunk.
Additionally, the decoder used to need to premultiply all of these
opaque colors, because the encoded data indicated that they had alpha.
Change-Id: Id21b3b31850c9db6149ced6d20ed5e0ce2d71c5b
Saves about 2 MB of encoded size across affected assets.
Also will enable more efficient decoding.
Specifically, encoded palette values are assumed to be opaque unless
alpha values are provided in a tRNS chunk. Before this change, we
would wastefully store many opaque alpha values in tRNS chunk.
Additionally, the decoder used to need to premultiply all of these
opaque colors, because the encoded data indicated that they had alpha.
Change-Id: I1d5400f71a0e3cb800fd0fc68a04c8c4069da8ef
* Add support for determining script from language and region.
* Add support for determining special parents of locales.
* Add support for smart comparison of locales with only a difference
in region, using the locale parentage tree.
* Fix LocaleData.matchScore() to not fallback to old locale matching
behavior if we can't determine a script.
* Allow four-character variant codes. (Previously, only five- to
eight-character variant codes were allowed.)
Bug: 7296673
Bug: 26589793
Change-Id: Ibde0a48c0564ff383b41068095a5cbacfe7b94bc
As the comment at the top of the file says:
STATUST: mingw does seem to redefine UNKNOWN_ERROR from our enum
value, so a cast is necessary.
Bug: http://b/26523949
Change-Id: I9d86cafdc47bbb9ce0e967cdde9315babc083432
The original intention for forcing ninepatches to be encoded as
RGBA (with alpha) was to avoid the possibility of the decoder
producing 565 output.
565 output is bad for ninepatches because dithering tiny images
that we intend to scale later leads to bad results. I would
argue that, since the new BitmapFactory does not dither, we might
now be ok to allow 565 decodes for ninepatches. However, we
will maintain the old behavior by disabling 565 decodes for
ninepatch.
There are two changes to PNG encodings:
(1) Allows ninepatch images to be encoded in any mode. Forcing
them to RGBA makes things awkward for the decoder. Currently,
BitmapFactory's png decoder checks every pixel for alpha.
That way, RGBA images that are actually opaque can be marked
as opaque, in order to optimize drawing. We want to remove
this complexity from the decoder.
(2) Make sure ninepatch chunks are stored in the png header. That
way we know immediately that the png is a ninepatch, and can
refuse to decode to 565 (if we feel this is best).
Change-Id: I724f5dbefb1be7b412f9b362dff83cbc0603f0bf
Include <uses-permission-sdk-23> permissions in dump badging and dump permissions.
This will also add implied features for that permission, marked as -sdk-23 features.
Ex:
uses-permission: name='android.permission.ACCESS_FINE_LOCATION'
uses-permission-sdk-23: name='android.permission.CAMERA'
feature-group: label=''
uses-feature: name='android.hardware.location'
uses-implied-feature: name='android.hardware.location' reason='...'
uses-feature-sdk-23: name='android.hardware.camera'
uses-implied-feature-sdk-23: name='android.hardware.camera' reason='...'
Bug:24939655
Change-Id: Ifb374696ed4760b0ba2f1cc3516f3bf08e6cb6a3
(cherry picked from commit 5f3b2ecb3e9d27e77bd59c7b9006a6239b773944)
Include <uses-permission-sdk-23> permissions in dump badging and dump permissions.
This will also add implied features for that permission, marked as -sdk-23 features.
Ex:
uses-permission: name='android.permission.ACCESS_FINE_LOCATION'
uses-permission-sdk-23: name='android.permission.CAMERA'
feature-group: label=''
uses-feature: name='android.hardware.location'
uses-implied-feature: name='android.hardware.location' reason='...'
uses-feature-sdk-23: name='android.hardware.camera'
uses-implied-feature-sdk-23: name='android.hardware.camera' reason='...'
Bug:24939655
Change-Id: Ifb374696ed4760b0ba2f1cc3516f3bf08e6cb6a3
Private resource package shouldn't be buried in some resource file.
It can now be specified on the command line via the Android.mk file.
Change-Id: I9e3cb0bf54830d6b021077af271913306c024701
AAPT will scan XML files looking for the <aapt:attr> XML tag.
<!-- @layout/bundle.xml -->
<ImageView xmlns:aapt="http://schemas.android.com/aapt">
<aapt:attr name="android:src">
<vector android:pathData="..." ...>
</vector>
</aapt:attr>
</ImageView>
The SINGLE child element of the <aapt:attr> tag is extracted into its own top
level resource. It is given a generated name.
The parent element of <aapt:attr> is then given the resource attribute that was assigned
to the `name' attribute. The value is set to a reference to the generated resource.
<!-- @layout/bundle.xml -->
<ImageView android:src="@drawable/bundle_1.xml">
</ImageView>
<!-- @layout/bundle_1.xml -->
<vector android:pathData="..." ...>
</vector>
Bug:22627686
Change-Id: I8575fc4f739011402662fbf6b3db96df0012f598
This reverts commit 9d0f7d44d5cc5322415f52f7ce03cc37a478b350.
Caused a build breakage when parsing some attributes.
Change-Id: I89ca958b2f2e820d353648df8aadd90bbe8d8339
AAPT will scan XML files looking for the <aapt:attr> XML tag.
<!-- @layout/bundle.xml -->
<ImageView xmlns:aapt="http://schemas.android.com/aapt">
<aapt:attr name="android:src">
<vector android:pathData="..." ...>
</vector>
</aapt:attr>
</ImageView>
The SINGLE child element of the <aapt:attr> tag is extracted into its own top
level resource. It is given a generated name.
The parent element of <aapt:attr> is then given the resource attribute that was assigned
to the `name' attribute. The value is set to a reference to the generated resource.
<!-- @layout/bundle.xml -->
<ImageView android:src="@drawable/bundle_1.xml">
</ImageView>
<!-- @layout/bundle_1.xml -->
<vector android:pathData="..." ...>
</vector>
Bug:22627686
Change-Id: I31bc96aae30d38bfd0b16508d0f585de5fd88a07
Use a modification timestamp of 0 for all files
inside the zip archive to make the build repeatable.
Change-Id: Ie6e57329469b99c6f93cb0a6083e0c402be99815
- Added aapt command line flag --app-as-shared-lib to build app resources
that could be loaded as shared lib at runtime.
- Added new method AssetManager.addAssetPathAsSharedLibrary() to load an
app resource as shared library.
Bug 22487604
Change-Id: Ib9b33c35f9c2b7129f3ba205de03d4564623ea39
With a set of resources with the following configurations:
()
(land)
the regression caused any resources that needed to be versioned in configuration () to be lost.
Bug:23038206
Change-Id: I2f1b0313fb780ac241e7aaa487cb37dfb79c36aa
Resource generation was greedy, so when an attribute with sdk level 21 was used in a resource
with v1, and a different attribute with sdk level 21 was used in a resource with v11,
a v21 resource would be synthesized, but it would contain the attribute from v1 instead of v11.
This change fixes the issue, having the higher versioned resource take precedence.
Bug:22793816
Change-Id: Ia687f56b0d9969e424111477d55d9804255b22e9
