- envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set
of things like BUILD_OUT to be able to use some local tools when
doing cross-compilation. This allows us to use the Linux version of
ACP when cross-compiling the tools to Windows.
- Makfile: include windows_sdk.mk when needed to build a Windows SDK.
- main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk)
(Merge master Change I9d08d0df)
Store a dump of the desired uid/gid/mode for every system file in the
target_files zip. Modify ota_from_target_files to use this stored
information when it is available, instead of running fs_config from
the current client (which might be out of sync from the one where the
target_files zip was built).
b/2516887 - New android_filesystem_config.h needed
Change-Id: I8409a0265d1d50daad9c2bc033c99b74b8931b20
This allows to explicitly deal with situations where we
want to use PRODUCT_COPY_FILES to manage overrides.
Change-Id: I2f87862e19b973f090099f335e9bdeb0c9f3bfe9
This allows "make dist" to work on that configuration.
A better fix would be to allow each product to specify
whether it's an emulator target or a device target, and
to adapt to that, but that'd be a lot more intrusive.
Change-Id: I47708025204a4991466abceb1708a3020a543238
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.)
Construct the /system/etc/event-log-tags file by unioning together any
*.logtags files included in LOCAL_SRC_FILES throughout the system (with
appropriate error checking for dup tag numbers, etc.)
For java packages, generate a java source file from the logtags file for
that package that contains static integer constants for each tag name.
Merge commit '1ae988040777f88f766fc421af79a61175e917af' into eclair
* commit '1ae988040777f88f766fc421af79a61175e917af':
Change where makefile looks for sdk_clean.sh
BoardConfig.mk typically defines TARGET_CPU_ABI to the name of the
native machine code CPU ABI supported by the target device. For example,
existing devices today use the value 'armeabi' corresponding to an
ARMv5TE instruction set with soft-float implementation.
This patch allows this file to also define TARGET_CPU_ABI2 to name
a secondary (minor) CPU ABI also supported by the device. This is useful
when the main ABI is ARMv7-A (identified as 'armeabi-v7a') which also
supports ARMv5TE. Such devices should have TARGET_CPU_ABI defined to
'armeabi-v7a' and TARGET_CPU_ABI2 defined to 'armeabi'.
TARGET_CPU_ABI2 will be translated into the ro.product.cpu.abi2 property
in build.prop. This value will be used by the PackageManager to handle
"fat-binaries" generated with the NDK.
Store the location of the releasetools extensions in the target-files
zip, and make ota_from_target_files use that stored location by
default (though it can still be overridden with -s if desired).
Make BoardConfig.mk store the size of the partition rather than the
maximum size of the image that can be flashed there, because the
function used to do the conversion isn't available when BoardConfig.mk
is read any more.
Merge commit '1e96ac8430da922332e4c85e7eed0e95442ff2ce'
* commit '1e96ac8430da922332e4c85e7eed0e95442ff2ce':
Make the recovery.img construction (from boot.img) logic depend on whether recovery.img was installed.
The SDK build doesn't have recovery, don't try to generate a patch or
include it in the system image size calculation. Also there's a
dependency on bsdiff that was omitted.
Instead of storing the whole recovery image in system in order to
flash it on first boot, we instead use an imgdiff patch from the boot
image to create the recovery image. This is substantially smaller
since it effectively only stores the recovery binary and UI images
(the kernel and the init binary are identical to that of the boot
image).
This change modifies the OTA-building script to create and install
these patches, and changes the calculation of the system image size in
the Makefile to reflect the new scheme.
Make some changes needed to applypatch in order to store the recovery
image in the system partition as a binary patch relative to the boot
image:
- make applypatch use shared libraries, so it's smaller. It will
need to be on the main system so it can install the recovery
image. Make an applypatch_static binary for use in recovery
packages (still needed for updating cupcake devices to donut).
- output the results of patching to an in-memory buffer and write
that to the partition; there's no convenient /tmp for us to us.
(This should be basically a no-op in recovery, since /tmp is a
ramdisk anyway.)
When I moved the building of the recovery image upwards in the file, I
moved an 'endif' surrounding it but not the matching 'if'. How did
this ever work?
There are currently two errors in the way we test the size of built
images against the size of the partition on the hardware:
- the limits in BoardConfig.mk are set with the data size only, but
images contain an extra 64 bytes per 2048-byte page. This means we
think the partition is about 1/32 smaller than it really is.
- when we deliver a build via OTA, the system partition ends up with
one more file than when it's flashed via fastboot. That file is a
copy of the recovery image. In order to be able to OTA a build, we
need to make sure the system partition has enough room for all the
system files plus the recovery image as well.
For the kila system partition, these errors are roughly the same order
of magnitude -- about 2MB, one in the "safe" direction, one in the
"unsafe" direction. This change fixes both to give us a more accurate
notion of how close we are to the limit.
Make the build emit a warning (but not fail) when the size is within
32kb of the limit.
Also, include the values of the partition size limits in an info file
in the target-files package, so post-processing tools can use them
without parsing the BoardConfig.mk file.
When building an OTA package, TARGET_RELEASETOOLS_EXTENSIONS can be
set (in BoardConfig.mk) to specify where the device-specific
releasetools code is located. (The default location is the common
directory for the device's vendor.) The TARGET_OTA_SCRIPT_MODE can be
used to override the default script mode ("auto") for a particular
device.
Non-HTC devices may have multiple files constituting their "radio
image". Generalize the INSTALLED_RADIOIMAGE_TARGET variable a bit:
initially define it as empty, then let AndroidBoard.mk files add to
it. Provide a convenience function add-radio-image for them to call
to add files. Put all those files into the target_files zip for use
in OTA and fastboot package construction.
Note that for HTC devices, this changes the name of the radio image in
the target_files zip: instead of "RADIO/image" it will be
"RADIO/radio.img". Tools that use the target_files zip will need to
be changed.
Split the details of generating script syntax into a generator class:
one for amend (whose output should be equivalent to the current
output), and one for edify.
Fix 'otatools' build rule to build imgdiff.
The ota and img building scripts contained some hardcoded 'linux-x86'
paths. Remove and replace with a slightly redefined -p option.
Modify Makefile to pass correct -p when building.
Merge commit '1a28c1a4c1ad0c4adf0c63bb36f47394e9509360'
* commit '1a28c1a4c1ad0c4adf0c63bb36f47394e9509360':
remember in the target-files package what version of the API recovery uses
Some devices define a BOARD_KERNEL_BASE argument which must be given
as an argument to mkbootimg when building a bootable image. Store the
value of this var (if any) in the target-files zip and use it when
building images.
