Files under /bin and all directories in an APEX now have x (executable)
bit set correctly.
Bug: 117580281
Test: m apex.test, push it to /data/apex and reboot.
adb shell ls -al /apex/com.android.example.apex@1 shows that the
directories have x bit set
Change-Id: I76e4188d86dc9cdf65e9f8e52be1981e25441a6e
Don't directly iterate over the copyManifest map to generate the copy
commands. Iterating over a map in golang isn't guaranteed to give
consistent order. This causes the apex build rules to be executed even
when there is no source file change.
Fix the issue by creating a sorted list of the key and then iterate over
the list.
Bug: 117453592
Test: m apex.test; m.apex.test nothing is built during the second
build
Change-Id: I329a91ec0b6a34cbe745bf9a9ceb0843b63c200c
Now, APEX-aware modules (the ones implementing android.ApexModule
interface) are created with multiple variants for each APEX that they
are included.
For example, if a module is included (either directly or indirectly -
via static linking) to two APEXs, the module is built separately for the
two APEXs (and of course separately for platform). This is a first step
to limit the symbol visibility to the modules built for APEXs; platform
private symbols and libs shouldn't be allowed for them.
In addition, the build system now tracks transitive dependencies of
the modules in APEXs. For example, if
native_shared_lib_modules:["libFoo"] then libFoo and its dependencies
are all automatically included to the APEX.
Bug: 112672359
Test: m apex.test; the built apex has additional libs (such as liblog,
libc++, ...) that are dependencies of the ones specified in Android.bp
Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
