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
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)
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
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
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
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
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
Change boot, recovery, and verity metadata signing keys to use the
same PKCS8 / X.509 PEM format as the other signing keys, and update
build scripts to use correct arguments for the updated signing
tools.
Bug: 15984840
Bug: 18120110
Change-Id: I23ed5a004ecdad6cf7696487935ad5031eb8adf8
(cherry picked from commit 72d90eb189)
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
Change-Id: Ifd517c842f48bf31568bf5ff56667298d422c2c0
- Added LOCAL_DEX_PREOPT_FLAGS to pass extra flags to dex2oat.
- Added macro add-product-dex-preopt-module-config to specify almost
arbitrary dex-preopt config/flags to modules in product
configuration:
$(call \
add-product-dex-preopt-module-config,<module_name_list>,<config_or_flags>)
How <config_or_flags> is interpreted is decided by
dex_preopt_odex_install.mk and dex2oat. For now if it's "disable" we
disable dexpreopt for the given modules; otherwise pass it to dex2oat as
command line flags.
- If there are multiple configs for the same module in the product
inheritance, the first takes precedence.
- Added PRODUCT_DEX_PREOPT_DEFAULT_FLAGS so you can specify default
dex2oat flags in product configuration.
- Added PRODUCT_DEX_PREOPT_BOOT_FLAGS to specify flags of building boot.oat.
Bug: 17791867
(cherry picked from commit 20ebd2ef08)
Change-Id: I2ee36892b40655c96837ee7a663dda1d25830878
It's better practice to include the minimal set of windows APIs anyways
and we're not doing anything that requires more.
Change-Id: I1b4362be4f707738b9cfbd6a87caabff8b8409ac
Some ext4 options were not suitable for all kernel versions.
The current option were checked against kernels 3.0 3.4 3.10.
Bug: 18092222
Change-Id: I30883706e5c8ac7a318f4b448d4becde50de808f
Currently recovery install/patch will mount /system++ with only default
options.
The default options are not very suitable for dealing with crashes.
We now use
TARGET_RECOVERY_FSTYPE_MOUNT_OPTIONS
that can specify which mount options to use for a given fs-type.
# <fstype>=<fstype_opts>[|<fstype_opts>]...
# fstype_opts := <opt>[,<opt>]...
# opt := <name>[=<value>]
If only defaults are to be used, then the BoardConfig.mk can just have
an empty (must have ""):
TARGET_RECOVERY_FSTYPE_MOUNT_OPTIONS := ""
The default is
"ext4=match_batch_time=0,commit=1,data=journal,barrier=1,errors=panic,nodelalloc"
The release tools will pick them up with
https://googleplex-android-review.git.corp.google.com/#/c/573628
Bug: 18092222
Change-Id: Iaa59099b0edf5af8835d1862fada089cff58882c
Windows does not have pthread support, and by defining the
GTEST_OS_WINDOWS flag, pthread support will not be built into
the windows version of gtest.
Change-Id: I0571fc52e77bb04175470d5750a7e2f46cdd5e86
Fix an issue where the add-on system images have 2 extra
inner folders. The sole root folder in the zip file should
be the ABI one.
Change-Id: Ie12b913438e2b1113d34222e467ff280daa23c7f
In case of emulator images created for an sdk build (sdk, win_sdk,
sdk_addon), do not set dex2oat to compile apps interpret-only.
Bug: 17796919
Change-Id: I6961aa20fd3b6ea164a1f55321387e84c8983550
You need those constant variables when you want to insert newline or
backslash at the end of a macro.
Change-Id: I3fe96580d7a4ebc9d013afe6dd4ec8f40f49c724
