Minie - Problem generating Android signed bundle

Pavl_G · May 10, 2022, 3:44pm

I know, i am using old gradle for java8 compatibility…i remember uaing gradle7 and above with android gradle plugin needs java 11.

EDIT :
So, no warnings about + sign on gradle7 ?

sgold · May 10, 2022, 3:46pm

In that case, try Gradle v6.9.2, which is what the Engine is using.

EDIT:
I don’t recall seeing that warning before. Perhaps it’s specific to the SDK.

adi.barda · May 10, 2022, 4:08pm

I’m also using Gradle V6.5 and as I said - it works fine

adi.barda · May 10, 2022, 4:25pm

So it’s probably not related to Gradle version 6.5
and probably not related to the + sign

Maybe there is some kind of collision between +bare and +ano
Something is not working right (consistent) with fetching the +ano lib

By the way, we need to compile to AAB and not APK since the last one is not valid anymore on Google play store

sgold · May 10, 2022, 4:32pm

Perhaps Gradle doesn’t like having two libraries named “MInie” in the same build.

adi.barda · May 10, 2022, 4:40pm

Stephen, is it possible of you to temporary create 2 unique names for those libs:

implementation "com.github.stephengold:Minie:4.7.1+bare"
implementation "com.github.stephengold:Minie:4.7.1+ano"

without the + sign. something like:

implementation "com.github.stephengold:Minie_bare:4.7.1"
implementation "com.github.stephengold:Minie_ano:4.7.1"

So we will immediately see if this is the cause for the “collision”…

sgold · May 10, 2022, 5:16pm

it’s possible. However, publishing a custom release of MInie requires a large amount of time and effort.

I think it would be much, much easier to download both libraries to the project’s “lib” directory, rename the files locally, and build using the renamed versions—for which you’d need:

repositories {
    flatDir { dirs "${rootProject.projectDir}/lib" }
    mavenCentral()
    // ....
}

Pavl_G · May 10, 2022, 5:47pm

Alright, you can add it to the new milestone, i will open an issue and document it, take your time for the next version, may be omitting the + sign to dash :

implementation "com.github.stephengold:Minie-bare:5.x.x"
implementation "com.github.stephengold:Minie-ano:5.x.x"

The same as jme3-android and jme3-android-native module we are not on a hurry i think, @sgold thanks for supporting Minie build for android and arm devices.

EDIT :
yeah, seems gradle in some cases, reads them as different versions of a same module, so if the + sign is omitted from the version number, i guess this would fix the issue.

sgold · May 10, 2022, 6:50pm

if the + sign is omitted from the version number, i guess this would fix the issue

No guessing—please document what you’ve tested and what the results were. Once I know what works and what doesn’t, I’ll make appropriate changes.

adi.barda · May 10, 2022, 6:54pm

Sure! I will try that tomorrow and report if it fixes the problem

Pavl_G · May 10, 2022, 7:03pm

I hope everything is clear.

github.com/stephengold/Minie

Android: Problems with '+' sign in version number

opened 07:03PM - 10 May 22 UTC

Scrappers-glitch

I have tested the new `Minie-4.9.0+bare` and `Minie-4.9.0+ano` parts of Minie li…brary on android, and i found out that the bare part always replaces the ano part if both are added as dependencies, i suspect the problem comes from using '+' sign in declaring minie parts, in which gradle consumes it as a different version of minie, so a suggestion for the next release and for an eventual fix is to omit the '+' sign from minie parts and replace it by `library-module:version` classical way of defining library parts. So, this is better : ```java implementation "com.github.stephengold:Minie-bare:5.x.x" implementation "com.github.stephengold:Minie-ano:5.x.x" ``` instead of this : ```java implementation "com.github.stephengold:Minie:5.x.x+bare" implementation "com.github.stephengold:Minie:5.x.x+bare" ``` By doing this, you are actually creating different `artificatId` names under the hood under the same library.

Pavl_G · May 10, 2022, 7:33pm

@adi.barda Do you have a warning for the usage of + sign in gradle implementation ?

adi.barda · May 10, 2022, 7:46pm

Yes, I do:

Pavl_G · May 10, 2022, 7:47pm

I mean a warning about not to use the + sign ? may be after updating to 4.9.0 ?

