feat: Add Android platform release targets with integrated JNI support #1145
Conversation
|
Is there a reason why this needs to be done in the library instead of in external JNI connected to the C bindings? |
scouten-adobe
changed the title
| @@ -0,0 +1,477 @@ | |||
| // Copyright 2024 Adobe. All rights reserved. | |||
There was a problem hiding this comment.
Could we move this out, even to its own folder (crate)? Because since it's JNI, this could maybe be reused in the future for Java bindings which are not specific to Android (or refactored to share some code with that, if we ever have a Java SDK)?
There was a problem hiding this comment.
Happy to put it where you think it is best. I do not believe there is anything Android specific here that wouldn't also work in a generica Java/Kotlin environment.
|
|
||
| /// Returns a ManifestStore JSON string from a file path | ||
| #[no_mangle] | ||
| pub extern "system" fn Java_org_c2pa_C2PA_readFile( |
There was a problem hiding this comment.
Ack - but we should consider using readers to do that, as they are an important piece of the API surface (and it reduces the exposed API surface too, so people use the API's main concepts).
|
|
||
| /// Creates and verifies a C2paReader from an asset stream with the given format | ||
| #[no_mangle] | ||
| pub extern "system" fn Java_org_c2pa_C2PA_readerFromStream( |
There was a problem hiding this comment.
Here we have the reader - that is similar in spirit to Java_org_c2pa_C2PA_readFile, if we open the file as stream and pass it to a Reader, to finally get the manifest store as JSON.
There was a problem hiding this comment.
We are still fully getting our heads around the best practices of the 2.x API ourselves. Readers do make sense, and again, will be more inline with the Android/Kotlin/Java idiom than just raw JSON.
Also, we do plan to continue to have a "SimpleC2PA" library as well, on top of the "Full API", that even further simplifies integration for the most common and basic functions in a mobile app.
|
I will work on resolving the Makefile conflict this week. I believe that relates to the recent work of @redaranj that was merged. |
|
Regarding the failures: |
Changes in this pull request
This PR integrates support for building the C API library targeting Android ARM64 and X86_64 with the local Makefile build process.
It also integrates the RUST-JNI crate to provide a first pass of an integrated Java Native Interface (JNI) which, unlike with Swift iOS, is required for calling into the library from Kotlin or Java in the Android environment. This interface will be improved in future PRs to be more in platform style.
The Makefile changes also integrate support for installing the required Android Native Development Kit (NDK) tools for completing the build.
Checklist
TO DOitems (or similar) have been entered as GitHub issues and the link to that issue has been included in a comment.