That's great, Xavier! A variation of this scenario is aar libraries containing locally built native libs and depending on external aars containing native libs. The contents of jniLibs/ must then be propagated from all the aar dependencies and become part of the locally built aar.
In addition, Eclipse/ADT must support the new jniLibs/ folder. Otherwise I can't provide my aar with the new directory format to customers using Eclipse. kl. 05:23:57 UTC+1 torsdag 9. januar 2014 skrev Xavier Ducrohet følgende: > > 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]<javascript:> > > 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] <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.
