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/
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
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With