-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Run core tests on Android #5456
Comments
I started of with the a native executable running only the 'simple' tests. With great help from @tmpsantos we got some 20 unit tests to run on the device. However, it seems that these executables have no access to any kind of vm (as they're not started from dalvik/art). Proceeding with the approach in #4671. Also, it only compiles with |
Linking #2150 |
Progress - Runs on a vm now, properly linked with gtest in a shared lib, from the command line. But only for a subset of the tests still. A couple of hacks were needed to get things going:
|
Concerning the crash in jni.cpp:
|
/sub |
The crash occurs during setup of the JNI bindings. It's trying to look up the |
Could be @jfirebaugh . But, if I load the class from the vm side, it loads fine: |
The crash above was indeed caused by a class loading issue. The underlying cause however was that |
…tings are conditional to the target platform.
…dedicated work directory to keep the device/sim clean
Current status:
|
…dedicated work directory to keep the device/sim clean
Completed the port of the nodejs webserver to c++ using cpp-httplib. cpp-httplib seems to have a serious issue with concurrency though. This results in the
|
Remaining issues on androidOn the android side of the tests, there are a couple more issues:
I've included the details for these below. test/storage/online_file_source.cpp won't compile:
http tests crash.On arm-v7:
From logcat:
On x86 (emulator)
Which is weird. The Java class for Log is loaded, but the associated native library isn't. Need to figure out which shared library contains the native implementations. AssetFileSource crashes
From logcat+ndk-stack
API.RepeatedRender lockupOn the emulator:
But this is also printed for the tests that succeed, might not be related. More probable is that I don't clean up correctly as it seems to lock after a couple of render iterations. On arm-v7 I don't get these messages (still locks up though). Maybe an emulator issue. |
Concerning the crash of the Http tests on Android. After removing the Log.* calls from our HTTPContext class, the tests ran rather smoothly. Turns out that not all native methods from the Android framework are loaded at the proper time. Loading the correct library ( The missing methods native methods are in the util Log class. Registration of these methods seem to go through the AndroidRuntime class: Both are package protected, so not easily re-usable. But similar functionality shouldn't be too hard to create for our test loader if we can link to either of those functions. Otherwise we can probably stub out the Log class as it is the only class from the runtime we need atm. |
@ivovandongen basic integration for x86 has landed, good to close for now? |
This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions. |
In order to test the android bindings for core-gl we need to run the core unit tests on Android.
There two ways to run the tests:
Furthermore, there are a couple types of tests:
The text was updated successfully, but these errors were encountered: