If an app exposes new/delete from a shared library, the libwilhelm
shared library can wind up using the new from the app shared library,
and the delete from libc++. It is completely legal for the app to
export new/delete in this way, so in order to avoid this situation,
preload libwilhelm in the zygote. This forces libwilhelm to always
resolve the new/delete from libc++.
This library cannot be added to android_runtime since libwilhelm
has a shared library which depends on android_runtime.
Bug: 21032018
Change-Id: Id89c196df62d98d62855a1421f397b75a7e990a9
Build both 32 and 64-bit versions and don't limit it to eng.
Change-Id: I5d6cc8005291100d5fe0f1385e8a0b4ba5f4d630
(cherry picked from commit e740b17d2400ed0db17d1f7fce4f052bbbf808ab)
Use LOCAL_WHOLE_STATIC_LIBRARIES to instruct static linker
to export symbols from the static library.
Change-Id: I465806dcffc777a682523f74ae6f7ab61aaa6962
Change app_process to be a symlink to the primary version
and have app_process32/app_process64 be the 32-bit/64-bit
versions respectively.
This will make it possible to use the primary zygote for
am/pm commands and other scripts that use app_process and
don't need a specific zygote.
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Change-Id: Ibef545994eb95ddc82101c95df613ad1d06345e6
Use LOCAL_MULTILIB := both to build app_process64 instead of
duplicating the build rule.
Also causes PRODUCT_PACKAGES := app_process to install both
versions on 64-bit platforms, as the module names for both
app_process and app_process64 are now app_process.
Change-Id: Ia3c3265d15475771b0cae8bace53b8fbf351c186
On 64-bit platforms builds two copies of app_process, the 32-bit
app_process and 64-bit app_process64.
Change-Id: I59d739b5df398ad0bd040c954c57640ff7ab3e72
executables have calls to some shared libraries without explicitly linking
them. Currently it works as linker links these libraries via dependencies of
other libraries. This is fragile and not the right thing to do.
