build fingerprint about android-prepare-vendor HOT 14 CLOSED

Yeah there is a warning triggered only for userdebug builds (it doesn't affect release builds). The reason is the following chunk from build/core/Makefile

134 # The string used to uniquely identify the combined build and product; used by the OTA server.
135 ifeq (,$(strip $(BUILD_FINGERPRINT)))
136   ifneq ($(filter eng.%,$(BUILD_NUMBER)),)
137     # Trim down BUILD_FINGERPRINT: the default BUILD_NUMBER makes it easily exceed
138     # the Android system property length limit (PROPERTY_VALUE_MAX=92).
139     BF_BUILD_NUMBER := $(shell echo $${USER:0:6})$(shell $(DATE) +%m%d%H%M)
140   else
141     BF_BUILD_NUMBER := $(BUILD_NUMBER)
142   endif
143   BUILD_FINGERPRINT := $(PRODUCT_BRAND)/$(TARGET_PRODUCT)/$(TARGET_DEVICE):$(PLATFORM_VERSION)/$(BUILD_ID)/$(BF_BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/$(BUILD_VERSION_TAGS)
144 endif

Now I'm not sure what exactly triggers the redefinition of BUILD_FINGERPRINT against the same build run. I'm guessing either some intermediate files not correctly updated or some resource of core makefile when vendor img is build. This is something new spotted against ninja build infra and this commit seems related if you want to get to the bottom of it.

I'm guessing that using PRODUCT_PROPERTY_OVERRIDES should be enough to remove the date part from BUILD_FINGERPRINT. Something like the following added at the vendor/<vendor>/<device>/Android.mk should do the trick.

PRODUCT_PROPERTY_OVERRIDES += \
  BUILD_FINGERPRINT := $(PRODUCT_BRAND)/$(TARGET_PRODUCT)/$(TARGET_DEVICE):$(PLATFORM_VERSION)/$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/$(BUILD_VERSION_TAGS)

Since I don't have time to test it at the moment let me know if that worked so I can formalize and maybe add it at the generated makefiles when userdebug build is detected. Or at least document it somewhere.

from android-prepare-vendor.

Have edited previous answer the correct flag for latest build system is PRODUCT_PROPERTY_OVERRIDES and not PRODUCT_BUILD_PROP_OVERRIDES.

from android-prepare-vendor.

Thanks for the info, i've noticed that override in cyanogens config files. Started a fresh build with these overrides so i'll post the result.

from android-prepare-vendor.

Ok, the update: I've tried your approach, had to configure my build to support PRODUCT_BUILD_PROP_OVERRIDES (PRODUCT_PROPERTY_OVERRIDES didnt work from scratch). I saw that this is used by cyanogen for example, they set the system fingerprint to be the one matching the latest build from google so when you flash official vendor.img everything should work. But, my test showed that my system.img actually gets my new custom fingerprint while vendor.img still gets the default one (it was not overridden).

Anyways, I realized what the problem was on my side: my build crashes somewhere on 45-50% of process with out of memory error. I just restart the build and thats probably where the fingerprint gets generated again with different timestamp. I deleted system and vendor img, started the build again and fingerprints would match :)

Btw, what I dont get is this: how does CM work with factory vendor.img? I havent had any luck with AOSP and flashing factory vendor.img, how do they manage to get it working?

from android-prepare-vendor.

They disable verified boot (dm-verity) and set their fingerprint to match the latest factory vendor.img.

from android-prepare-vendor.

So if I understood that right the problem is that after corrupted build (error or user abort) the build.prop is not invalidated properly thus the difference between system & vendor versions of the file.

Sounds like an upstream problem to me. Have you isolated which file is the one that is not invalidated by the build system after the corrupted build? Is it some intermediate version or the final one? If it's something trivial we can track it down and commit upstream.

from android-prepare-vendor.

Yup, if the build was corrupted for whatever reason, when I relaunch it again (without doing make clean/clobber) it completes successfully but build.prop files from system and vendor have different fingerprintes. The vendor fingerprint matches the fp from build_fingerprint.txt but the system fingerprint is different.

On my side, the build fails because jack has no more memory so if I increase it via Xmx my build goes smooth all the way and I get identical fingerprints. Not sure if I could pinpoint it to a particular file as it depends when will I run out of memory (at least in my case).

from android-prepare-vendor.

So to recap,

PRODUCT_PROPERTY_OVERRIDES += \ BUILD_FINGERPRINT := $(PRODUCT_BRAND)/$(TARGET_PRODUCT)/$(TARGET_DEVICE):$(PLATFORM_VERSION)/$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/$(BUILD_VERSION_TAGS)

Adding this to the overlays should be enough, right? Any other commits I need or am I good?

from android-prepare-vendor.

No the property overrides method doesn't appear to work for definitions in core Makefile. You need to directly set them at a Makefile that is included before the core so that definition can be overriden. Such a case is the vendor BoardConfig makefile.

For example I was able to modify the fingerprint for a N6p userdebug build by placing the following at vendor/huawei/angler/BoardConfigVendor.mk

ifeq ($(TARGET_BUILD_VARIANT),userdebug)
    BF_BUILD_NUMBER := $(USER)
    BUILD_FINGERPRINT := $(PRODUCT_BRAND)/$(TARGET_PRODUCT)/$(TARGET_DEVICE):$(PLATFORM_VERSION)/$(BUILD_ID)/$(BF_BUILD_NUMBER):$(TARGET_BUILD_VARIANT)
endif

However, the underlying problem still exists. The vendor/build.prop and the intermediate build_fingerprint.txt are correctly updated with the new fingerprint (even without doing the previous change), although the system/build.prop generated from previous build is not invalidated and thus not updated. The reason that is not invalidated appears to be related to obj/ETC/system_build_prop_intermediates/build.prop file which maintains the old fingerprint. This is an upstream bug I would probably report it at some point (or directly push a fix at AOSP).

An automation option that doesn't require modifying the AOSP source code would be to invalidate (delete) the old build fingerprints from the vendor Android.mk. I've test the following against an N6p userdebug build with leftovers from previous build and it appears to work.

In vendor/huawei/angler/Android.mk add the following:

ifeq ($(TARGET_BUILD_VARIANT),userdebug)
  intermediate_system_build_prop := $(call intermediates-dir-for,ETC,system_build_prop)/build.prop
  $(shell rm $(TARGET_OUT)/build.prop $(intermediate_system_build_prop) $(TARGET_OUT_VENDOR)/build.prop)
endif

This will effectively delete possible leftovers from previous builds and does not require to override the BUILD_FINGERPRINT as discussed before.

from android-prepare-vendor.

This was for sure working with MM builds, I could cancel them and continue again anytime I want and it would go with the same build fingerprint. Maybe building the vendor image actually makes it confused? If vendor was not intended to be built with the image maybe the dont consider that as a bug?

from android-prepare-vendor.

Building vendor image as we do in this project is actually the step that surfaces the problem and not part of the problem.

From my point of view AOSP still has a bug since a build fingerprint that includes a date timestamp is not properly invalidated between builds (that obviously occur in different time). People applying incremental builds (even without vendor partition being build) will still have a problem identifying the builds in an automated way since the fingerprint will be identical across builds that don't clean before (that was the purpose of adding the date there).

If the previous trick does the dirty work across the border (+ backwards compatible) I might add it at vendor generate rules, although I still prefer an upstream fix since every additional hack is another headache to deal with the next major release.

from android-prepare-vendor.

I completely agree, was not my intention to point out that your tool has an issue. And I also find it very frustrating to work on my ROM since if there is a build error or it is interrupted somehow, I'll end up with that lame warning on boot saying my device has internal problem. I would probably take on that on my own but I dont have that much experience with build process so not sure I would be able to fix it and push it upstream.

Shall I close the question now? (big thanks to you for your support!)

from android-prepare-vendor.

No problem. Yeah you can close it.

from android-prepare-vendor.

You can export BUILD_NUMBER before building, and you can reuse whatever was used for your last build to make incremental builds work properly.

from android-prepare-vendor.