Nothing is final until 1.0. I'm finalizing some thing before documenting
the first NDK integration and asking for feedback, but basically you'll
have:

src/*/jni can contain code and this gets compiled. This works in apps and
library projects.
src/*/jniLibs can contains prebuilt libraries. There should be an ABI
folder in there and then the .so files. Similar to your artifact/libs/...
example.

When a library project compiles native code, this gets packaged in the aar
in the jni folder like you mentioned and this gets packaged in the apps
using the library.

Most of this is present in 0.7.0 and 0.7.1, except for the jniLibs folder
which has been checked in our source tree already (yesterday by me). It'll
be done pushed with 0.7.2. Hopefully this thursday (I'm supposed to be on
holiday the whole week...)

We did intend to document things with 0.7 but we realized a few things
where missing (also it requires NDK r9c which ended up being released a few
days after 0.7), which is why we're waiting until 0.7.2 to officially talk
about it.


On Tue, Dec 24, 2013 at 2:23 AM, Mario Zechner <[email protected]>wrote:

> Hi,
>
> what is (will be) the default way to include precompiled native shared
> libraries in a Gradle build? It appears that the current NDK/native support
> is tailored towards cases where the native code is compiled locally on
> every build. There isn't any official documentation on how to integrate
> native libraries from 3rd parties, which is a common use case as well.
>
> we had a working "solution" up until 0.7 that would depend on standard
> Maven artifacts which contain the shared libraries, e.g
>
>    artifact
>       -> libs/
>          -> armeabi/
>              -> libxxx.so
>          -> armeabi-v7a/
>              -> libxxx.so
>
> and so on. We'd then depend on that artifact in the Android project's
> Gradle build, with an additional task that extracts the contents of the
> artifact to the local libs/ folder (yes, it's that bad...). This no longer
> works.
>
> After searching the web and getting some feedback from users, it appears
> that the new way of doing things is to publish an .aar to the Maven
> repository which has a new layout:
>
>
>    artifact.aar
>       -> AndroidManifest.xml
>       -> jni/armeabi/
>          -> libxxx.so
>       -> jni/armeabi-v7a
>          -> libxxx.so
>
> Is this the "final form" for including native shared libs?
>
> I understand that the dev tool team is overwhelmed with work, especially
> with battling Gradle itself. But it would be really awesome if such changes
> where documented in some way. A more detailed change log would go a long
> way. The information above could only be found when reading through
> comments on a Google+ post.
>
> Thanks,
> Mario
>
> --
> You received this message because you are subscribed to the Google Groups
> "adt-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to