The build was working on AOSP, but fails downstream when using
Jack because the javalib.jar file needed by CTS is not being
built by default there.
Change-Id: I8dd836b33a4e1bae5af623db3822de99e9b05cf0
Add vboot properties to the dictionary file, which will be packed into
the target_files zip. Add support in packaging and OTA scripts to
sign the generated bootable images (boot.img and recovery.img) when
vboot is enabled.
Change-Id: I08758ced03d173219415bca762bbdb66c464a9f5
(cherry picked from commit 5d5a3bd9e8d8b14b71d1b2105417a2958d13d3d2)
Previously we were bundling this into libc++ and having each binary
resolve its symbols from there. This means that the unwinder that gets
used for a given binary is sensitive to the order in which its
libraries are linked. Making this a static library dependency of each
binary means the right unwinder will always be used.
Bug: 18471342
Bug: 19958712
Change-Id: I782d212784dbf85355b5d9146d7460d675259a0e
With commit 33360dd569 we moved Java
resource packaging forward to creation of the jar file. But the Java
resource packaging will be skipped if a module has no Java code at all.
(The build system does support building an apk without Java code.)
In this change we add back the Java resources directly to the built apk
when the apk has no Java code.
(cherry-picked from commit 8b27d1879c)
Bug: 19947218
Change-Id: I0e1a65a9cbe656974f8ef3923b2f15e9efa5feb9
Added support to build system.img that combines contents of /system and
the ramdisk, and can be mounted at the root of the file system.
To enable this feature, define BoardConfig.mk variable:
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
Ideally we would just change TARGET_OUT (the path of the staging system
directory) to under TARGET_ROOT_OUT. But at this point many places in
the build system assume TARGET_OUT is independent of TARGET_ROOT_OUT and
we can't make it easily configurable.
Instead this implementation takes the least intrusive approach:
We don't change TARGET_OUT or TARGET_ROOT_OUT. We just assemble a
temporary staging directory that contains contents of both TARGET_OUT
and TARGET_ROOT_OUT, in build_image.BuildImage() of
tools/releasetools/build_image.py.
When build_image.py is directly called from the makefile, we pass in the
parameters from the global dictionary; when build_image.BuildImage() is
called from add_img_to_target_files.py, we need to override values to
point to files extracted from the target_files zip file.
We need to combine the fs_config files of both /system and ramdisk,
when fs_config is enabled.
Also this change refactored build_image.BuildImage() by moving the extra
parameters to the image property dictionary.
(cherry-picked from commit 0eabd4f2c5)
Bug:19868522
Change-Id: Iafc467a0e3427b0d6ad3b575abcc98ddcc9ea0f1
Fix the bug that build is still success when boot jars contain
non-whitelisted classes. Now, check-boot-jars.py correctly
finishes with exit code 1 when non-whitelisted classes are found.
Change-Id: Id5c80ef9fdb70213d878d569f6033be2c9eb90d3
-Wl,--fix-cortex-a8 is a workaround for an Erratum in Cortex-A8
processors. It slightly increases code size and decreases performance,
and there's no point in using it on non-A8 CPUs.
Instead of forcing it unconditionally, use it when targeting
Cortex-A8 or generic armv7-a (which might or might not be A8).
Change-Id: Ifa59765d380445237edccfe5440a67b3ba1e459a
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Clang 3.6 (including the snapshot present in AOSP) added support for
-mcpu=cortex-a15 -- there's no need to fall back to generic armv7-a
anymore.
Change-Id: I8a582261ac35e32f8f1def1d244cf83f2096520d
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
The change follows the patten found in "Package OTA" and other places
to allow for overriding the mkbootimg command.
Now pass MKBOOTIMG variable to get make_recovery_patch and add_image_to_target
to use the tool set in BOARD_CUSTOM_MKBOOTIMG for boot/recovery image
generation.
Change-Id: I78533c25e87c2750eb24ac1bf39e4b7ca321a441
Clang's tail call optimization for position independent code
only works when the callee was called (bound in GOT) before
the jump through GOT.
It does not work for some lazy bound Android tail callee.
We used special flag to disable all tail call optimization.
This change removes that global flag and depends on
clang compiler fix from upstream or the temporary patch in
https://android-review.googlesource.com/#/c/142241
See proposed llvm changes and pointers to llvm bugs in
https://android-review.googlesource.com/#/c/142792
Change-Id: Idb6e98d6b5f0e4c3676884b69eb3e767eba2491a
Can't be done on the user's end because these libraries all need to be
linked after libc++_static.
Change-Id: Ib21364e6f43689cf59da31d6f561919731ef8272
Previously odex files were stored alongside the dex location as:
dex location: /foo/bar/base.apk
odex location: /foo/bar/<isa>/base.odex
This changes where odex files are stored, adding an "oat" directory:
dex location: /foo/bar/base.apk
odex location: /foo/bar/oat/<isa>/base.odex
See also the corresponding change in platform/art and
platform/frameworks/native.
Bug: 19550105
Change-Id: I4c6be4f0c41ff175904846db8e360c4af815b265
So that the cts config.mk can use global variables set by the core build
system config.mk.
Change-Id: I2571564abbb53257eee54485a3357ab1305eb870
(cherry picked from commit bacf5f8008)
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)
"LOCAL_FDO_SUPPORT := always" enables FDO without user specifying
"BUILD_FDO_OPTIMIZE := true", i.e. it turns on FDO for a
module in any build configuration.
Change-Id: I05d8db2edb2b3f5db073fa14d5bf1083a04571c0
(cherry picked from commit 45d0143ab1)
Some releasetools python sripts rely on $PATH to search for the
executables. With this change, you don't need to run lunch even after you
change the build system variable OUT_DIR.
Bug: 19320328
Change-Id: Ia44b11084fb1bdcceb60b1d33cb7e460c9b705a8
(cherry picked from commit 9d252e1009)
Add a target to zip up all the otatools and releasetools, for easy
copying to the OTA builder machine.
Change-Id: If14b4afefcc1a20ea19dfca3f3b9f9fae73189a6
(cherry picked from commit f22b0f43ef)
v8.renderscript is needed, even for bundled apps.
Bug: 19343399
Change-Id: I461e244be15e08d4525439bc042529314c84031e
(cherry picked from commit c919b0ba88)
"cp -Rf" fails on Mac OS when some broken symlinks exist in the dest
dir.
Also switch to better shell error handling when copying
init.recovery.*.rc.
Change-Id: Idd05f7604736b234619f62be12dd108fac91fed1
Previously the recovery binary was configured to be installed to the
system.img and then got copied to recovery.img in the recovery.img's
build rule.
With this change, a module, such as the recovery binary, can configure
itself to be installed directly to the recovery.img, just like how other
modules get installed to system.img.
Bug: 19667686
Change-Id: I46b0b4a95cf078a68999db9c0f6635d6a3f5cd86
Add source and target block hashes as parameters to transfer list
commands that copy or patch data to a partition. This allows the
updater to verify the status of each command in the transfer list
and makes resuming block based OTAs possible. Due to the changes,
update the transfer list version to 3.
Needs matching changes from
I1e752464134aeb2d396946348e6041acabe13942
Bug: 18262110
Change-Id: Ia5c56379f570047f10f0aa7373a1025439495c98
(cherry picked from commit cac671a9d1)
Previously when a file in LOCAL_SRC_FILES starts with "../", the object
file may escape out of the module's intermediate directory, because we
insert the source file's path (but not with LOCAL_PATH) to the object
file's path. Even worse when two object files escape to the same destination
and cause conflict.
This change fixes the issue by removing the "../" inside the object
files' paths. To do that, we have to set up the compilation rules for
those files one by one, instead of using the one-for-all static
pattern rules.
Bug: 19641115
Change-Id: I19f3c48ece3244fa14acb2caa609deea710840d3
By default we build both 64-bit and 32-bit odex files for a Java library.
With this change:
- For system server jars (PRODUCT_SYSTEM_SERVER_JARS), we build only
64-bit odex;
- A library can opt to build only 64-bit odex with
"LOCAL_MULTILIB := first".
Bug: 19650934
Change-Id: Ic0b7fd381396ed276e6129f883881c5c41c6e154
On non-arm architectures, there is no TARGET_CPU_VARIANT set. For x86,
art assumes that the CPU variant is actually the TARGET_ARCH_VARIANT.
Therefore, if no TARGET_CPU_VARIANT is set, use the TARGET_ARCH_VARIANT.
If TARGET_ARCH_VARIANT is not set, then use default as the value.
Change-Id: I17fc9e3ac7412462103b8f0b287fce106298b741
Expectation is that classes in pre-compiled apps should be structurally
sound and not cause a hard failure.
Bug: 19606409
Change-Id: Idc9da4d4c6bd259555671c657d3414a97940717f
We should put the NDK library path before
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), so that we link against the NDK
libc/libm, instead of the platform libc/libm in
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), which may still being written out,
because we don't have dependency on them.
Bug: 19613709
Change-Id: I26a8b272e38b7436bca3324246b21cd71349662b
The Mac linker doesn't understand --start-group, which is needed for
properly linking libgcc/libc statically. It isn't needed for dynamic
executables though, so use that driver behavior where appropriate.
Bug: 19567451
Change-Id: Ifeb03bea55bc87561c64ddafdb99f664fef0f00e
BUILD_HOST_static=1 forces all host binaries to be statically linked.
Since -nodefaultlibs was passed (to disable libstdc++), libgcc wasn't
being passed. This change emulates the driver's behavior.
Also fix default STL selection for BUILD_HOST_static.
Bug: 19567451
Change-Id: I617aab782d40ac76ca5a7d9dddf0f202a4e3a69b
http://llvm.org/bugs/show_bug.cgi?id=15086,
llvm tail call optimization is wrong for x86.
For Android/x86 to use SSE* instructions safely, stack should be 16-byte
aligned before JNI function call, which isn't true for all x86 device,
so -mstackrealign should be the default.
BUG: 19234330
Change-Id: I4c6676366788772dbe64fd7f0dd33b3ed5c9b80e
Previously if user has a directory with name dummy in the root of the
source tree, "zip -qd package.apk dummy" fails with:
"zip error: Nothing to do!".
This change mitigates the error.
Change-Id: I642e3bf0378e5b9911a068ecb72f795b3e92f1fe
- Add a new flag to zipalign (-p) that page aligns shared
libraries (zip entries ending with ".so") in the archive.
- Add a new build variable LOCAL_PAGE_ALIGN_SHARED_LIBRARIES
to turn on this behaviour in zipalign.
- Add a new LOCAL_JNI_SHARED_LIBRARIES_ZIP_OPTIONS to control
zip behaviour.
Bug: 8076853
Bug: 19330157
Co-Authored-By: Simon Baldwin <simonb@google.com>
Co-Authored-By: Dimitry Ivanov <dimitry@google.com>
Change-Id: I1aa2c039bb2a590ae72f256acc9ba5401c2c59b1
These CFLAGS and CPPFLAGS will always be added last, and are
controlled by the build system. This way we can add warnings that
users are not allowed to disable.
Change-Id: Id71f69249078f62ca2687ecbf764aff0fd3a1c1b
Implicit function declarations are much more dangerous on LP64 because
sizeof(int) != sizeof(void*), so any function that returns a pointer will
lose its top bits, leading to relatively hard to debug crashes.
Change-Id: Ia05beffb949ca747833c2e12c40daf896f7a60a5
Implicit function declarations are much more dangerous on LP64 because
sizeof(int) != sizeof(void*), so any function that returns a pointer will
lose its top bits, leading to relatively hard to debug crashes.
Change-Id: Ib2570326dde1b1cde09c63c9b4c973d741528ee2
We don't support platform builds under CYGWIN and can safely
assume that all windows host builds are for MinGW32.
HAVE_WINSOCK2_H is currently unused. The only references to it
are in code that define it themselves or in application code that
by definition isn't compiled for windows.
Change-Id: I236d6e070df93f713cb716bb8a461c9c1d32a180
With the long PLATFORM_VERSION, if you have also a long device/product
name and/or a long username, ro.build.fingerprint can easily exceed the
system property's length limit of 92 bytes.
This mitigates the risk a little bit.
Bug: 15593959
Change-Id: I9e316025227b30aa6887c9ce0065364fdbb9fc8f
Package up LOCAL_PREBUILT_JNI_LIBS when you do tapas (apps_only) build.
Change-Id: Ibdc920fee22d4940eebee080a940e8e9492c06cb
(cherry picked from commit e66d7c1de0)
We don't use EXT2 for bootimage anymore.
This will allow getting rid of external/genext2fs
Bug: 19282953
Change-Id: Ie56528c7877036d2501a09888a4420637f9cd647
When incremental builds only affect the system partition,
the build.prop file for other partitions might go out of
date.
Add a dependency on system/build.prop s.t. when
it's rebuilt,
the fingerprints are updated on the other
partition's build.prop's.
Bug:19058575
Change-Id: Iea7b761e0800c402eb4ce1154e8f6af5a17f7b06
The transitive symbol resolving causes build breakage when a binary
linked against NDK has indirect dependency on platform libraries, or
vice versa.
Change-Id: Idbfe76079c1db14eb1156d0f396e13d26f0ff582
With this support, you can set dpi-specific aapt flags like:
$(LOCAL_PACKAGE_NAME)_aapt_flags_hdpi := --version-code 100 \
--version-name "100
which will override the --version-code and --version-name set in the
base apk's LOCAL_AAPT_FLAGS.
Bug := 18388705
Change-Id: Ie79d7b1b6bbf7463bce51ddae04ba81384ec58dc
With this support, you can set dpi-specific aapt flags like:
$(LOCAL_PACKAGE_NAME)_aapt_flags_hdpi := --version-code 100 \
--version-name "100
which will override the --version-code and --version-name set in the
base apk's LOCAL_AAPT_FLAGS.
Bug := 18388705
Change-Id: Ie79d7b1b6bbf7463bce51ddae04ba81384ec58dc
Normally the build function initialize-package-file will delete all
class files and all directory entries from JAR files, but sometimes
external projects (eg. ICU4J) depend on having directory entries in
their JAR files.
This change adds the flag LOCAL_DONT_DELETE_JAR_DIRS (analogous to the
flag LOCAL_DONT_DELETE_JAR_META_INF) which when set will skip deletion
of directory entries in initialize-package-file.
Change-Id: I4464b947b7528fca23925affa95e4071915f04d4
It's pain to maintain an inactive product's list of
PRODUCT_FACTORY_RAMDISK_MODULES or PRODUCT_FACTORY_BUNDLE_MODULES.
Just show a warning if a module name becomes dangling.
Bug: 18779515
Change-Id: I3d137ed59feb005b186ed2a3519465da3d8f45c3
Note that this doesn't play nicely with acov out of the box. Clang
apparently generates .gcno files that aren't compatible with gcov-4.8.
This can be solved by installing gcc-4.6 and invoking lcov with
`--gcov-tool /usr/bin/gcov-4.6`.
http://stackoverflow.com/questions/17758126/clang-code-coverage-invalid-output
Change-Id: I79547e1c579fa79db47ff07d5e90c42cedbd5cbb
Don't remember why I didn't enable this for the host when I made the
first pass, but it works just fine.
Change-Id: I0892c0bc353bf8b60b432ba9f69f97281177d41d
Clang driver needs -static flag, not -Bstatic,
to produce statically linked modules.
However, -static is not added if LDFLAGS contains -shared,
which is used in bionic/linker to create a shared object with static libraries.
BUG: 18008984
Change-Id: I75c3e24973ee77170285ec4c8e7aacc345722685
So the build system regenerates import_includes when you modify
Android.mk to add a new dependency library.
Change-Id: Ic92b097b659bb68a9065e1d66da59e0dc7e2836a
Before this change, Java resources are added as a separate step
(add-java-resources-to-package) after dex is run, so jarjar isn't run on
the resource files.
With this change, we add Java resources immediately after we call javac,
so jarjar is run on the resource files (the module's own resource, as
well as resources carried by static Java libraries).
When we generate the final apk/jar, we use the jarjar'ed jar as the
inital pacakge file, with class files and empty folders removed.
(cherry-picked from commit 140274707e)
Bug: 18837479
Change-Id: I15ecf282bfb65fd53dd03fbd03dd4c71927c186a
This is a BCP-47 language tag representing the default locale for a
given device. Support for the earlier mechanism of supplying a language
and region via ro.product.locale.region/language has been removed. This
change also removes support for supplying these properties via
PRODUCT_ADDITIONAL_PROPERTY_OVERRIDES. Devices that need to override
this should either rearrange their PRODUCT_LANGUAGES or supply a custom
.prop file.
bug: 17691569
Change-Id: I00c74098542b49b9c514a6ca39ea8d08179546c1
We want to store the symbol information for all android binaries in a global database.
* We ingest unstripped binaries into the global database
* When we collect address data from device (e.g. instruction pointer address), we want to lookup its symbol information through the global database. The key of the mapping is a unique build id, which is the same between binaries on device (stripped) and unstripped binaries.
After applying this patch, the system.img size increases by 0.0047% (16.3KB).
Change-Id: Id92faf2951f43a30947e8d2b690c1af6bf7e3f54
The proto handling will modify the set of dependent libraries, but
this was not actually accounted for in dependency handling because
dependencies had already been established.
Change-Id: Iba1582f3c9eeeada19569e4b5358b6ec4168fccc
If LOCAL_WHOLE_STATIC_LIBRARIES contains a library that has
two files that have the same name but are in different
directories, only the first gets included.
This fix detects this case, and uses the m option to ar to force the
duplicate object to the end of the archive. After this, using the p
option gets the correct object file.
Change-Id: I2e183f48cef3c79499d4ab8ff147444611ff938b
In anceint time we didn't have an "sdk" product so that we had to run
"make sdk" in a device product configuration.
Now we have SDK specific product configuration and we don't do "make
sdk" in device product configuration.
Change-Id: I40d58d51261498017bbe7e574c8128afc77e9b96
The transitive symbol resolving causes build breakage when a binary
has indirect dependency on the NDK library.
We only observed such behaviour in the aarch64 toolchain.
Change-Id: I29e01f16bdfa3aa206cd42d6f07c764fd436873a
In commit e9dd9f2bf we moved "include $(BUILD_SYSTEM)/android_manifest.mk"
forward before the variable intermediates.COMMON gets defined. That's a
mistake.
This change replaced the tentative variables
package_expected_intermediates_COMMON and guessed_intermediates with
their proper counterparts defined in base_rules.mk.
If their values differ in the two file, that's an error and we should
fix.
Bug: 18168693
Change-Id: I2bf17b0476b4a7f97810fbb0bde7630eb8878b53
- You can give a .aar as source file to a prebuilt static Java library
module. The build system will set up dependencies and rules to extract
classes.jar and other resource files.
- To build against a prebuilt AAR module, use:
LOCAL_STATIC_JAVA_AAR_LIBRARIES := <module names of aar prebuilt AARs>
The build system will set up rules to merge the library's
AndroidManifest.xml with the main AndroidManifest.xml, add the AAR's
resource dirs and link/merge the AAR's classes.jar.
Bug: 18168693
Change-Id: Ic2c1d20572a93bd98dbc72f8a39e26b459e442c2
(cherry picked from commit e9dd9f2bfc)
Now libart is the only supported runtime and
we don't need the build variables PRODUCT_RUNTIMES and
DALVIK_VM_LIB.
Bug: 18465297
Change-Id: Ibfda931cde0649163d79b584fb5ccad927a9bc2b
We use search LOCAL_DPI_VARIANTS in the list of
"$(PRODUCT_AAPT_PREF_CONFIG) $(PRODUCT_AAPT_PREBUILT_DPI)"
and the first takes precedence.
That way if we don't have a best match, we fall back to the second best,
the way how it worked with PRODUCT_AAPT_CONFIG previously.
Bug: 18388705
Change-Id: I8bd646c52215c65cc6e38c728857af9b64d13469
We had discussed the idea of making all host tools default to using
ASAN. Even if we don't make it the default, this makes it easy for the
user to switch all host binaries over.
Change-Id: I64a5c741b1b4e9aefed3a6be8dcd4f386e06b29c
Pass -fsanitize=address instead of manually specifying asan libraries
and other linker flags.
Note that we enable LOCAL_ALLOW_UNDEFINED_SYMBOLS by default for host
builds because ASAN only links symbols in the final executable, so
there will _always_ be undefined symbols in intermediate libraries.
Bug: 18208352
Change-Id: Ief55ab296e94974560eeb10507ec8d90f0025d5c
ro.build.flavor is set to "$(TARGET_PRODUCT)-$(TARGET_BUILD_VARIANT)" in
system.img build.prop at build time,
and it won't be overridden by oem partition's build.prop.
Bug: 18605832
Change-Id: Ic917623dd43b74d9c601119db0b457483e8c4472
This change also defaults C compilations with clang to gnu99, and turns off
the -Winconsistent-missing-override flag, since we need further cleanup to
turn it on. -finline-functions is an unnecessary flag that only gcc needs.
Change-Id: I1cfcaedca32d9e3c248a6aa9460603205901c491
Otherwise wrong set of memory/string functions is chosen when building atom
image (in Bionic we have libc/arch-x86/atom/atom.mk). Plus this naming is
consistent with other x86 architectures.
Change-Id: I21e899534e7ce10530474a22ceba770422b39d8d
Signed-off-by: Alexander Ivchenko <alexander.ivchenko@intel.com>
Bug: 18589470
__LP64__ is only defined for 64-bit compilation targets, so this macro
is evaluated as an implicit 0 in the original case. This change makes
it explicit that we only care whether this is actually defined.
Change-Id: I8c11b41fc0bde9477c5efeea0782d9741d9d827d
In unbundled apps_only build, in addition to the base apk, you can also
build the dpi-specific apk variants, with:
LOCAL_DPI_VARIANTS := <a list of dpi names>
Previously user needs to include $(BUILD_PACKAGE) repeatedly with the
same package definition except dpi flags.
With this change, all the dpi-specific apk variants share the base apk's
compiled Java code and only diverge at the point we add resources/assets
to the apk.
Also we set up variables/targets/rules in a way those dpi-specific apks
appear to be independent apks to the users, for example, you can pass
"AppName_<dpi_name>" to tapas, and AppName_<dpi_name>.apk lives in its
own intermediate directory.
Bug: 18388705
Change-Id: I2ba4972ea7d1f796352fab2407888f996781ae44
For apps, we don't want to set up the prebuilt apk rule twice even if
"LOCAL_MULTILIB := both", which for apps really means to set up only the
jni library rules twice. See also build/core/install_jni_libs.mk.
Change-Id: Id0406c3c605c6ede613dba06178a1710590c09b3
This will be necessary to support -std=gnu99 mode for clang 3.6, which
defaults to C11 mode (unlike prior releases that use C99).
Change-Id: Iea84582f9f12ba76b988463cbc0a20bd61042538
This breaks our build-art-host and build-art-target. I think we need to rewrite those rules as well.
This reverts commit 29f0a487b0.
Change-Id: I2e6674e01a2042e9d53e28ecd3e6bdf76fa806a3
There are a _lot_ of users of `typeof` in the tree, and they'll need a
GNU flavored standard. Rather than fixing up all of these
individually, let's just use gnu++11 as the default.
Bug: 18466763
Change-Id: Ia1bd3adaa74fadba259fda3d37653fb8d5cff69a
There are no more users of TARGET_CPU_SMP in the current codebase.
Expert users should set "-smp" in DEX2OAT_TARGET_INSTRUCTION_SET_FEATURES
for targets that run on a single-core CPU.
Change-Id: Ib94865f05a92c9a4622540cebc18ded4bdfa6363
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
This caused a lot of failures in the libc++ tests, since linking
libgcc.a before libc++.so means that the wrong unwinder will be used.
This patch is still correct, but I will revert for now while I find a
good way to apply it without breaking unwinding.
This reverts commit 741b36e922.
Change-Id: I57e0b89534adf5c1677dbf2f64ac750e74bd5fbf
A device can set up BOARD_SYSTEMIMAGE_JOURNAL_SIZE (number of journal blocks)
in its BoardConfig.mk.
To disable journaling, set "BOARD_SYSTEMIMAGE_JOURNAL_SIZE := 0".
BOARD_VENDORIMAGE_JOURNAL_SIZE and BOARD_OEMIMAGE_JOURNAL_SIZE work in
similar way.
Bug: 18430740
Change-Id: I0594814fe19ffc54dff41ec2464e2e3a802b9419
Allow a compiled-classes file for pre-opting.
Bug: 18410571
(cherry picked from commit 4fec0bb265)
Change-Id: I8c69dd0fb8c04aaae0c4f062049cc9cce7d755c7
When WITH_DEXPREOPT=true is set, if we also set WITH_DEXPREOPT_PIC=true
then the build will generate position-independent OAT images.
This means that all the system applications no longer need to be
relocated into /data/dalvik-cache and this can achieve saving disk space
at the cost of slightly slower running code.
Bug: 18035729
(cherry picked from commit da9f1a7e82)
Change-Id: Ifd517c842f48bf31568bf5ff56667298d422c2c0
No one's using ARCH_AARCH64 or AARCH_MIPS64 yet, and ARCH_PPC was always more
aspirational than real.
Change-Id: I07c6cbad6eb0917c4c24848a98c3bc9a3fe72db6
Previously we store tag's installed modules in a separate variable
ALL_MODULE_TAGS.$(tag). However we only record the main installed file
for a module, but omit affiliated files like .odex.
With this change, we handle the tagged module the same way as modules in
PRODUCT_PACKAGES.
Change-Id: I7972528a4df5a4ba8bc98930864da9672d32d7fe
Two new LOCAL variables are added to support dpi-specific prebuilt apk
selection:
- LOCAL_DPI_VARIANTS: specify a list of dpis the module provides with
specific prebuilt.
Example: LOCAL_DPI_VARIANTS := xxhdpi xhdpi hdpi mdpi
- LOCAL_DPI_FILE_STEM: specify the dpi-specific source file name
pattern.
Example: LOCAL_DPI_FILE_STEM := MyApp-%.apk
"%" will be substitued by $(PRODUCT_AAPT_PREF_CONFIG) in the core
build system.
If you don't set up LOCAL_DPI_FILE_STEM, the default is
$(LOCAL_MODULE)_%.apk.
The build system searches $(PRODUCT_AAPT_PREF_CONFIG) in a prebuilt apk
module's $(LOCAL_DPI_VARIANTS). If not found, use whatever
$(LOCAL_SRC_FILES) as the source file; Otherwise use $(LOCAL_DPI_FILE_STEM)
to construct the dpi-specific apk's source file name, and use whatever
directory name of $(LOCAL_SRC_FILES).
Bug: 18388705
Change-Id: I63cae73f1b6f880302142abc476b3ce1fb5500b5
Install preloaded-classes as a standalone configuration file
/system/etc/preloaded-classes, so we can configure different file per product.
To override the default frameworks/base/preloaded-classes, just override
in your product configuration makefile with PRODUCT_COPY_FILES before it
inherits from build/target/product/base.mk: if there are multiple items
in PRODUCT_COPY_FILES with the same destination, the first one takes
precedence.
Bug: 18305157
Change-Id: I937632b4a1aa73310ec90e73fd708fbd0c704a21
Elliott Hughes