1073021 - Add base image version to HTML report

Status: RESOLVED FIXED

(Remote Protocol :: Marionette, enhancement)

Description

[Robert Chira [:RobertC]]

It would be nice to have additional information about the device in the html report (e.g., base build and memory setting)

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

As far as I'm aware the base build is not available after a full flash. Also, determining the memory allocation requires switching the device into fastboot mode, so I don't think this would be trivial.

Tony: Do you know a way to determine the base build that persists after a full flash, or a way to determine the memory allocation without using fastboot?

Comment 2

[Tony Chung [:tchung]]

(In reply to Dave Hunt (:davehunt) from comment #1)
> As far as I'm aware the base build is not available after a full flash.
> Also, determining the memory allocation requires switching the device into
> fastboot mode, so I don't think this would be trivial.
> 
> Tony: Do you know a way to determine the base build that persists after a
> full flash, or a way to determine the memory allocation without using
> fastboot?

Determining base build version:
Easiest way on KK only, just do:  adb shell getprop ro.boot.bootloader
$ L1TC10011800   (where "...xxx180x" is version 180)

Longer way:  (from check_versions.sh in b2g-flash-tool repo)
# get and print device information
PROPS=( "Device-Name:ro.product.device"
        "FW-Release:ro.build.version.release"
        "FW-Incremental:ro.build.version.incremental"
        "FW-Date:ro.build.date"
        "Bootloader:ro.boot.bootloader" )
for KEY_VALUE in "${PROPS[@]}" ; do
    KEY="${KEY_VALUE%%:*}"
    VALUE="${KEY_VALUE##*:}"
    RET=$(run_adb shell getprop $VALUE | tr -d '\r\n')
    if [[ ${RET} ]]; then
        printf ${OUTPUT_FORMAT_DEVICE} "${KEY}" "${RET}"
    fi
done

As for memory allocation, not sure what you are asking?  can you get away with adb shell b2g-info or adb shell cat /proc/meminfo?

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to Tony Chung [:tchung] from comment #2)
> (In reply to Dave Hunt (:davehunt) from comment #1)
> > As far as I'm aware the base build is not available after a full flash.
> > Also, determining the memory allocation requires switching the device into
> > fastboot mode, so I don't think this would be trivial.
> > 
> > Tony: Do you know a way to determine the base build that persists after a
> > full flash, or a way to determine the memory allocation without using
> > fastboot?
> 
> Determining base build version:
> Easiest way on KK only, just do:  adb shell getprop ro.boot.bootloader
> $ L1TC10011800   (where "...xxx180x" is version 180)

Great, that appears to persist beyond a full flash. I've raised bug 1073441 to get this into mozversion. Once there, we should just need to include the new entry in the HTML report.

> As for memory allocation, not sure what you are asking?  can you get away
> with adb shell b2g-info or adb shell cat /proc/meminfo?

It looks like grabbing MemTotal from /proc/meminfo would be enough, and pretty easy to do. I don't think this should be in mozversion though, we could either do it in mozdevice or just directly into the HTML report.

Comment 4

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Attachment: Add base image version to HTML report. v1.0

Comment 5

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to Dave Hunt (:davehunt) from comment #3)
> (In reply to Tony Chung [:tchung] from comment #2)
> > As for memory allocation, not sure what you are asking?  can you get away
> > with adb shell b2g-info or adb shell cat /proc/meminfo?
> 
> It looks like grabbing MemTotal from /proc/meminfo would be enough, and
> pretty easy to do. I don't think this should be in mozversion though, we
> could either do it in mozdevice or just directly into the HTML report.

Will: Do you think this is something we should add to mozdevice? I see that getInfo [1] could return memory stats, but currently doesn't for the ADB device manager [2].

[1] http://mozbase.readthedocs.org/en/latest/mozdevice.html#mozdevice.DeviceManager.getInfo
[2] http://hg.mozilla.org/mozilla-central/file/2399d1ae89e9/testing/mozbase/mozdevice/mozdevice/devicemanagerADB.py#l499

Comment 6

[William Lachance (:wlach)]

(In reply to Dave Hunt (:davehunt) from comment #5)
> (In reply to Dave Hunt (:davehunt) from comment #3)
> > (In reply to Tony Chung [:tchung] from comment #2)
> > > As for memory allocation, not sure what you are asking?  can you get away
> > > with adb shell b2g-info or adb shell cat /proc/meminfo?
> > 
> > It looks like grabbing MemTotal from /proc/meminfo would be enough, and
> > pretty easy to do. I don't think this should be in mozversion though, we
> > could either do it in mozdevice or just directly into the HTML report.
> 
> Will: Do you think this is something we should add to mozdevice? I see that
> getInfo [1] could return memory stats, but currently doesn't for the ADB
> device manager [2].
> 
> [1]
> http://mozbase.readthedocs.org/en/latest/mozdevice.html#mozdevice.
> DeviceManager.getInfo
> [2]
> http://hg.mozilla.org/mozilla-central/file/2399d1ae89e9/testing/mozbase/
> mozdevice/mozdevice/devicemanagerADB.py#l499

I think it would be a good idea to put something like this in devicemanagerADB? The current return value from devicemanagerSUT for memory available is kinda broken and illegible (I get "PA:332009472, FREE: 7692288" and have no idea what it actually means). Maybe a new info keyword like "memtotal" which just gives the total amount of ram available on the device makes the most sense.

Comment 7

[Dave Hunt [:davehunt] [he/him] ⌚BST]

I've raised bug 1078274 for returning the total memory available on the device. Let me know if you're interested to work on this, I'd be happy to mentor.

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f50d71868097

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f50d71868097

Comment 10

[Dave Hunt [:davehunt] [he/him] ⌚BST]

I'm going to close this and implement the device information changes as part of bug 1065402. This is because getting a device manager instance in the code that generates the HTML report will be quite hacky.