I'm building a version of the AOSP for custom hardware and I'd like to use some root permissions (INJECT_EVENTS, UPDATE_DEVICE_STATS, CONNECTIVITY_INTERNAL).
For rev control, it would be ideal to use an APK-based distribution. As such, I'd like to include the APK in the build instead of building the source every time. The program gets successfully included, but the system privileges are ignored.
Is there a way to include this program such that it receives the necessary privileges? I'm hoping there is some connection that either LOCAL_CERTIFICATE, LOCAL_MODULE_CLASS or BUILD_PREBUILT in Android.mk can achieve.
EDIT:
The solution was to first determine the signatures that were being used to build the Android system. They existed in /build/target/product/security/platform inside the AOSP. Once I had these signatures, I could then create a new keystore. I then imported the keys into the new keystore using the tool keytool-importkeypair found here.
https://github.com/getfatday/keytool-importkeypair
Once that was done, I could select the keystore inside Android Studio and correctly install and debug the program that had the necessary permissions.
Here is what I have: my application is a system application which I develop using Android Studio. When I want to include it in my ROM, here are the steps:
Export the app as an unsigned apk from Android Studio
Place the apk in packages/apps/your_app folder
Use the Android.mk like this:
.
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE := your_app
LOCAL_CERTIFICATE := platform
LOCAL_PRIVILEGED_MODULE := true // if required
LOCAL_MODULE_CLASS := APPS
LOCAL_SRC_FILES := app-release-unsigned.apk
include $(BUILD_PREBUILT)
In addition to this, you can also generate keystore file from the platform certificates. You can google that, it involves several shell commands (I use the same approach) and then you can run your app on your device from Android Studio with appropriate signing configuration.
So you are making a custom Android build, just need to put your app source in the same directory level with other system apps, such as Phone, Messages, Calendar ... then it will eventually be built and generated as a system app, which will stay in /system/app after burning the image to the hardware.
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 am looking to add a prebuilt APK to my AOSP build. I can already do this by doing the following:
Add the APK to the $root_of_my_source_tree/packages/apps folder.
Create an Android.mk file. The file has the following contents:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE := <name of APK>
LOCAL_SRC_FILES := <Name of APK>.apk
LOCAL_MODULE_CLASS := APPS
LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
LOCAL_CERTIFICATE := platform
include $(BUILD_PREBUILT)
Add:
PRODUCT_PACKAGES += \ <name of APK>
To a make file that gets picked up by the AOSP build system.
This adds the APK to the /system/app folder which is read-only so the user will not be able to update the APK. I would like the APK to be placed in the /data/app folder so the user can actually update the prebuilt APK.
I have tried the suggestions in this question and they did not work. I tried the suggestion in this question and while it did output the APK to the /data/app folder of the finished build, once I flashed the image onto my device, the app was not there. The second answer in that question does provide a possible explanation for this but no other suggestions.
Ultimately, I need an APK preloaded in my build that can be updated so if this doesn't work or is a bad approach, I am open to suggestions.
I found the standard behavior of the PackageManager class good enough for my use case. So here are a couple tidbits worth explaining:
Lavakush's answer does work and it does output the APK to the out/target/product/vendor/data/app folder in the source tree but the APK does not show up under /data/app in the system image once it's flashed onto a device. According to this answer, the Android build system does not build anything into /data/ so that explains that. I still find it confusing that it does show up as output in the out/target/product/vendor/data/app folder however.
In my use case, I need to preload APKs onto a build and then update them as needed. Due to the read-only nature of the /system/app folder I assumed that I would not be able to update my app which is why I wanted to preload it to /data/app. As in turns out, according to this answer & to my testing, the PackageInstaller class' standard behavior is to install the updated APK to the data/app folder and to start running this APK instead of the preloaded /system/app APK. The answer also says that the settings->apps screen will give you the option to uninstall the updated APK and then you'll be left with the original system/app APK. I did observe this behavior and it is fine for my use case.
In your Android.mk file Use LOCAL_MODULE_PATH to TARGET_OUT_DATA or TARGET_OUT_DATA_APPS
LOCAL_MODULE_PATH := $(TARGET_OUT_DATA)
------
include $(BUILD_PREBUILT)
I've created an Application that works perfectly in Android Studio. If I generate an AAR and APK and use these files they again work fine. I can install the APK on several devices and it works flawlessly. Now when I install the APK inside of an AOSP build I keep getting an java.lang.UnsatisfiedLinkError: which points to the very first line of code that's calling my native method. I used this link as a reference Add .apk files in aosp. When I run the emulator and click my application it crashes and produces that UnsatisfiedLinkError. The same thing happens if I generate an APK using my AAR file. Just to clarify again this only happens in AOSP it does not happen when using the AAR inside Android Studio doing other builds and the APK always works regardless of the device I install it on. Any advice as to why this is happening would be great!
which points to the very first line of code that's calling my native method.
Sounds like you are building your application with native libraries included and the .APK you created has only bundled some architecture types into it. If you have native libraries, make sure to include all architecture types (usually x86 and armv7 does the job, but always consult your compatibility checklist first) and make sure if you do ABI splitting that you are using the right APK.
Please consule the following guide to make sure you have the NDK integration set up correctly.
AOSP was trying to find the .so that my APK uses from either the system/lib or vendor/lib folders and since it wasn't there it was causing the UnsatisfiedLinkError. So by adding the .so object file directory to those locations the APK started up fine inside the emulator after that. This could also be accomplished by modifying the Android.mk as well by adding these lines to the file.
include $(CLEAR_VARS)
LOCAL_MODULE := myfile
LOCAL_SRC_FILES := lib/myfile.so # or wherever your .so is located
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
include $(BUILD_PREBUILT)
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.