.so file in apk in the /system/app doesn't extract to the /data/data/xxx/lib directory

[Hendy]

hi all, especially to fadden

This is a additional question to this post:
http://groups.google.com/group/android-ndk/browse_thread/thread/bfceac612dceae8c/7f2b8b48a87c2a52.

Sorry for this new post. Because I replied to that post but the system
didn't show my reply.

My question is that it seems to be a designed behavior of Android.
Then how will the system APPs with .so be upgraded? If a APP wants to
upgrade itself, normally will supply a new apk file and install it
with the package installer, the upgraded so file will be placed in
the /data/data/com.xxx.xxx/lib directory. The old so in the /system/
lib directory will not be upgraded. But the so files in the system
directory have high priority to be linked. Then the old so will never
be replaced. How to solve this problem?


Thanks.

[Eurico Inocêncio]

Hi

You should never place your .so in /system/lib, or as you said it will
never be upgradable. When the initial APK is placed in /system/app the
packager manager is supposed to copy the so into
/data/data/xxx.xxx.xxx/lib. In the past found a couple of terminals
that don't always copy the .so, in those cases it was necessary to
copy the .so into /data/data/xxx.xxx.xxx/ on behalf of the package
manager, Fortunately on most terminals it works ok.

Eurico

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
>
>

[David Turner]

Note: this goes into android-porting, not android-ndk.

This works like this:

• Applications that are bundled with the system _should_ place their system libraries under /system/lib
  
  
• When an update is installed, the PackageManager will place its shared libraries under /data/data/<package-name>/lib and these will be used by the updated application. The old system library is _not_ replaced, simply ignored.
  
  
• If you uninstall the update, the original bundled application will still be here, including its system libraries.
  
  
• During the very first boot sequence (e.g. after a -wipe-data when starting the emulator, or a factory reset on a device), the system will scan for bundled applications under /system/app/<packagename>.apk, and will install them one by one.
  
  As a special exception, the PackageManager will _not_ extract shared libraries from these packages to /data/data/<package-name>/lib (this avoids duplication of the system libraries in both /system/lib and <data>/lib)

[Hendy]

Hi, David

Thanks for your explanation.

But what I see is different from your statement, with testing on both
emulator and some real phone.

First, the .so isn't extracted to the /system/lib directory
automatically during the first boot. Second, when the updated package
installed, the .so is extracted to the /data/data/xxx/lib as expected.
But the application doesn't link to this new .so but still to the old
one under /system/lib.

Has it something to do with the java library path? I found that the
"java.library.path" contains only /system/lib. I tried to add /data/
data/xxx/lib to it but taking no effect.

I have to use another solution. Use System.load instead of
System.loadLibrary and pass in the absolute path of the library.

And also thanks to Eurico. It is really weird if some terminals work
ok and some not.

On Oct 27, 2:56 am, David Turner <di...@android.com> wrote:
> Note: this goes into android-porting, not android-ndk.
>
> This works like this:
>

>    - Applications that are bundled with the system _should_ place their
>    system libraries under /system/lib
>
>    - When an update is installed, the PackageManager will place its shared

>    libraries under /data/data/<package-name>/lib and these will be used by the
>    updated application. The old system library is _not_ replaced, simply
>    ignored.
>

>    - If you uninstall the update, the original bundled application will

>    still be here, including its system libraries.
>

>    - During the very first boot sequence (e.g. after a -wipe-data when

>    starting the emulator, or a factory reset on a device), the system will scan
>    for bundled applications under /system/app/<packagename>.apk, and will
>    install them one by one.
>
>    As a special exception, the PackageManager will _not_ extract shared
>    libraries from these packages to /data/data/<package-name>/lib (this avoids
>    duplication of the system libraries in both /system/lib and <data>/lib)
>
>
>
> On Tue, Oct 26, 2010 at 2:44 AM, Hendy <hendy...@gmail.com> wrote:
> > hi all, especially to fadden
>
> > This is a additional question to this post:
>

> >http://groups.google.com/group/android-ndk/browse_thread/thread/bfcea...
> > .

