To consolidate the number of places that we're using 'find' in the tree,
add some more helpers:
all-named-dirs-under
all-subdir-named-dirs
all-named-files-under
all-subdir-named-files
This change also makes many of the current helpers use these helpers
instead of using their own implementation.
The 'dirs' helpers are using '-type d' so that they only output
directories. It's probably safe to use '-type f' for the files helpers,
but that increased the kati load time by ~20%.
Bug: 24204119
Change-Id: I3312e2fe8c146f10955e1d986ad15d9c8be494e1
There are multiple versions of this in the tree. Let's standardize on
one that will work for everyone, and will sort the results.
Bug: 24204119
Change-Id: I09fcd80e1e8e35e64d8a8a62bbc096f87b02603f
Don't uncompress/page-align the jni libraries in apps_only build,
because the apk may be run on older platforms that don't support loading
jni directly from apk.
When prebuilt apks are installed to platform build, the build system
will automatically uncompress/page-align the prebuit apks in M and
downstream, so no need to uncompress/page-align in the apps_only build
either.
Bug: 22491084
Change-Id: I67e977b2592800ae467450592069843b4e5fc466
Prevents aapt from generating java symbols for strings that don't have
a default localization.
Bug: 21537397
Change-Id: I2f17397e33d823045f7dcff02e3d0817f3f81849
These directories are excluded in addition to OUT_DIR.
This can be useful if your build system has other output directories
beyond what OUT_DIR is set to.
Change-Id: I6d98a85bcc8c89279e939406a7fec32547e8922f
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Ic3666dc72bf17cd293787414dd185470b365f967
Normally the binaries use the exsiting $ORIGIN/../lib[64] with binaries
in the bin subdirectory;
For historical reason the binaries in the SDK package don't have a bin
subdirectory. This workaround enables them to work in the exsiting SDK
directory structure.
Bug: 21301578
Change-Id: Ibebfbfb8b30e81e7bbaf13a21bb205f3f0282d24
- Detect java-source-list before transforming to java-source-list-uniq.
This fixes non-fatal errors in build log like:
/bin/bash:
out/target/common/obj/APPS/android.core.tests.libcore.package.tzdata_intermediates/classes/java-source-list:
No such file or directory
- Cleaned the outdated incrementaljavac. Nobody is using this feature
and now we switched to jack.
Change-Id: If1adb9b5820d9b295a11984c0f170f9a7ff4de7b
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Icf07e0998ac3602e6e05e80fed836fbafca33e01
Add replocation-packer step for dynmic executables.
Enable it by default for arm and arm64 platforms.
Bug: http://b/18051137
Change-Id: I0c88fd31595bcea62a087f219acb9ecf9c80f2e5
If a prebuilt APK contains shared libraries and the flag
LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES := true is set, then
uncompress any shared libraries stored within the APK.
This allows processes to load the shared library directly from
the APK.
Bug: 20247329
Bug: 8076853
Bug: 1162500
Change-Id: Iac4db32457d9ce31eb7256410023819b44fda0a6
With this, you can easily add more executables, jars or shared libraries
to the package. Also now it automatically takes care of
32-bit-v.s.-64-bit library issue.
Change-Id: I5afe00fadc978d0da229b192eca1a4b1c149764e
Strip prebuilt shared library but not try adding gnu debuglink.
It would fail if you try run the adding gnu debuglink command if a
prebuilt is already stripped.
Bug: 17177288
Change-Id: If5811865715c2437e45fbd329983ef1212ef0109
(cherry picked from commit bfb52a2ec1)
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
Set LOCAL_PROTO_OPTIMIZE_TYPE=nanopb-c which doesn't support
malloc and set it to nanopb-c-enable_malloc which does.
For client code details see nanopb-api:
http://koti.kapsi.fi/jpa/nanopb/docs/reference.html
Change-Id: If238412463aabb5e1d556dfc9c464bcaf9e3333a
