Awesome, i'll give 0.7.2 a try. You should get of the internet and enjoy your vaccation!
On Tuesday, December 24, 2013 9:49:37 PM UTC+1, Xavier Ducrohet wrote: > > 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]<javascript:> > > 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] <javascript:>. >> 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.
