Possibly incorrect android build metadata associated with eve Chrome OS releases |
||
Issue descriptionOS: Chrome OS 10718.71.2 Board: eve The metadata information associated with eve release 10718.71.2, https://pantheon.corp.google.com/storage/browser/chromeos-image-archive/eve-release/R68-10718.71.2?pli=1&prefix=partial-metadata, shows Android build "4922387". I interpret this value to be the android buildid of device cheets_x86 that is used with this Chrome OS release. Please let me know if my interpretation is wrong. We use this information to fetch the symbols associated with that android build, e.g. file cheets_x86-symbols-4922387.zip from https://android-build.googleplex.com/builds/submitted/4922387/cheets_x86-userdebug/latest. We use the ingested symbols to symbolize perf samples received from user devices. We get pretty good symbolization coverage for ARC++ libraries that have build IDs. It used to be above 99%, but in the last few months it dropped towards 96%. See http://b/112326515. During my investigation, I found that the linker build ID associated with samples mapped to libart.so that we collect from user devices is "4616f4738d16c352dc888c0fc3810a8b", while the build ID associated with the libart.so module in cheets_x86-symbols-4922387.zip and cheets_x86-img-4922387.zip is "f2ec67676e1ecc2524fe4f679c4940b9". You can read the linker build ID for an ELF executable with: readelf -n <path_to_exe> This makes it look like a different android build image is installed on eve boards at version 10718.71.2, then the version indicated in the metadata (4922387). Is there a problem with the metadata generation, or is my interpretation of the android build version from the metadata wrong?
,
Aug 10
Ping Evan, is this the right team generating the ARC++ related metadata for release builds?
,
Aug 10
What happens if you use https://android-build.googleplex.com/builds/submitted/4922387/cheets_x86_64-user/latest instead? All* the build images that are used in CrOS are -user instead of -userdebug. Additionally, eve, soraka and other poppy-base boards use a 64-bit container. * There are a couple of exceptions. betty/novato and *-userdebug boards do use -userdebug images.
,
Aug 10
Luis, thanks, that's it. The cheets_x86_64 version matches the build ID from the field. Do you know of any programmatic way to tell if a board release uses the 64-bit or 32-bit container? I am looking at the partial-metadata.json file, but nothing obvious jumps at me.
,
Aug 10
On the same note, is there also a 64-bit ARM container that we need to ingest for some boards? Right now, I only know of cheets_arm.
,
Aug 10
welp, i don't think we expose that information into that metadata. there's a roundabout way of knowing based on the Chrome OS USE flags for that build: cheets_user_64, cheets_userdebug_64, cheets_user, cheets_userdebug. Maybe we should propagate that information into the metadata, but I have no idea how to do that. Re: ARM we only have 32-bit userspace, so there's no 64-bit ARM container for the time being.
,
Aug 10
Thanks. If I was to open a feature request to expose the device name (cheets_arm, cheets_x86, cheets_x86_64) and build type (user or userdebug) in the metadata, should I file it under this component here in chromium, or in buganizer? I expect it is not a lot of work, since the android build version is already propagated, but somebody has to implement it. |
||
►
Sign in to add a comment |
||
Comment 1 by jclinton@chromium.org
, Aug 9Components: -Infra>Client>ChromeOS>Build Platform>Apps>ARC
Owner: erosky@chromium.org
Status: Assigned (was: Untriaged)