>
> > Sorry for this new post. Because I replied to that post but the system
> > didn't show my reply.
>
> > My question is that it seems to be a designed behavior of Android.
> > Then how will the system APPs with .so be upgraded? If a APP wants to
> > upgrade itself, normally will supply a new apk file and install it
> > with the package installer, the upgraded so file will be placed in
> > the /data/data/com.xxx.xxx/lib directory. The old so in the /system/
> > lib directory will not be upgraded. But the so files in the system
> > directory have high priority to be linked. Then the old so will never
> > be replaced. How to solve this problem?
>
> > Thanks.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr­oups.com>
> > .

> > For more options, visit this group at

> >http://groups.google.com/group/android-ndk?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Eurico Inocêncio]

Hi Hendy, David

What I have observed in the actual devices is that sometimes the .so
is copied to /data/data/xx.xx.xx/lib, others not, in my code I detect
this and if necessary the .so is copied to /data/data/xx.xx.xx and
loaded from there using absolute path. I thought this to be normal
since /system is in a read-only partition.

Quite frankly never found a device that extracted my .so into /system/lib

Once one device manufacturer placed my .so in /system/lib on their ROM
and I ended up with a native code that could not be updated because
the loader picked the .so from /system/lib and ignored the newer
version on /data/data/xx.xx.xx/lib.

Eurico

> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[fadden]

On Oct 27, 4:24 am, Eurico Inocêncio <eurico.inocen...@gmail.com>
wrote:

> Quite frankly never found a device that extracted my .so into /system/lib

On production devices, /system is mounted read-only, so attempting to
extract a file there wouldn't make sense.

> Once one device manufacturer placed my .so in /system/lib on their ROM
> and I ended up with a native code that could not be updated because
> the loader picked the .so from /system/lib and ignored the newer
> version on /data/data/xx.xx.xx/lib.

This behavior has been fixed for an upcoming Android release. The app-
specific lib directory now comes at the start of the path list rather
than the end.

[Hendy]

Got it. Thank you all!

[David Turner]

On Wed, Oct 27, 2010 at 2:25 AM, Hendy <hend...@gmail.com> wrote:

Hi, David

Thanks for your explanation.

But what I see is different from your statement, with testing on both
emulator and some real phone.

First, the .so isn't extracted to the /system/lib directory
automatically during the first boot.

I never said, quite the contrary, please read my post. What I said was that the libraries

had to be placed under /system/lib, which is done when building the system image, not at boot time.

 

Second, when the updated package
installed, the .so is extracted to the /data/data/xxx/lib as expected.
But the application doesn't link to this new .so but still to the old
one under /system/lib.

Apparently, this is a bug. I thought it had been fixed in Froyo, but I was probably mistaken.

 

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[David Turner]

On Wed, Oct 27, 2010 at 8:11 PM, David Turner <di...@android.com> wrote:

On Wed, Oct 27, 2010 at 2:25 AM, Hendy <hend...@gmail.com> wrote:

Hi, David

Thanks for your explanation.

But what I see is different from your statement, with testing on both
emulator and some real phone.

First, the .so isn't extracted to the /system/lib directory
automatically during the first boot.

I never said, quite the contrary, please read my post. What I said was that the libraries

had to be placed under /system/lib, which is done when building the system image, not at boot time.

 

Second, when the updated package
installed, the .so is extracted to the /data/data/xxx/lib as expected.
But the application doesn't link to this new .so but still to the old
one under /system/lib.

Apparently, this is a bug. I thought it had been fixed in Froyo, but I was probably mistaken.

 

You can probably route around this by using a different library name for your updated library (e.g. libfoo2.so instead of libfoo.so). I know it's not elegant, but it should work.

[Eurico Inocêncio]

Hi

>> Quite frankly never found a device that extracted my .so into /system/lib
>
> On production devices, /system is mounted read-only, so attempting to
> extract a file there wouldn't make sense.
>

Precisely that's why on 1st boot the .so is extracted from
/system/app/xxx.apk into /data/data/xxx.xxx.xxx/lib
and not into /system/lib (well most times, there are buggy devices out there)

Eurico

[Chris Stratton]

On Oct 28, 2:51 am, Eurico Inocêncio <eurico.inocen...@gmail.com>
wrote:

No.

The .so's for apps placed in /system/app by the rom author or
update.zip should be included in /system/lib by the rom author or
update.zip