adi.barda · May 10, 2022, 7:50pm

Yes, warning still there:

Avoid using + in version numbers; can lead to unpredictable and unrepeatable builds (com.github.stephengold:Minie:4.9.0+bare)

adi.barda · May 11, 2022, 7:16pm

EDIT:
found it:

    implementation files('libs/Minie-ano-4.9.0.jar')
    implementation files('libs/Minie-bare-4.9.0.jar')

I’m trying to test that now. What would the implementation line looks like in that case?

adi.barda · May 11, 2022, 8:32pm

Well…
I’m using jitpack and testing the following gradle build file:

github.com

scenemax3d/scenemax3d-mobile-engine/blob/main/build.gradle

repositories {
    google()
    mavenCentral()
    jcenter()
    maven { url "https://jitpack.io" }
}

buildscript {
    repositories {
        google()

        mavenCentral()
        jcenter()
        maven { url "https://jitpack.io" }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:4.1.3'
    }
}

This file has been truncated. show original

From the tests I have made I can tell that:

the combination of +bare & +ano does not get the libbulletjme.so files
putting just: implementation “com.github.stephengold:Minie:4.9.0” - works fine - gets the native .so files
I have tried to work with local files (flatdir) - it works fine with either file name but I cannot simulate the exact “problematic” file name because ‘:’ char is invalid and anyway it seems from the docs that it works differently than a maven repo so it’s probably not a valid check
using just: “com.github.stephengold:Minie:4.9.0” also works fine with generating APK / AAB
still need to check if signed AAB will also work fine
I can tell for sure that previously I had issues with using just “com.github.stephengold:Minie:x.x.x” for generating signed AAB but it was prior to version 4.9.0

Conclusion:
if “com.github.stephengold:Minie:4.9.0” will work as expected in all scenarios then I will just use it instead of the ano+bare combo
I can’t tell whether or not renaming the artifacts to not using the + sign will solve the “.so” files problem

Pavl_G · May 12, 2022, 4:28pm

Yeah, i tested Minie:4.9.0 and i also found the android native files too (without the empty file), @sgold so why doing separate parts, when the original minie still has the android native files, in my opinion, if you want to separate android natives on another module, then you should also remove them from minie module.

For Minie-4.9.0, this works fine for me too :

implementation 'com.github.stephengold:Minie:4.9.0'

EDIT :

I am sure it will work, since the empty file has disappeared now.

adi.barda · May 13, 2022, 3:59pm

Yes. Signed AAB also worked as expected. no errors

sgold · May 14, 2022, 5:58am

The default Minie library supports 13 different platforms, which is great when you just want things to simply work. It is also 16 MB, which is rather large. A major reason for creating other builds (such as “big3”, “bare”, and “ano”) was to reduce bloat.

The “ano” build was created specifically to address @adi.barda 's troubles creating signed bundles (see the early posts in this topic). I was unsure whether the difficulties were caused by placeholder files or non-Android natives, so to be safe I tried avoiding both.

I’m not willing to remove Android from the default build. However, one possibility for the next release would be to create a “Minie-android” library that combines the contents of “bare” and “ano”.

Another route I’m considering would be to drop “ano” and “big3” and publish a broad selection of native libraries as individual Maven artifacts, similar to what LWJGL does. That would provide flexibility to “mix and match” natives. For instance, to support ONLY the 4 Android platforms, you’d drop something like this into the build script:

repositories {
    mavenCentral()
}
dependencies {
    implementation 'com.github.stephengold:Minie-bare:5.0.0'
    runtimeOnly 'com.github.stephengold:Android_ARM7ReleaseSp_libbulletjme:14.6.1'
    runtimeOnly 'com.github.stephengold:Android_ARM8ReleaseSp_libbulletjme:14.6.1'
    runtimeOnly 'com.github.stephengold:Android_X86ReleaseSp_libbulletjme:14.6.1'
    runtimeOnly 'com.github.stephengold:Android_X86_64ReleaseSp_libbulletjme:14.6.1'
}

The extra flexibility would come at a cost: build scripts become cumbersome and error-prone. Note long artifact IDs and the distinct version numbers for classes and natives. I think this route leads inevitably to the creation of a configuration tool comparable to LWJGL’s in its complexity. Not a project I’d likely enjoy.