Loading two instances of a shared library.

[Owen Hogarth II]

Loading two instances of a shared library with android ndk
I am using a shared library for an android app, that part works very
well since there's only ever one instance of the shared library loaded
in memory.

I want to adapt this to work as a live wallpaper but now I am running
into problems because as you know livewallpapers can have up to two
instances open at the same time.

Is it possible to use dlopen to load multiple instances of the shared
library to avoid collisions? In the livewallpaper there's a
isPreview() that returns true or false, I can use that flag to load
either the default or an alternate version of my shared library.

I wrote a wrapper lib that gets loaded when the android WallpaperService.Engine is created, can I use that wrapper lib to use dlopen to open two different instances of the shared library?

[J Decker]

No.
If they had two different names sure.
cat /proc/self/maps
if it's loaded in a separate process, yes.

>
> --
> You received this message because you are subscribed to the Google Groups
> "android-ndk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-ndk...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-ndk.
> For more options, visit https://groups.google.com/d/optout.

[Owen Hogarth II]

Currently things work fine as an activity because there's only ever one instance of the shared library loaded. The shared library has a thread and some global variables that are out of my control.

This is a wallpaperservice/ wallpaperservice.engine;

I can get either the preview to work fine or setting the wallpaper to work fine but if the wallpaper is set and I go to the preview, it all crashes.

what are some options that I could try? I've even looked at dlopen but android doesn't seem to support the flags necessary to load shared libraries in a private manner.

[Owen Hogarth II]

Here is the proc map before attempting to load the service

40052000-40053000 r--p 00000000 00:00 0 

4008d000-4009e000 r--s 00000000 00:0b 3079       /dev/__properties__

400aa000-400cf000 r-xp 00000000 b3:09 497        /system/bin/mksh

400cf000-400d0000 r--p 00000000 00:00 0 

400d0000-400d1000 r--p 00025000 b3:09 497        /system/bin/mksh

400d1000-400d2000 rw-p 00026000 b3:09 497        /system/bin/mksh

400d2000-400d6000 rw-p 00000000 00:00 0 

4015c000-401a2000 r-xp 00000000 b3:09 1362       /system/lib/libc.so

401a2000-401a4000 r--p 00045000 b3:09 1362       /system/lib/libc.so

401a4000-401a6000 rw-p 00047000 b3:09 1362       /system/lib/libc.so

401a6000-401b4000 rw-p 00000000 00:00 0 

401c3000-401d2000 r-xp 00000000 b3:09 477        /system/bin/linker

401d2000-401d3000 r--p 0000e000 b3:09 477        /system/bin/linker

401d3000-401d4000 rw-p 0000f000 b3:09 477        /system/bin/linker

401d4000-401d5000 rw-p 00000000 00:00 0 

41300000-41307000 rw-p 00000000 00:00 0          [heap]

bed6a000-bed8b000 rw-p 00000000 00:00 0          [stack]

ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]

here's the map after loading the preview

40064000-40075000 r--s 00000000 00:0b 3079       /dev/__properties__

4008b000-4008c000 r--p 00000000 00:00 0 

400a7000-400a8000 r--p 00000000 00:00 0 

400de000-40103000 r-xp 00000000 b3:09 497        /system/bin/mksh

40104000-40105000 r--p 00025000 b3:09 497        /system/bin/mksh

40105000-40106000 rw-p 00026000 b3:09 497        /system/bin/mksh

40106000-4010a000 rw-p 00000000 00:00 0 

40184000-40193000 r-xp 00000000 b3:09 477        /system/bin/linker

40193000-40194000 r--p 0000e000 b3:09 477        /system/bin/linker

40194000-40195000 rw-p 0000f000 b3:09 477        /system/bin/linker

40195000-40196000 rw-p 00000000 00:00 0 

4025f000-402a5000 r-xp 00000000 b3:09 1362       /system/lib/libc.so

402a5000-402a7000 r--p 00045000 b3:09 1362       /system/lib/libc.so

402a7000-402a9000 rw-p 00047000 b3:09 1362       /system/lib/libc.so

402a9000-402b7000 rw-p 00000000 00:00 0 

4079a000-407a1000 rw-p 00000000 00:00 0          [heap]

be8cf000-be8f0000 rw-p 00000000 00:00 0          [stack]

ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]

On Sunday, September 27, 2015 at 12:15:17 AM UTC+8, J Decker wrote: