931190 - Code to determine android version at runtime does not work on test infrastructure

Status: NEW

(Core :: General, defect)

Description

[u408661]

Code in gecko that determines (at runtime) the version of Android does not work properly when run on our test infrastructure. Example code at https://mxr.mozilla.org/mozilla-central/source/content/media/plugins/MediaPluginHost.cpp?rev=cb8146788ab1#117 (which was copied by me for bug 881804, which surfaced this bug) will return "2" on android 2.2 or "3" on android 4, instead of "8" or "18" (the proper values), respectively. The numbers returned appear to be the first digit of the kernel version, instead of the API version. This code works just fine on an actual android phone, so I suspect some configuration issue with the boards used for testing, hence this being filed under RelEng.

Comment 1

[Phil Ringnalda (:philor)]

Seems odd and unlikely that it would be the fault of releng that that doesn't work, given that the same thing in JS, http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/reftest.js#609, most certainly does work, as the various "AndroidVersion>=15" lines in reftest and crashtest manifests attest. If you look for "394751.xhtml" (which I know to look for because I just stuck the condition in recently) in Tegra and Panda crashtest logs, you'll see it being skipped on 2.2 and run on 4.0.

Comment 2

[u408661]

That does seem quite odd (and, I might add, disconcerting). Just so people don't think I'm full of it, though, https://tbpl.mozilla.org/?tree=Try&rev=15dd2f281e3b has an example of code failing on infrastructure, that proceeds to work just fine on my android device (I have a log which is unfortunately on a machine I don't currently have access to - suffice to say, it doesn't abort, and if I log the value, it's the expected 18 on my android 4.3 device).

Still not sure where this belongs, given both the code paths are the same (modulo the xpconnect translation from js<->c++ in the versions that work), but I agree that it's likely not the fault of releng.

Comment 3

[Justin Wood (:Callek)]

(In reply to Nicholas Hurley [:hurley] from comment #2)
> That does seem quite odd (and, I might add, disconcerting). Just so people
> don't think I'm full of it, though,
> https://tbpl.mozilla.org/?tree=Try&rev=15dd2f281e3b has an example of code
> failing on infrastructure, that proceeds to work just fine on my android
> device (I have a log which is unfortunately on a machine I don't currently
> have access to - suffice to say, it doesn't abort, and if I log the value,
> it's the expected 18 on my android 4.3 device).
> 
> Still not sure where this belongs, given both the code paths are the same
> (modulo the xpconnect translation from js<->c++ in the versions that work),
> but I agree that it's likely not the fault of releng.

our infra does not run Android 4.3, to be clear. Its entirely possible/likely that there is a change in Android 4.3 that is not on our infra. And also carriers and Hardware vendors also routinely make changes to Android Source code for their hardware platforms, which is something to be aware of when comparing local vs our infra.

Comment 4

[u408661]

(In reply to Justin Wood (:Callek) from comment #3)
> our infra does not run Android 4.3, to be clear. Its entirely
> possible/likely that there is a change in Android 4.3 that is not on our
> infra.

While true, I don't think that any differences between our infra and android 4.3 would matter, as this code is also used by the media layer (which is where I aped the code from) to behave differently on different android versions all the way down to android 2.x, on all different devices. I'm convinced this isn't a releng issue, but like I said, I have no idea at this point where the issue actually lies.

Comment 5

[Richard Newman [:rnewman]]

Relevant?

        // NSPR "version" is the kernel version. For Android we want the Android version.
        // Rename SDK version to version and put the kernel version into kernel_version.
        rv = GetPropertyAsAString(NS_LITERAL_STRING("version"), str);
        if (NS_SUCCEEDED(rv)) {
            SetPropertyAsAString(NS_LITERAL_STRING("kernel_version"), str);
        }
        SetPropertyAsInt32(NS_LITERAL_STRING("version"), android_sdk_version);

N.B., that if you want this to be reliable (read: almost entirely in Java-land), you could directly fetch the SDK_INT value over the Gecko-Android bridge. We have that value available in the SysInfo class on the Java side: call getVersion().

Happy to help with this if I can.