It turns out that the way I use Python to create ZIP
archives is plain wrong. Some files simply don't have the
right size and we get EOFException when unzipping with
Java's ZipFile.
This change adds a flag to instead simply copy all the
files we want and then run the 'zip' system command.
The python zip facility is left there intact in case
I want to go back and fix it later (I'm going to assume
it's my usage that's wrong before really blaming python).
Change-Id: Iea178a49be0bf23c91c01a2e036ae7a76def2b55
Also fix packaging of system image (it had an extra root
directory in it, e.g. it was packaging android-4/armeabi-v7a/
instead of just armeabu-v7a/)
Change-Id: I0254b2680168d25103222f8871b2af37a7406b58
Also:
- in the images_*_source.props, we can't have the platform
version name (the human readable string). It's not a valid
property of the XML.
- disable the included-abi in the platform.
Change-Id: I3db62fde5e436bbe8f8e69eb1495ca4e6b954ba2
When the "sdk_repo" modified is used during the SDK build,
this also generates the repository.xml and addon.xml files
for the new SDK repository packages and places them in
the DIST_DIR.
Example usage:
make -j 16 PRODUCT-sdk-sdk showcommands sdk_repo dist DIST_DIR=/dist/sdk
make -j 16 PRODUCT-google_sdk-sdk_addon showcommands sdk_repo dist DIST_DIR=/dist/addon
Change-Id: Ibaad66f4b1cc476a4146afde7087a10a0557f74c
When the build is invoked with the fake target "sdk_repo" and
a main target of sdk, win_sdk or sdk_addon, we now create
packages in DIST_DIR that can directly be used to populate the
SDK Repository.
This is quite close to how we actually distribute the SDK.
Change-Id: I01c729eff4dbc1eccbc7c5b1869f329363f1ce07
