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.

Reply via email to