Bug 109144 – build-webkit --chromium-android should complain if build environment is not set up correctly

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit Misc.

[Dominic Cooney]

Version: WebKit r142063
OS: Ubuntu 12.04

What steps will reproduce the problem?

1. Check out WebKit
2. Tools/Scripts/update-webkit --chromium-android
3. Tools/Scripts/build-webkit --chromium-android
4. Tools/Scripts/run-webkit-tests --chromium-android

What is the expected output? What do you see instead?

I expect the tests to run.

Instead, the tests hang. Inspecting with adb logcat, the test binary is failing to start because the ChromiumActivity superclass is not found.

Inspecting the APK, indeed the class is missing.

I started digging into this and looked at GYP (dependencies on chromium_base which contains ChromiumActivity looks OK) and generate_native_test.py (looks OK, passes the chromium_base JAR to ant.)

If I turn on verbose ant output, I see this:

[dex] Using Pre-Dexed chromium_base-a1936b86d1a1176fd0026791ff4d6303.jar <- /work/WebKit/out/Release/lib.java/chromium_base.jar

and if I dig up this file I find it just contains MANIFEST/MANIFEST.MF. It looks like ChromiumActivity has been... "aggressively optimized."

[Dominic Cooney]

Here is the specific part of adb logcat of interest:

I/ActivityManager(  477): Start proc org.chromium.native_test for activity org.chromium.native_test/.ChromeNativeTestActivity: pid=16283 uid=10064 gids={50064, 1006, 3003, 1015, 1028}                                                       
D/dalvikvm(16283): Late-enabling CheckJNI                                       
W/dalvikvm(16283): Unable to resolve superclass of Lorg/chromium/native_test/ChromeNativeTestActivity; (19)                                                    
W/dalvikvm(16283): Link of class 'Lorg/chromium/native_test/ChromeNativeTestActivity;' failed                                                                  
D/AndroidRuntime(16283): Shutting down VM                                       
W/dalvikvm(16283): threadid=1: thread exiting with uncaught exception (group=0x41b10930)                                                                       
E/AndroidRuntime(16283): FATAL EXCEPTION: main                                  
E/AndroidRuntime(16283): java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{org.chromium.native_test/org.chromium.native_test.ChromeNativeTestActivity}: java.lang.ClassNotFoundException: Didn't find class "org.chromium.native_test.ChromeNativeTestActivity" on path: /data/app/org.chromium.native_test-1.apk

This occurs in debug and release builds.

[Nico Weber]

Mr Beverloo: This is yours, right?

[Peter Beverloo]

Looking at the bots, the build seems to be fine. Dominic, is JAVA_HOME set and arenyou sure that you're building with Sun Java instead of OpenJDK? Linking errors are common if you use OpenJDK and are completely expected.

[Dominic Cooney]

Created attachment 187786 [details]
Patch

[Dominic Cooney]

Indeed, JAVA_HOME was unset. What do you think about having the script sanity check this? Uploaded a patch to this effect. Otherwise I'm fine if this is RESOLVED WORKSFORME.

[Peter Beverloo]

The suggested way of toggling between Java installations seems to be to execute the following commands, and to remove the directory in which the default installation resides from the PATH in .bashrc.  This does not involve setting or changing JAVA_HOME, so I'm not sure if requiring it to be set is the right approach.

$ sudo update-alternatives --config javac
$ sudo update-alternatives --config java
$ sudo update-alternatives --config javaws
$ sudo update-alternatives --config javap


Chris: Any opinion on this?

[Chris Hopman]

(In reply to comment #6)
> The suggested way of toggling between Java installations seems to be to execute the following commands, and to remove the directory in which the default installation resides from the PATH in .bashrc.  This does not involve setting or changing JAVA_HOME, so I'm not sure if requiring it to be set is the right approach.
> 
> $ sudo update-alternatives --config javac
> $ sudo update-alternatives --config java
> $ sudo update-alternatives --config javaws
> $ sudo update-alternatives --config javap
> 
> 
> Chris: Any opinion on this?

Yeah, our suggested workflow doesn't set JAVA_HOME so I wouldn't check that. It would be better to check that the java binaries are the correct ones, but some of them at least don't really provide a simple way to check it (java has --version, but others don't). 

It would be nice if it were easier to diagnose these problems though (many people have dealt with similar things), I wonder if we could add some sanity check targets to the build that would fail if java weren't setup correctly. This problem isn't specific to WebKit, so putting the sanity checks in a shared place (i.e. build targets) would be nice.

[Dominic Cooney]

Unassigning myself from this for now and deprecating the patch until what checks are desired is clearer.

[Peter Beverloo]

Resolving as WontFix given that Chromium moved to Blink.