This allows to explicitly deal with situations where we
want to use PRODUCT_COPY_FILES to manage overrides.
Change-Id: I2f87862e19b973f090099f335e9bdeb0c9f3bfe9
The check_target_files_signatures determines what key was used to sign
every .apk in a given target_files. It can compare that signature to
that of another target_files (eg, the previous release for that
device) and flag any problems such as .apks signed with a different
key.
(This is a backport of a change in froyo. It does not affect device
code, only the scripts that sign images and OTA packages.)
This switches the emulator to "single step" emulation mode which is
slower but seems to work-around the current ARMv7 emulation bug.
This allows the dexreopt passes to go through normally.
This detail got lost in my previous cleanup change 9b4a812.
Also add a comment explaining why the host side of the
simulator needs to be built in 64-bit (wxWidgets).
Change-Id: I2a867f7f80b43d53e73348b19f6ae834600295f9
The only OS-ARCH combo that would have benefited from it
is linux-x86, but it explicitly used separate configurations
for the HOST_ and TARGET_ side of things.
This makes is clear which files are related to the HOST_
configuration and which ones are related to the TARGET_
configuration, and expands $(combo_target) to the only
possible/reasonable value that it could have had in every
file.
This also cleans up the simulator, by moving it in a single
place in TARGET_linux_x86 (since the only part that's special
is to use HOST_ settings even when building TARGET_ modules).
Change-Id: I2420eeb8cfe539f5807ec99cb3177ffb9f2476d5
The "set default variant to armv5te if none defined" in the ARM config
was applying to all architectures, but as it turns out only ARM builds
actually cared. When I made a copy of the "set default" code to the x86
config, one or the other would win for builds that didn't specify a
variant. Turns out x86 won, so sim and voles worked, but opal didn't.
applypatch now takes patches as blob-valued arguments instead of just
filenames, eliminating the need to unpack all patches to /tmp before
starting to apply them.
Revert the last change I made where sha1_check(read_file(...)) was
substituted for apply_patch_check(...). apply_patch_check() knows to
check /cache/saved.file if the original source file is missing or has
a bad checksum, which is important if the device loses power or
otherwise restarts during patching.
Change-Id: Ia5b761474b0f809a5a5eed29455b1b145145699e
This allows to use a proper $(call inherit-product) across
the open-source -> non-open-source boundary in a way that
can automatically adapt to whether the non-open-source
part is present or not
Change-Id: I357721c68362ff8c0f90610850b0368adee68ada
- Delete the applypatch code (it's being moved to bootable/recovery).
- Change the OTA script generator to verify the sha1sum of all the
patch files after they are unpacked into /tmp.
b/2361316 - VZW Issue PP628: Continuous reset to Droid logo:
framework-res.apk update failed (CR LIBtt59130)
Change-Id: I5858d48f10127f72e708d50d3de844569d1aff27
The variable inheritance system can leave extra spaces in a variable
when multiple levels of inheritance are used. It can expand:
"@inherit:foo @inherit:bar @inherit:baz"
to
"value @inherit:bar @inherit:baz"
and then
"value @inherit:baz" (if bar has no value for the variable)
and then
"value " (if baz also has no value).
Call strip to remove excess spaces between words after each
replacement pass.
Change-Id: Ic4cfc6fed1865066a6353a522e4bdcb68ec875d3
Use the PWD= /bin/pwd trick used in getopt in mmm so that it can deal with a symlinked
root directory.
Change-Id: Ia8b5ef10cbd10ca05f2301db86f64fdf11ff2840
If there are packages that specify logtags being built that aren't
included in the product, their logtags won't be included in the merged
file. Assign an arbitrary tag number to them so they can be built
anyway.
Change-Id: I4929016bf289b7a814b48bc51f324c09f500fab1
With this change, you can specify "?" in place of a tag number in a
.logtags file and the build system will assign numbers to these tags.
(The numbers used shouldn't matter since we translate them back to tag
names whenever the logs are read back.)
This is pretty straightforward to do:
- make merge-event-log-tags.py assign numbers to any tags that specify
"?"
- make the generated java files depend on the merged output
- make java-event-log-tags.py read both the original .logtags and the
merged output, and fill in tag numbers for any "?" using the merged
version.
Change-Id: Icc6ccd705db461d570fc929922a830aa6deaca48
(Cherry-pick from donut.)
Delete the old recovery-from-boot patch before patching system files,
then install the new one at the end of the process. Also fix an issue
with applypatch returning the wrong status.
Change-Id: I614fce39f307eded696ba792912b863f9fb0580b
