NordicSemiconductor/Android-nRF-Connect-Device-Manager

[Request] Keep the resulting byte-code of the generated .aars and .jars Java11-compliant in terms of byte-code so as to make them friendly towards the "Classic Xamarin" (mono) C# java-bindings toolchain

ksidirop-laerdal opened this issue ยท 7 comments

I've explained the issue we're facing here:

#75 (comment)

In my team we created C# nugets that rely on java-bindings under the surface to interact with Nordic BLE devices. Up to version 1.5.1 of your libs everything was working smoothly. In the recent months however something changed in your libs in regard to how the 'sealed' classes are being employed:

https://github.com/search?q=repo%3ANordicSemiconductor%2FAndroid-nRF-Connect-Device-Manager%20sealed&type=code

When we upgraded the underlying java libs to version 1.7.2 we realized that even though our nuget packages where getting properly built (without any errors), when we tried to install+build "Classic Xamarin" apps for Android we would get a build-error like this one:

image

From what I've gathered in so far (and I could be wrong about some details - but the general idea seems to be correct) when the java libs got updated to use gradle 8.x+ in commit cab13d6 (30/06/2023) this caused the entire build system of the project to automatically switch gears over to JDK17+ and in the same vein the source + target compatibility for byte code was upgraded to version 17:

    classpath 'com.android.tools.build:gradle:8.0.2'

    compileOptions {
          sourceCompatibility JavaVersion.VERSION_17   <---
          targetCompatibility JavaVersion.VERSION_17    <---
    }

Before this the generated java-libs where Java11-compatible in terms of the generated byte code. After the gear switch however the projects became incompatible with Java11 bytecode thus leading to the error observed above.

There might be a simple solution to this problem: We can keep the generated java .aar and .jar compatible with Java11 per

https://stackoverflow.com/questions/73453524/what-is-causing-this-error-com-android-tools-r8-internal-nc-sealed-classes-are

I will look deeper into this and keep you updated. Keep up the good work.

I have created the following pull-request to resolve this issue:

#114

With these changes the resulting .aar files now load and run just fine again in our "Classic Xamarin/Android" applications.

@philips77

Merged. I hope it will work for you. I'm releasing 1.8.0 now.

@philips77 Much appreciated. Will test things out asap and let you know how it panned out with the official .aars. Keep up the good work.

I'll be releasing a bug-fixing version soon. If you find any issues, we may release another one any time.

I'll be releasing a bug-fixing version soon. If you find any issues, we may release another one any time.

All our tests are green with 1.8.0 - again highly appreciated. Be safe.

1.8.1 is greener.

1.8.1 is greener.

Appreciate bringing this on our radar - testing it out asap and keeping you posted.

Update: Everything works flawlessly on our end. Keep up the good work!