Run the LabRecorder GUI on Android

[tstenner]

After #2 it should be possible to compile the whole LabRecorder GUI for Android.

Needed: build instructions and testers.

[cboulay]

Does this use the same Qt GUI as desktop? If yes, what version of Qt is required? My recent PR #7 is built against 5.11 but I don't think there's anything newer than 5.8 in there.

[tstenner]

Ubuntu 16.04 still ships 5.6, so I'd rather not use anything newer than that before April 2019.

In the end, we should use whichever version has precompiled binaries for a recent Android toolchain and is preinstalled on the CI systems. I have a couple of changes to liblsl-Java and liblsl-Android that simplify the android builds for liblsl and other cmake projects, after that Qt should - in theory - just work.

[mgrivich]

Qt should - in theory - just work.

Ha Ha Ha ..... Ha

Anyways, I put a few days into this. I was able to get it to compile (including Qt).

Using ninja, the latest version (important) of cmake and the android sdk and ndk, I am able to get LabRecorder to compile with

c:\labstreaminglayer\build>cmake .. -G "Ninja" -DQt5_DIR="C:/Qt5.12.0/5.12.0/android_armv7/lib/cmake/Qt5" -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK="c:/AndroidStudio/android-sdk/ndk-bundle" -DIS_LITTLE_ENDIAN=TRUE -DCMAKE_ANDROID_ARCH_ABI=armeabi-v7a -DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang -DCMAKE_ANDROID_STL_TYPE=c++_shared -DLSLAPPS_Labrecorder=ON

c:\labstreaminglayer\build>cmake --build . --config Release -target install

I had to remove

if (MINGW)
      target_link_libraries (${target} PUBLIC ws2_32 wsock32 winmm)
endif()

from LSL/libllsl/CMakeLists.txt. This should be removed permanently, right? No one should be linking boost libraries anymore.

Older versions of the android ndk fail due to missing features, such as std::to_string and std::make_unique. Older versions of CMake fail because the newest android ndk deprecated a bunch of features

However, this just makes a pile of build products. I still need to build the apk, using androiddeployqt deployment tool, as described by http://doc.qt.io/qt-5/deployment-android.html, with a relatively simple test project at https://github.com/LaurentGomila/qt-android-cmake. I was making good progress adapting Laurent's project to ours, when I started getting very suspicious errors about ndk tools not being there.

I then found this: https://bugreports.qt.io/browse/QTBUG-70650. So, Qt does not yet work with NDK 18.

So, if you're keeping track, with our current source, android apks cannot be built.

I think it is best to wait until Qt fixes the issue to proceed with Qt on Android. NDK 18 is significantly better than previous versions, but in order for that to happen, some features had to get removed.

For now, if Lab Recorder functionality is needed on Android, the developer would need to make a Java wrapper around some sort of Lab Recorder library. Is someone currently building such a library?

[cboulay]

For now, if Lab Recorder functionality is needed on Android, the developer would need to make a Java wrapper around some sort of Lab Recorder library. Is someone currently building such a library?

Tristan and I are not in agreement of what this library should look like.

I hope I'm not misrepresenting him, but I think he's of the opinion that the library-consuming client application should do quite a bit, including handling the data, handling the arrival of new streams, using signals and slots, etc.

I'm of the opinion that the library should do just about everything and the client should do as little as possible, maybe limited to things like get_list_of_stream_identifiers(*stream_ids, *stream_strings), set_stream_recording_status(stream_id, on_or_off), get_likely_filename(some, params), start_recording(filename), stop_recording(), get_recorder_status(*state_struct). The client will never touch the data or know for sure the data are being recorded; it only knows what the state_struct tells it and only when it asks for that info.

Tristan doesn't like my approach because it's not responsive to errors and because it'll make debugging difficult.

The reason I don't like Tristan's approach is because it will require repeating a lot of functionality for each implementation. The list of implementations that we feel are necessary are C++, Python, Java, maybe something for iOS, and I think there was a good reason to have C# but I can't remember right now.

[mgrivich]

If you both want me to I can adjudicate this dispute, I can, but I'd need catch up on the details of the competing designs, starting with a list of desired features and use cases. We talked about it a bit in Delmenhorst, but I haven't been in the loop since then.

In other news, I was wrong about Qt being incompatible with ndk 18. That issue was actually closed. I'm now able to build and install the LabRecorder apk. It crashes on lsl_resolve_all, but progress.

[tstenner]

This should be removed permanently, right? No one should be linking boost libraries anymore.

One of the guys in Delmenhorst tried the latest MinGW and it was still needed, but it might be needed by lslboost, not liblsl. Filed in sccn/liblsl#14

Older versions of the android ndk fail due to missing features, such as std::to_string and std::make_unique. Older versions of CMake fail because the newest android ndk deprecated a bunch of features

And newer versions fail because Asio uses then experimental features that have already been moved to the regular headers. I've upgraded lslboost to 1.69 so NDK19 should work have one showstopper less.

I hope I'm not misrepresenting him, but I think he's of the opinion that the library-consuming client application should do quite a bit, including handling the data, handling the arrival of new streams, using signals and slots, etc.

That sums it up quite well. I've created a separate issue for that discussion.