Create Android distribution

[ALRubinger]

@michaelneale has been trailblazing to validate tbdex-kt (and by extension, web5-kt), for Android apps in https://github.com/TBD54566975/tbdex-android-example.

This uncovers a few things we can do to make these libraries more consumable by Android devs:

• Uplevel the AndroidKeyManager into web5-kt (see dep Migrate AndroidKeyManager to web5-kt #250 below)
• Remove exclusions an Android app developer would need to make so that this runs in the Android runtime environment (ie. here and here)
• Create a single-dependency distro specifically for Android to get all the dependencies correctly

Dependencies of this issue:

• Migrate AndroidKeyManager to web5-kt #250
• Add Maven Build #217 (We will implement in the new build after tbDEX 1.0 is feature-complete as to not interrupt that work)

To preflight this approach with @jiyoontbd to her +1 before cracking work.

[jiyoonie9]

upleveling androidkeymanager is a dupe of an existing ticket #250

[ALRubinger]

Ah thanks @jiyoontbd - updating ticket description

[ALRubinger]

OK, I've done some research and there's 2 approaches we can take here:

1. Align the Android Distribution (and AndroidKeyManager impl Migrate AndroidKeyManager to web5-kt #250) with the web5-kt release cycle and use the existing Maven build. This is going to involve nonstandard and custom build approaches. The Android Platform library is not itself OSS and is installed on developer machines when installing Android Studio. All Android library and applications are intended to be built with a Gradle plugin which makes these binaries available on the build classpath. We'd have to make a custom Maven plugin to handle this; all references I could find to a Maven plugin for this already in the ecosystem haven't been released in 5 years (https://simpligility.github.io/android-maven-plugin/).

2. Make a separate repo and release cycle for web5-android, which depends upon web5-kt. That one could have a Gradle build and is where we would house the Android distribution and the AndroidKeyManager impl. It'd be done using the industry standard practices for building Android applications using defacto standard ecosystem approaches and plugins on Gradle.

Because of alignment with the greater Android ecosystem, I propose we go with 2. This comes at the expense of when we make a web5-kt release, we'll also have to upgrade web5-android and release that as well as part of our Release Process.

Project leads, what say you?

cc: @jiyoontbd @mistermoe @michaelneale @leordev

[mistermoe]

@ALRubinger what are the downsides of including a build.gradle in this repo and including the android release as part of this repo's release pipeline?

[ALRubinger]

@mistermoe I'd hoped to do that, but:

The Gradle build would then be triggered by the Maven build, and the two are not the same. So the Gradle build for Android would not be picking up the components built by the Maven main build. For example:

• We start main build in Maven
• dids, vc, etc is built
• Android packages with Gradle build are triggered
• Android packages don't see the latest from dids and vc modules because they're not part of that Gradle build and haven't been installed locally or released yet

Unless you're seeing a solution for this I'm missing?

[mistermoe]

ah because we need to reference the version bumped dids and vc etc. that were just built in the maven step?

[ALRubinger]

@mistermoe Yes.

[jiyoonie9]

cc @nitro-neal as he's onboarding as kotlin dri

what you recommend (option 2) sounds reasonable to me @ALRubinger !

[jiyoonie9]

re: what we did with awskeymanager #327 - would option 2 mean we take the same approach for androidkeymanager?

[frankhinek]

@ALRubinger @nitro-neal @jiyoontbd Good topic to discuss in the context of the Rust Core initiative and our priorities for the Kotlin SDKs for the next month.

[ALRubinger]

re: what we did with awskeymanager #327 - would option 2 mean we take the same approach for androidkeymanager?

Structurally different; AwsKeyManager could live as a new module in the existing Maven multimodule build, so same build system, same release cycle.

Option 2 proposes another repo depending on web5-kt so that it can bring in the Android deps via Gradle.

[michaelneale]

perhaps one short term thing is to document how to do a key manager in android and let people copy/paste inline to their code if simple enough? (longer term - yeah kotlin SDK priorities)

[ALRubinger]

re: what we did with awskeymanager #327 - would option 2 mean we take the same approach for androidkeymanager?

With AwsKeyManager we made a module in web5-kt. For Option 2, we'd be making a new repo on a different release cycle. This is so that we could do things The Android Way and in a Gradle build system. So web5-android would have that AndroidKeyManager and distribution, and it'd depend on web5-kt.

With leads advising their preferred direction for this I can get the work done.