Remove option to force UTF-8 encoding which could corrupt packages meant
for systems before API level 7. Added switch to allow encoding for UTF-16
which will allow API 7 and later to encode resources in UTF-16.
Change-Id: I70d0bddb0dfd12dcbd08c95f613dcfe896ae680b
Allows the use of UTF-8 for packing resources instead of the
default of UTF-16 for Java. When strings are extracted from the
ResStringPool, they are converted to UTF-16 and the result is
cached for subsequent calls.
When using aapt to package, add in the "-8" switch to pack the
resources using UTF-8. This will result in the value, key, and
type strings as well as the compiled XML string values taking
significantly less space in the final application package in
most scenarios.
Change-Id: I129483f8b3d3b1c5869dced05cb525e494a6c83a
This is needed to add library support to the SDK.
The goal is to have libraries and main project use the same
package for the R/Manifest classes to that they can share code
and resources.
BUG 2293994
Change-Id: Ie4cdb5a3bdabe1760a91316fd8969e4f53344bf9
Adds a "junk path" option to aapt so that you can do:
aapt add -k archive.zip path/to/some.file
and have the file stored in the zip under the name "some.file"
(without the path). Needed so that we can use 'aapt add' in place of
'zip -j' when building jar files, which will lead to smaller
incremental OTAs.
(This is a cherry-pick of a change already submitted to eclair-mr2;
the change was approved for mr1.)
Adds a "junk path" option to aapt so that you can do:
aapt add -k archive.zip path/to/some.file
and have the file stored in the zip under the name "some.file"
(without the path). Needed so that we can use 'aapt add' in place of
'zip -j' when building jar files, which will lead to smaller
incremental OTAs.
Merge commit '1585bd24c10d16351f89e32dddbfa799f18db6bd'
* commit '1585bd24c10d16351f89e32dddbfa799f18db6bd':
Report densities in badging, debugging for nine patch bug.
The aapt tool now reports all available densities like it already did
for locales. Also this includes more resource data output, which I
was using to examine bug #1867049 (which at this point I am unable to
reproduce).
Now old applications will automatically be granted it. Also renamed it from
SDCARD_WRITE to WRITE_SDCARD to be consistent with our other permissions,
and re-arranged how we do targetSdkVersion to actually be usuable for this
kind of stuff.
Note that right now this results in basically all apps being given the
WRITE_SDCARD permission, because their targetSdkVersion is not set. I will
be dealing with that in a future change.
Now old applications will automatically be granted it. Also renamed it from
SDCARD_WRITE to WRITE_SDCARD to be consistent with our other permissions,
and re-arranged how we do targetSdkVersion to actually be usuable for this
kind of stuff.
Note that right now this results in basically all apps being given the
WRITE_SDCARD permission, because their targetSdkVersion is not set. I will
be dealing with that in a future change.
