Our chipset vendor gives a drop of the Android platform with hundreds of useless modules. Some are included using LOCAL_MODULE_TAGS := optional debug but I don't want this module to show up in any build at all. Some are included by doing PRODUCT_PACKAGES += junk-app. I could go through all the Android.mk files one at a time cleaning this stuff up but that is tiresome and problematic for merging if the vendor gives us a new drop.
I can use LOCAL_OVERRIDES_PACKAGES to get rid of the PRODUCT_PACKAGES but that doesn't work on shared libraries saved to /system/vendor/bin or prebuilt files that are copied in /system/etc/.
The ones with LOCAL_MODULE_TAGS set to values that include eng or debug are the most annoying.
So there doesn't seem to be any silver bullet, here was my strategy:
Remove the debug and eng tags from the LOCAL_MODULE_TAGS in a bunch of makefiles (tedious but no other obvious choice)
Use ifneq ($(TARGET_VENDOR), mycompany) to get rid of things added to PRODUCT_PACKAGES
Related
I am trying to gradually stripe AOSP out of its default apps. But I wonder if the method I am going to apply is correct and is the most effective.
After looking through ways of doing that I have come to the following method:(example app - "package_name")
1. Pick particular app and find out its "LOCAL_PACKAGE_NAME"
2. Use "envsetup.sh" provided command "mgrep package_name"
3. Look at the output to determine where package_name is mentioned
4. Remove lines of code containing package_name from makefiles
I have also stumbled upon this solution:
Instead of modifying bunch of .mk files in AOSP in many folders, you
can add a new module, a stub, and disable modules in its
Android.mk using LOCAL_OVERRIDES_PACKAGES. If a module still appear in
target, you'll probably need to add to LOCAL_OVERRIDES_PACKAGES
another modules which added undesired packages via
LOCAL_REQUIRED_MODULES.
But sadly I am not aware yet how one builds a new "module, a stub" so I can't apply this method as of now.
Are there any steps I can take to make sure a particular app is removed from my build completely without harming anything. What do you think is the most elegant solution to this specific task if there is one? What(literature/docs/website)would be useful for me to get familiar with making "scratch-surface" changes to AOSP code like the abovementioned case?
If that matters what I am trying to remove at the moment: Calculator; Calendar; Camera; Clock; Contacts; Files; Gallery; Messaging; Music; Phone; Search; WebView
Thanks in advance for your responses!
You can override unwanted modules with an phony module.
1, define an phony module and override unwanted modules
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
UNWANTED_OVERRIDE_PACKAGES := \
watchhome \
all_your_unwanted_pacakge \
each_pacakge_one_line
LOCAL_MODULE := override_packages
LOCAL_MODULE_TAGS := optional
PACKAGES.$(LOCAL_MODULE).OVERRIDES := $(strip $(UNWANTED_OVERRIDE_PACKAGES))
include $(BUILD_PHONY_PACKAGE)
https://gist.github.com/auxor/6e363e56eb1af430bfee8fe01916e4df
2, include phony module in your device.mk
PRODUCT_PACKAGES += override_packages
This is most clean way to override modules without modifing build/target/
Remove Packages
Ideally, you would update your device configuration to not include these packages at all.
You probably have a .mk file in your device/ directory that looks similar to this:
# Common product definition.
$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_x86_64.mk)
# Your device extensions.
$(call inherit-product, device/<company>/<device>/device.mk)
PRODUCT_NAME := my_x86_64
PRODUCT_DEVICE := x86_64
PRODUCT_BRAND := Android
PRODUCT_MODEL := My x86_64 Android Product
All default packages have - indirectly - been added by the common product definition aosp_x86_64. You can switch to one that does not have Calculator, Calendar, Camera and so on in its PRODUCT_PACKAGES list, like $(SRC_TARGET_DIR)/product/core_minimal.mk
Replace Packages
If you, for whatever reason can't change your device configuration you can override these packages with shallow ones.
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_PACKAGE_NAME := CalculatorOverride
LOCAL_OVERRIDES_PACKAGES := ExactCalculator
LOCAL_SDK_VERSION := current
include $(BUILD_PACKAGE)
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.calculator_override">
<application/>
</manifest>
You have to add your package to the PRODUCT_PACKAGES list in your device configuration. If you have already started your device before, the Calculator app will already have been installed. Clear the /data partition in that case.
This solution has the flaw that you do not really remove the apps, but replace them with other apps that are just not working.
Temporary Hack
If you don't care about making temporary changes in AOSP repositories, the fastest way to test what happens if you remove these apps is altering the list in build/target/product/core.mk. At least this list is likely to be the one your device configuration is currently using.
If you follow your first approach, changing the module definition of the installed apps, you will have the same problem that you made changes to AOSP repositories, just in many more places.
Your best source of information is probably source.android.com. There are some books, but I haven't yet seen one that incorporates the profound changes Android introduced with Treble.
I am getting this error: unable to lookup library path for, native render plugin support disabled when I run my app on android. I think I am building the shared libraries incorrectly.
I am looking to build the source files from this repo. I'll say my build process and perhaps someone can spot a step I'm missing or doing incorrect.
Following this guide, I came up with this:
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libhydrogen
LOCAL_SRC_FILES := ..\hydrogen.c
include $(BUILD_SHARED_LIBRARY)
Application.mk
APP_PLATFORM := android-16
APP_OPTIM := release
APP_MODULES := libhydrogen
Next I:
Placed these files in the jni folder.
Called ndk-build.
Copied the .so files from the \libs folder and placed them in their respective folders in Unity (i.e. Hydrogen\Plugins\Android\arm64-v8a).
Made sure their platforms and CPU architectures were correct.
Built my app.
Here is the c# wrapper I am using.
Calling Hydrogen.Library.Initialize(); is then giving me this error.
Here is the full logcat related to this error.
And in the case my build process manages to be correct, and the .so files are fine; what else might cause this to happen?
Edit: I am trying to build for armeabi-v7a and `x86. Here are the .so file details, maybe there is something there that is not right? I am unfamiliar with c and since I haven't heard of anyone building this library for android, I wonder: could there be anything within the c source file that is incompatible with the NDK build process?
Native libraries are loaded by the native linker of the system, in your case, the linux dynamic linker: ld.so (it changes names sometimes, so I used that name, as you can check the man page in the documentation with that name).
For that to happen, in general, you need to provide a LD_LIBRARY_PATH environment variable to the java virtual machine, so it can effectively dlopen(3) it.
Think how different can be your development system to your target one.... and you'll easily get to that.
It was a bug with Unity! For some reason when switching the project's target platform some of my files would get corrupted. Strangely, it only seems to happen in this one project, but in any case the (temporary) solution is to re-import the plugin folder whenever I switch platforms.
I have started developing a very simple Android application that consists of three parts:
the Java application itself
a pre-built shared library (we'll call it libfoo)
another shared library that uses the pre-built library (we'll call it libfoowrapper)
The file system looks something like this:
jni
Android.mk
libfoo.so
foowrapper.c
The Android.mk file contains the following contents:
LOCAL_PATH := $(call my-dir)
#==============================
include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := libfoo.so
include $(PREBUILT_SHARED_LIBRARY)
#=========================
include $(CLEAR_VARS)
LOCAL_MODULE := foowrapper
LOCAL_SRC_FILES := foowrapper.c
LOCAL_SHARED_LIBRARIES := foo-prebuilt
include $(BUILD_SHARED_LIBRARY)
When I build the application in Eclipse, things seem to work fine - no errors are reported. However, when I upload the application to my Samsung Discover (running Android 4.0.4), I get the following error in the log:
03-05 21:20:27.859: E/AndroidRuntime(20324): Caused by: java.lang.UnsatisfiedLinkError: Cannot load library: link_image[1936]: 102 could not load needed library 'libfoo.so.0' for 'libfoowrapper.so' (load_library[1091]: Library 'libfoo.so.0' not found)
Why is the Dalvik looking for a .so.0 file instead of a .so file? What changes do I need to make to my app to get rid of this error?
At least in the Linux world, every shared library has a special name called the soname. The soname has the prefix lib, the name of the library, the phrase .so, followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don't start with lib). A fully-qualified soname includes as a prefix the directory it's in; on a working system a fully-qualified soname is simply a symbolic link to the shared library's real name.
Every shared library also has a real name, which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number. The last period and release number are optional. The minor number and release number support configuration control by letting you know exactly what version(s) of the library are installed. Note that these numbers might not be the same as the numbers used to describe the library in documentation, although that does make things easier.
Reference: Linux Standard Base
Edit:
It seems this is not an uncommon problem, haven't seen any real solutions to it, but perhaps this will get you started to finding something that works for you.
Problem with LOCAL_SRC_FILES when using PREBUILT_SHARED_LIBRARY
https://groups.google.com/forum/#!topic/android-ndk/_UhNpRJlA1k
Creating non-versioned shared libraries for android
http://www.opengis.ch/2011/11/23/creating-non-versioned-shared-libraries-for-android/
Library 'libproj.so.0' not found
https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/ai3tu0XXs88
I want to create a Player which uses Android system/lib/libmedia.so.
Directly use JNI to play a video.
In Android.mk, i add "-lmedia" for including the library, but i can't link this directly.
This is my process.
write a Cpp file which includes some header file in libmedia.so
add "-lmedia" in Android.mk of LOCAL_LDLIBS
such as..
LOCAL_LDLIBS -lmedia -lstagefright
use ndk-build to build .so
error occured!!
Does anybody have some answer to help???
libmedia.so and libsinstructionght.so are not part of the public API. This means that in theory, you should not rely on them. In practice, though, these libraries are present on all devices, but they are different.
You can extract this binary file from your device, or even from an emulator using command
adb pull /system/lib/libmedia.so C:/android-ndk/platforms/android-14/arch-arm/usr/lib
This will put ths file together with the public API so that using it with ndk-build is easier. On the other hand, you should be aware of fragmentation not lnly between different levels of Android, but also chipsets, manufacturers, and even models.
To handle this, I pull .so files from different devices into separate directories, and add one of them to the linker path, e.g.
LOCAL_LDLIBS += -Lc:/android/galaxys.4.1.2.system.lib
This instruction above can not resolve the big problem you are facing with your approach. libmedia.so is not intended to be linked to user apps. It assumes the context of a privileged user with access to protected devices, such as camera, codecs, and screen.
You can make full use of this library if you target a rooted device, or prepare a custom ROM. And know what you are doing, and how to avoid stealing essential resources from the system.
Otherwise there is very little gain in linking the media lib.
PREBUILT_SHARED_LIBRARY
Points to a build script used to specify a prebuilt shared library.
Unlike BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, the value
of LOCAL_SRC_FILES must be a single path to a prebuilt shared
library (e.g. foo/libfoo.so), instead of a source file.
You can reference the prebuilt library in another module using
the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more
information).
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := libfoo.so
include $(PREBUILT_SHARED_LIBRARY)
Refrenced from NDK documentation.
PREBUILT_STATIC_LIBRARY
This is the same as PREBUILT_SHARED_LIBRARY, but for a static library
file instead. See docs/PREBUILTS.html for more.
Please read the NDK documentation for more details.
I'm working on an Android.mk file in which, for a single module, one of the files needs different CPPFLAGS; namely, it needs -frtti enabled, while others need the Android default of -fno-rtti.
The obvious solution was target-specific variables, but oddly they do not seem to affect compilation, even with some fiddling to ensure the values should be fixed at the right time.
Here's an extract from my Android.mk (names changed to protect me):
LOCAL_MODULE := foo_bar
LOCAL_SRC_FILES := \
foo_bar.cpp \
foo_baz.cpp
my_intermediates:= $(local-intermediates-dir)/foo_baz.o
$(my_intermediates): LOCAL_CPPFLAGS := -frtti
I have tried simply doing foo_baz.o: in lieu of $(my_intermediates), and have tried substituting += for := to no change.
So, is there an Android-specific way to override CPPFLAGS (or CFLAGS) for a specific source file?
(In this case I'm using the Eclair Android sources, though it may apply to the NDK; see my answer, below.)
As is usual, having asked the question after spending a lot of time on it, I have found the answer in short order. I need to use PRIVATE_CPPFLAGS instead of LOCAL_CPPFLAGS.
However, this only appears to be the case for the Android source distribution (at least Eclair) and NDK r6b. If I was using NDK r6, this probably would have worked as it stands.
The easiest way to have different parameters for some source files is to group these files in Android.mk together to produce a static library include $(BUILD_STATIC_LIBRARY) which will then be listed in LOCAL_STATIC_LIBRARIES for the resulting shared object.