Instead of using the DEFAULT_APP_TARGET_SDK, which is the hardcoded in
the build system, ie the sdk version of the current source tree.
Change-Id: I2fae3521300cc6b2449df3659ded7f7a397609c0
With this change, PRODUCT_LOCALES will contain only locales.
Other aapt config flags, such as *dpi, small/normal/large/xlarge,
should go to PRODUCT_AAPT_CONFIGS.
Bug: 4086309
Change-Id: I922f153d79777a9522c542a3907111193b40e7b7
Head was causing a SIGPIPE in grep that only appeared when using
distss. This wasn't causing any build problems but spewed a lot
of warnings.
However, this change trims the command from 5 proccesses to 1 which is
nice.
Change-Id: Iac846ec1d01a022976cfc5fd28091a720ab161e7
Merge commit '606540b739599c8f079baa2a03b5f0501b148eb2'
* commit '606540b739599c8f079baa2a03b5f0501b148eb2':
Packages can specify where to find AndroidManifest.xml
By overriding LOCAL_MANIFEST_FILE, a package can now specify which
AndroidManifest.xml file to use. This also allows for AndroidManifest.xml to
be in a non-standard location, though that's not recommended.
Change-Id: Ib6d1baeef7601e5a93d4ce64d18883d45373fc12
With this change, you can add your .rs files to LOCAL_SRC_FILES.
The .rs files will be compiled by slang and the output .java files
will be compiled into the jar, while the generated .bc files will
be put into the final apk as raw resources.
Change-Id: Icde3d6139951d6d039b4b37376e72e1fc5c8b0d4
LOCAL_JNI_SHARED_LIBRARIES_ABI allows individual APKs to specify
specify the path where JNI shared libraries are stored in the APK. This
is useful if you want to build an APK that supports a generic version of
an ABI (e.g. armeabi) from a device configuration where
TARGET_CPU_ABI is set to a more specific version of an ABI (e.g.
armeabi-v7a.)
Note that specifying the LOCAL_JNI_SHARED_LIBRARIES_ABI does not
affect how the local JNI shared libraries are built. It just controls
where the local JNI shared libraries are placed within the APK.
Defaults to TARGET_CPU_ABI.
Change-Id: I1cbb293e0c953688945fc147c7fc367421cf860b
This lets you use the source code from one apk to build a new one
with a new module name, a new android package name and optionally,
a new certificate.
To use this, in a makefile, add this:
$(call inherit-package, \
packages/apps/Music/Android.mk, \
Music, \
MusicFork, \
my_cert, \
com.example.music)
You don't need the LOCAL_PATH and CLEAR_VARS stuff. It will override
only the packages that are defined in the makefile name you give, but
if other modules of other types are defined, you will get an error
saying that it's defined twice. In that case, you need to move the
duplicate library (for example a .so) out into a different makefile.
A LOCAL_OVERRIDES_PACKAGES entry is automatically created for the
forked app.
Before, LOCAL_RESOURCE_DIR got messed up when the build system
tried to find the whole LOCAL_RESOURCE_DIR string in each
overlay directory.
This change splits LOCAL_RESOURCE_DIR before appending it to
the overlay directory paths.
I've verified that this now works:
LOCAL_RESOURCE_DIR := $(LOCAL_PATH)/overlay $(LOCAL_PATH)/res
Change-Id: Iea47f94a14720af0ca4b422aec30acf4acbe13cf
Setting LOCAL_CERTIFICATE to "EXTERNAL" now marks an apk (either a
prebuilt or otherwise) as needing the default test key within the
system, but one that should be signed after the target_files is
produced but before sign_target_files_apks does the rest of the
signing. (We use this to ship apps on the system that are signed by
third parties, like Facebook.)
1. Dedup LOCAL_JAVA_LIBRARIES.
2. Even no resource or asset for a package, we still need to set
package_expected_intermediates_COMMON, which is anyway used by ProGuard.
Ying Wang