am: bc60af7bfd
* commit 'bc60af7bfd4e7190086d59eea53b3dcf3cf40a6d':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: I4ce025692a6e6c0c96d5657d99131c306a742da4
am: 9ae8c7356e
* commit '9ae8c7356efd1eadb9e4043d96cc5dc28ba554b6':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: I67fe439474ce9edd47194a926719b71b846a2a56
am: 8ebaeae1f6 -s ours
* commit '8ebaeae1f6f0a69fc1bf518558fa463ed0cca6de':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: I07650552a45e5e2de1524b43839c895283d17c4a
am: 3cba9b15f7
* commit '3cba9b15f7ce25e194a305d37d27424e6923fd4b':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: Ib7e12ebb1a9140084a1e3aa28cede2809499004e
am: 8b961c808b
* commit '8b961c808b6c67d464f4c070ea46b8a0650595d5':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: Id5916f2fa84a2fee99a37a1a8b9fd07d8c58ae0b
am: e495d379de -s ours
* commit 'e495d379decdfea93789c4693dd0f96aac23c34d':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: I1749805100b45f8f12cac476df8e7be3380fbd54
am: 2ee84bf0a5 -s ours
* commit '2ee84bf0a56984323154411d60096b691c66b841':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: I7a2c2f1d707eb14b56b8e5227724427bdf0e2768
am: 0bdac8fba3
* commit '0bdac8fba335f4e1620871bf5082dbebc55a497d':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: I9c2b97af248ab4007fbfce8d67f9f70b5016687f
am: 89f6f7aa01
* commit '89f6f7aa01591e8524ef0c4b5efa7433d082a9b9':
DO NOT MERGE Updating security string to 2016-07-01 - for klp-dev only
Change-Id: I0e07966827713405ac2145a44185fe2f485c6e62
Data of uncompressed APK entries is often aligned to a multiple of 4
or 4096 in the APK to make it easier to mmap the data. Unfortunately,
the current method for achieving alignment suffers from two issues:
(1) the way it uses the Local File Header extra field is not compliant
with ZIP format (for example, this prevents older versions of Python's
zipfile from reading APKs: https://bugs.python.org/issue14315), and
(2) it does not store information about the alignment multiple in the
APK, making it harder/impossible to preserve the intended alignment
when rearranging entries in the APK.
This change solves these issues by switching to a different method for
aligning data of uncompressed APK entries. Same as before, alignment
is achieved using Local File Header entry field. What's different is
that alignment is achieved by placing a well-formed extensible data
field/block into the extra field. The new field/block contains the
alignment multiple (e.g., 4 or 4096) as well as the necessary padding
(if any). Compared to the original alignment method, the new method
uses 6 more bytes for each uncompressed entry.
Bug: 27461702
Change-Id: I8cffbecc50bf634b28fca5bc39eb23f671961cf9
am: 57c3aea442
* commit '57c3aea442bff67e4452eee7ff8f13294fbad34b':
Build: Only use compiled-classes file when available
Change-Id: I9a3ae7385483f9f5d934d8cd6660c17c57529989
am: 315621eee0
* commit '315621eee0a1199b175ab4d251ea617fdb018fd5':
Move to a single clang unknown flags list
Change-Id: I209bf8b868da7b11d55fc6cf701976ff914a2160
am: 06935290ac
* commit '06935290ac12d03a5a4f287f4743ada996305235':
Move to a single clang unknown flags list
Change-Id: Ia02030229a089e531c7258780fb7837240e2b47f
Soong is using a single list of unknown clang flags for all
architectures, instead of the per-architecture list here. Collapse this
down to a single list as well so that it can be verified against the
Soong list, and eventually replaced by the Soong version.
Change-Id: If43cd892105da5155907c05965a74b835920a369
Zach Jang