Getting Started Path and Streamlined Flow for Android + Java

[GregoryComer]

🚀 The feature, motivation and pitch

Many, if not most, Android developers will want to interface with ExecuTorch through Java, rather than C++ code. We see this semi-frequently with issues reported against the framework. For users not already familiar with C++ or not doing Android native development, integrating ET via C++ can be a sizable barrier to adoption.

We have support for Java and Android-specific bindings, as well as pre-built .aar binaries for Android users, however these may not be discoverable for new users, and I also believe we can continue to invest in this area to make consuming ET via Android/Java a first-class feature.

Specifically, I'd envision the following:

1. Android developers have a dedicated, Java-first getting started experience and documentation flow. It will convey all the information a user needs to integrate ET into an existing Java or Kotlin Android app. They won't need to read any C++ focused documentation to integrate the framework for standard use cases.
2. Android developers don't need to clone the repository or build from source for common use cases. They should be able to use standard package management through Maven/Gradle to acquire the library, and can use pip to install the Python components.
3. The Java API surface has parity with native, to the extent possible.

To accomplish this, I'd propose the following:

1. Create a dedicated, top-level getting started path for Android development in the ExecuTorch docs. The entry point will be a "Getting Started with ExecuTorch on Android" under the top-level "Getting Started" section. Amend other top-level getting introduction / started documentation to guide Android developers to this page.
   a) All code snippets that the user needs to integrate with the framework should be representable in-line in the Getting Started page.
   b) The focus should be on integrating ET into an existing Android app. Our demo apps are good as a supplemental reference, but not necessarily the best way to introduce the framework or help users get started.
2. Document the Java API surface.
3. Publish prebuilt Android binaries to the Maven Central Repository, such that users can add the library to their app using standard Maven/Gradle tooling.
4. Update the ExecuTorch README to explicitly mention Android support and Java language bindings.
5. Continue to invest in the Java bindings to achieve parity with native, to the extent possible. That includes exposing result values and error handling, log routing, profiling, and any other features users may require for common use cases.
6. Create a script or path for users to easily re-build the ET Android binaries from source, in a manner that is drop-in with pre-builts. It should be easy to start with pre-builts, and then drop-in a from-source build if the user needs to change backends, log level, profiling, etc.

This should have the effect of making the framework much easier to adopt for Android developers, which make up a sizable portion of our users.

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

cc @kirklandsign @mergennachin @byjlw

[mergennachin]

Java bindings for Module.h and Tensor.h are good starters

[mergennachin]

@GregoryComer - can you also point specific issues developers face? And also can you lay the current state of documentations and how the user journey looks like for Android developers?

[orionr]

Is this the equivalent of @mergennachin 's work for iOS at #7903 by any chance? Just checking