Do library projects support prebuilt native libraries? When I try to put .so files into src/*/jniLibs of my library project, they do not get packaged into library's aar.
With app projects everything works fine. Thanks! On Saturday, December 28, 2013 1:42:11 AM UTC+3, Mario Zechner wrote: > > 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]>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.
