Android mergeDexRelease task fails

[wasnotrice]

This is the first time I've tried building a signed Android AAB since I updated from crux_core 0.4.0 to 0.6.0, and it seems like something broke in the typegen. I'm no longer able to build signed release AABs, although debug builds still work as expected.

I'm getting this error in the :app:mergeDexRelease task, even after cleaning the project (removing the build directories in question):

Type com.novi.serde.ArrayLen is defined multiple times: /Users/eric/code/my_project/android/shared/build/.transforms/f9ef25802a86e432ac275520f2e2daf4/transformed/release/com/novi/serde/ArrayLen.dex, /Users/eric/code/my_project/android/app/build/intermediates/external_libs_dex/release/mergeExtDexRelease/classes3.dex

I've never seen something like this before, and I'm not sure what to make of it. I do see entries in both of these places, but it looks like this is only failing on ArrayLen because it's the first one—every type is defined in both of these places. Any ideas what might be causing this?

[wasnotrice]

I thought this might have been related to the fact that I started using register_app(), but I went back to the "old" way of registering types and still get the error.

[wasnotrice]

Some more information on this. I reverted to crux_core 0.4.0 and building a signed AAB succeeds again (took a while because I had to remove all of the float values in my events 😅).

I noticed that, in 0.4.0, I have only these directories

android/shared/src/main/java/com/my_project/shared
android/shared/src/main/java/com/my_project/shared_types

whereas in 0.6.0 I have

android/shared/src/main/java/com/novi
android/shared/src/main/java/com/my_project/shared
android/shared/src/main/java/com/my_project/shared_types

That extra novi directory seems to be causing the AAB build issue.

[StuartHarris]

Hi @wasnotrice — thanks for reporting this, and apologies. It looks like we are including it twice as the new type generation includes the serialization library. Can you try removing the following lines from your app/build.gradle:

    implementation('com.diem:client-sdk-java:1.0.5') {
        exclude group: 'org.bouncycastle', module: 'bcprov-jdk15to18'
    }

I modified the master branch accordingly here

[wasnotrice]

@StuartHarris thanks for looking at this issue. That does seem like the solution, but after removing the diem client sdk entry from my app/build.gradle I still get the same error. I did the sync, clean, rebuild, package dance many many times to be sure I didn't have stale build files around, but no luck so far.

Removing the diem client sdk entry from shared/build.gradle causes the build to fail immediately as expected (can't find bcs).

If I build an unsigned bundle, it seems to work ok, it's just the signed bundle (the important one) that fails.

[StuartHarris]

The diem dependency is not in twice by any chance? I think the example had it in both app/build.gradle and shared/build.gradle. We shouldn't need any external dependencies (for serialisation) since v0.5. I'll definitely take another look though and try to build a signed release as well (although I can't do it today unfortunately)

[StuartHarris]

Sorry just read that again. It shouldn't be looking for bcs since v0.5, only bincode which it should have already.

[wasnotrice]

@StuartHarris thanks for looking at this. I wasn't able to get to it yesterday either 😄 I also realize it's hard to diagnose this issue from a distance.

I did have the diem dependency in both app/build.gradle and shared/build.gradle. Removing it from app/build.gradle doesn't seem to do anything (same error). Removing it from shared/build.gradle caused the compilation error. But I see what you're saying, we shouldn't be looking for bcs anymore. It's possible I mistyped that in the comment. I'll have to get back on that branch and work through the build again.

But I'll work from the understanding that we shouldn't need any diem entry in either gradle file.

[wasnotrice]

@StuartHarris sorry it took so long to get back to this. Removing all gradle references to the diem library works 🎉

I had some stale .java files in my build directory (because of #108), that's why they were failing with a bcs error, even though we shouldn't have been using bcs. Once I got the stale files cleaned out, then the build worked again.

Closing now, thanks for the help!