Skip to content
Snippets Groups Projects

Draft: android: refactor buildsystem for java wrapper and add texture synchronization

3 unresolved threads

Disclamer: this MR is far from being ready, but it's currently working well. Many things are still a bit ugly or experimental.

This merge request implements texture synchronization between the android SurfaceTexture and mediacodec.

Because the android entrypoints are interface only implementable in java, it adds a way to compile and bundle java into a .jar to Android application and bindings (libvlcsharp, libvlcjni) so as to implement the necessary JNI <-> Java wrappers. In a sense, it enables using Java as an IDL to expose C for the java runtime.

A LOT are not completely ready for this MR, but since I already sent part of it on the ML and the buildsystem parts will need some discussion, I think it was important to publish.

It doesn't involve the other buildsystem changes discussed for Android yet.

Merge request reports

Members who can merge are allowed to add commits.

Merge request pipeline #443358 skipped

Merge request pipeline skipped for fe92763d

Ready to merge by members who can write to the target branch.

Merge details

  • The source branch is 5108 commits behind the target branch.
  • 15 commits will be added to master.
  • Source branch will be deleted.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
696
697 # TODOLIST:
698 # - configure.ac: find android path
699 # - configure.ac: find javac
700 # - configure.ac: find dx/dex, compatibility between both?
701 # - Makefile.am: classpath for android?
702 # - Makefile.am: path where to generate
703 # - Makefile.am: install?
704 # - Malefile.am: sources directories for java package handling
705
706 if HAVE_ANDROID_JAR
707 vlc_android_support_jar_JAVASOURCES = \
708 android/java/org/videolan/vlccore/SurfaceTextureListener.java
709
710 vlc_android_support.jar: $(vlc_android_support_jar_JAVASOURCES)
711 $(AM_V_at)rm -rf $(builddir)/android/java
    • We removed Python and .Net from the main repository. And frankly, that seems like it was a very good idea. I don't think we should be adding Java code now...

      ...and especially not as part of the main build system. We have enough problems with Objective C as things stand. Plus this can only confuse new developers trying to set the build system up.

    • Hi, this is not about writing bindings for libvlc, it's really about using Java as a DSL to implement modules in C. Everything in this work stems from the limitation of JNI which cannot implement interfaces in C.

      Because java is of course not mandatory on Android (you can launch application natively through adb shell), there are no mandatory java JNI wrappers, so it seems like a fair trade to me.

      Maintaining JNI code in the core for classes that are not in the core would (is) be really a nightmare. We can write those C/Java wrappers in something else closer to an IDL than java if you prefer, like XML + a conversion tool, but I'm not sure that's really an issue here.

    • Note that I'm all for remove the binding code from libvlccore and push it towards the bindings. It's not just that it's cleaner, but it's also much easier to maintain across varying version of libvlc, much more stable, and much easier for the binding themselves. My work on AWindowHandler typically follows this direction, and I removed the usage of the private surfacetexture from the libvlcjni binding in the libvlc core modules.

      Here, this is quite the opposite. It's typically classes that could have been in libvlcjni, but then the class should also be duplicated in LibVLCSharp, libvlc flutter, etc, though it's just really an entrypoint for the modules to avoid java until it's fully supported in the NDK.

      Wrt. to the buildsystem, I use as few tools as possible (meaning only what's in the SDK and the java that is already potentially used for compiling libbluray).

    • +1 with @alexandre-janniaux

      If we were able to implement interfaces via JNI, we would not need it. Unfortunately, it's not the case. So, you end up with some JNI code in the vlc.git repository that rely on how some interfaces are implemented in vlc-android.git repository.

    • Please register or sign in to reply
  • Alexandre Janniaux mentioned in merge request !1043 (merged)

    mentioned in merge request !1043 (merged)

  • mentioned in issue #26943 (closed)

  • Alexandre Janniaux added 11547 commits

    added 11547 commits

    • f3dec442...50066908 - 11535 commits from branch videolan:master
    • 50066908...e1b75897 - 2 earlier commits
    • 6e0c3c3a - android: utils: load SurfaceTextureListener wrapper
    • 4cea42db - android: utils: setup Handler for SurfaceTextureListener
    • a14f495f - android: utils: synchronize on updateTexImage
    • 668bef18 - configure.ac: add support for android java build
    • 43c22e4c - configure.ac: force version to 29
    • a27523fb - src/Makefile.am: add support for android java build
    • fd4e7ac4 - android: add SurfaceTextureListener java wrapper
    • a32178b1 - extras/package: add build script for android
    • 48972931 - fixup! android: utils: setup Handler for SurfaceTextureListener
    • 2a4e9bf2 - WIP

    Compare with previous version

  • added 8 commits

    • d6bdd29b - android: add SurfaceTextureListener java wrapper
    • f5170249 - src/Makefile.am: add support for android java build
    • 3c659166 - extras/package: add build script for android
    • e1145bc7 - fixup! android: utils: setup Handler for SurfaceTextureListener
    • e2e56677 - WIP
    • 5c232482 - fixup! configure.ac: add support for android java build
    • 206d9e2b - Fixup previous configuration
    • 3fdd835c - WIP

    Compare with previous version

  • mentioned in merge request libvlcjni!111 (merged)

  • Alexandre Janniaux mentioned in merge request !6233

    mentioned in merge request !6233

  • Please register or sign in to reply
    Loading