This is fixed internally and will be part of the next release.
On Wed, Jan 8, 2014 at 5:18 AM, Per Christian Henden <[email protected]>wrote: > I have the same behaviour with 0.7.3. > APKs are packaged with the jniLibs/*/*.so files, but AARs aren't. > > A workaround is to copy the .so files into > build/bundles/<variant>/libs/<abi>/, before the library is packaged. Then > they are included. > > kl. 16:36:48 UTC+1 tirsdag 7. januar 2014 skrev Anton Rutkevich følgende: > >> 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. > -- 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.
