I am working on custom Android build, where prebuilt should be included as a system app. Simply, this app adds VPN profile and open links after it.
I've done the following with no result. I left no stones unturned.
First, I add the APK to packages/apps/<app name>, and include its module name in build/make/target/product/base_system.mk to be include in the /system. It successfully included in /system/priv-apps/. Reference
Following these steps, I re-signed the APK as a system apps & added android:sharedUserId="android.uid.system" to application. Successfully done and checked it with adb shell ps -Z | grep system_app.
Selinux policy denied most of operation used audit2allow and added the allow statements to system/sepolicy/public/init.te.
Result: the app installed but seems the OS blocked some of its services/processes or something and cannot operate properly, I also found this I/system_server: oneway function results will be dropped but finished with status OK and parcel size 4.
AFAIK, System apps gain access to an extremely high level of system. But this is not what is happening.
Why does Sepolicy denies a system_app request?
Is there any wrong with these steps? What should I do in order to make the app work properly?
Update.
the app include prebuilt .so files and now the error is that the app cannot run these files.
Cannot run program "/system/priv-app/****/lib/arm64/libovpnexec.so": error=2, No such file or directory
Related
In my company, we would want total control for battery consumption in the field, using only 2g and gps could drain the battery awfully fast. What we decided is that we need to have root access to the mobile phone, So that when phone is idle, we would turn off those needless battery consumption.
And also we would not allow users to uninstall it and clear data to it.
My Question is :
Where do I get these signature key?
Is it going to like a root access If ever I successfully managed to
sign it?
What is the difference between Root vs Signed with key?
Answering your three questions:
1 - Where do I get these signature key?
From Android's own documentation in the section Release Keys
The Android tree includes test-keys under
build/target/product/security
But the next part is where you should really pay attention
Since the test-keys are publicly known, anybody can sign their own
.apk files with the same keys, which may allow them to replace or
hijack system apps built into your OS image. For this reason it is
critical to sign any publicly released or deployed Android OS image
with a special set of release-keys that only you have access to.
So basically unless you can somehow gain access to manufacturer's pvt keys it might be difficult to achieve this. This is why a user in a previous comment was saying this is usually achieved by producing your own build.
2 - Is it going to like a root access If ever I successfully managed
to sign it?
You will not get "root access" by doing it, but you will get access to an extremely high level of access. Specifically, what this achieves you is that you will be granted permissions with declared android:protectionLevel="signature" which is, arguably, the most exclusive one.
One other dangerous consequence (or fun, depending on how you look at it) of this is that you can now run your app under system user process android:sharedUserId="android.uid.system" - under android's "process sandboxed" security rules this would normally fail.
3 - What is the difference between Root vs Signed with key?
With an app signed with the platform key from your build, you can get the permissions mentioned above, or run your app with UID 1000 (system uid) which in android is much more powerful than the UIDs of other apps because of the permissions it can request, this is a behaviour specific of Android though.
In a rooted device, you can use UID 0 (root) which has the broadest access in linux based systems, you can bypass most of the security sandboxing/checks/fences on the OS.
Hope this helps ;)
Well below is your answer,
You can find platform keys from
HERE. The command to sign apk (for linux) is:
java -jar signapk.jar -w platform.x509.pem platform.pk8 APPLICATION.apk APPLICATION_sign.apk
onward Android 10 lib64 library path need to provided which can be found at android/out/host/linux-x86 after generating a successful build, one can copy folder or simply provide its path to generate sign APK
java -Djava.library.path="<path to lib64>" -jar signapk.jar -w platform.x509.pem platform.pk8
If you sign your apk with platform keys you won't required root access you can simply install it from "adb install" command, and yes in someway it is like root 'cos it can access all internal api but keep in mind if your app is system signed then you can't write external storage.
First of all don't combine both root is user where system app is application type which distinguish from normal application below link might clear your confusion regarding it.
what-is-the-difference-between-android-user-app-with-root-access-and-a-system-ap
For anyone coming to this question and even after reading the comments not being able to make it work, it might be because there're some things missing (specially if getting OPENSSL errors), here's everything you need.
Sign APK with test keys from the AOSP
git clone https://android.googlesource.com/platform/prebuilts/sdk.git - Careful it's ~6GB, or you can download what you need, the signapk.jar file and the libraries.
download the platform.x509.pem and platform.pk8 from https://github.com/aosp-mirror/platform_build/tree/master/target/product/security (or get your own keys corresponding to the image)
With java installed, change the following command with the right paths for the files, the lib64 in the sdk you just cloned, the signapk.jar file, the platform key files and the apk to sign
java -Xmx2048m -Djava.library.path="~/../sdk/tools/linux/lib64" \ # In the cloned sdk
-jar ~/../sdk/tools/lib/signapk.jar \ # In the cloned sdk
platform.x509.pem platform.pk8 \ # The keys for signing (from step 2)
app-prod-release.apk release.apk # The app to sign and the signed app
I have app which include two native library (for example libfirst.so, libsecond.so). Now a loading libraries standard method.
System.loadLibrary("first");
System.loadLibrary("second");
Now I need to be able to update the library without reinstalling the app (without update .apk).
I can loaded native libraries this method
System.load("/storage/emulated/0/armeabi/libfirst.so");
System.load("/storage/emulated/0/armeabi/libsecond.so");
I think this is a bad practice.
I tried to copy manual the libraries in folder getApplicationInfo().nativeLibraryDir , but system error:
open failed: EACCES (Permission denied)
What are the best practices update native libraries without update apk ?
What are the best practices update native libraries without update apk ?
I don't believe that contingency is covered.
Code signing does two things. First, it ensures the developer who publishes the app is the same one who updates the app. Second, it creates trust relationships between related apps (but that does not apply here). Nikolay Elenkov discusses the topic at Code signing in Android's security model.
If you want to update the dependent libraries, then you need to rebuild the APK to prove you are authorized to make the updates. That's part one of code signing discussed above.
If you want to update a personal copy of the app (and not publish it), then just strip the existing signatures, update the libraries, sign with the Debug signing key, and then push to the device.
Also, you are safe to perform adb install -r <the apk>. -r is "replace existing application", and its effectively a reinstall. It retains the previous application data, like a database.
There are some other things that need to be done when updating an app, like increasing version numbers so its handled properly in Google Play. But they are not really relevant to your question.
There is actually a way to do it
for install your apk:
adb install -r path_to_my_apk.apk
now you can change your code and recompile your .so and when you want to update it you can do:
adb push -p path_to_my_so.so /data/local/tmp/libmyso.so
adb shell cat /data/local/tmp/libmyso.so | run-as com.mycomp.myapp sh -c 'cat > /data/data/com.mycomp.myapp/lldb/libmyso.so; chmod 700 /data/data/com.mycomp.myapp/lldb/libmyso.so'
adb shell rm /data/local/tmp/libmyso.so
Android studio does exactly this in order to install the lldb server when you are debugging native code.
It assumes there is a folder called lldb in your app directory. if you are debugging using Android Studio, this folder will already be there.
Your Java code needs to make sure to load the correct .so using
System.load("/data/data/com.mycomp.myapp/lldb/libmyso.so");
Instead of System.loadLibrary() which doesn't take a full path in a static initialization block somewhere, similar to how you load any other .so
This method can be very useful if your apk is huge and you only want to update the binary for easy debugging.
Which permission an app need to access the file /cache/recovery/last_log?
My app is signed with platform key, so I can provide system permissions. The app will be pre-built into a device, and the device will be non-rooted.
You can only access the cache directory for your app
getApplicationContext().getCacheDir()
Apparantly, you don't need any permission to READ from cache. But you do need permission if you want to write something in cache directory.
Documentation from http://developer.android.com/reference/android/Manifest.permission.html#READ_LOGS on logs:
Allows an application to read the low-level system log files.
Not for use by third-party applications, because Log entries can contain the user's private information.
Constant Value: "android.permission.READ_LOGS"
What do you mean by 'recovery'?
I found the solution some time ago, just posting here to help if someone else have the same problem.
The thing that was blocking me was SELinux. I'm posting the solution to the original question, but be aware that some things changed on Android since that, including the creation of the A/B system, where the recovery and cache partitions where removed from Android.
SELinux
I learned the hard way that one have to deal with SELinux in order to work on the Android source code. The important bits are:
On the device definition (makefiles under the device directory) there will be reference to SELinux policies. In one of the devices I work with I have a makefile that have:
BOARD_SEPOLICY_DIRS += path/to/sepolicy/dir
And on the directory all files with ".te" ending will be used as SEPolicy. I suggest adding a new directory for your custom policies, where you can use your own git repository.
Now you need to know what policies to write. I suggest reading Google's documentation here.
Personally, I first test the app on a userdebug build with SELinux in permissive mode (log only). These way SELinux will only log actions that violates the policies, what makes development substantially easier. Only after I know the app runs with SELinux off I start collecting the logs and set the "enforced" mode.
To collect the SELinux logs of actions that don't met the policies I use:
adb logcat | grep "avc: denied"
There is a tool called audit2allow that reads the logcat output and the device policy and outputs policies that are missing:
adb pull /sys/fs/selinux/policy
adb logcat -b all -d | python2 audit2allow -p policy
The output of the file are policies that can be added to the .te files.
This particular method I used with Android 8.1.
Sign app with platform key
I also had to sign the app with the platform key. For that I edited Android.mk to add:
LOCAL_CERTIFICATE := platform
System UID
Fixing SELinux policy might not be enough for some device. You might need to make the app run with the system user.
You must avoid using these method, because this user have access to some very sensitive device files. If you really need, you can do it by:
Sign the app with platform key;
On the app that will read the recovery, you have to make sure AndroidManifest.xml set android:sharedUserID to "android.uid.system".
<manifest package="my.app.name"
xmlns:android="http://schemas.android.com/apk/res/android"
android:sharedUserId="android.uid.system">
....
</manifest>
Other useful files
Other files of interest to diagnose boot and ota problems are documented here.
I use construct 2 to build my apps and then I export them to CocoonJS which then compiles them as a native app. I download an unsigned .apk file, sign it then upload it Google Play. The apps work great, just like they were natively written.
When I compile my app with CocoonJS it requires all of these permissions that my app doesn't need. How can I remove the unneeded permissions?
Until Ludei implement an optional permissions on their cloud compiler, we have to do a bit of "hacking" to fix the problem ourselves.
Get the attached apktool.zip, extract it to a folder C:\Android (to make it easier later).
https://static3.scirra.net/uploads/articles/1071/apktool.zip
Copy your release CJS compiled game.apk (from herein, referring to that APK file as game.apk) into C:\Android so its in the same folder as the extracted apktool files.
Open command prompt in C:\Android by right clicking somewhere in that folder while holding SHIFT key.
First, we need to install the framework of our CJS compiled game.apk, type this in:
apktool if game.apk
Its instant, with a feedback that it installed in location 127 or thereabouts. Now we have to decompile the APK, type this in:
apktool d game.apk game
It take awhile depending the size of your game & speed of your PC, but all the contents of your game.apk will be decompiled and stored in a subfolder with the same name as your game.apk, ie. game. Note, if you use different versions of apktool, you may need to change the flag to: apktool d game.apk -o game so it decompiles properly.
Browse the new game subfolder, you will see all the contents. What we are after is the AndroidManifest.xml, open it with Notepad++
Hi-res version: halfgeekstudios.files.wordpress.com/2014/07/androidmanifest.jpg
Remove the permissions by deleting the grey highlighted lines!
The permissions ACCESS_NETWORK_STATE & INTERNET are required, if you remove it, your game is likely to crash on startup. This is true even if you have no Ads or IAPs or Social plugins. CJS needs these since its got some built in analytics that require it. BILLING is also required if you implement IAPs. Interestingly, Google has decided that these three aforementioned permissions will now be considered normal and they do not warn users when games have these three only, only if it contains the other permissions!
Here, I'd like to point out this line:
You can edit your game to be on phones or tablets by setting them to false. If you set smallScreens & normalScreens ="false", the game is only compatible with tablets or vice versa (I've tested this with my own games). This is handy if you design your target to tablets and don't want to manually filter over 6,400 devices, one at a time. :D
Once the changes are done, save it. Go back to the command prompt, type this in to recompile it into a new APK:
apktool b game game_new.apk
Takes awhile, but you will get your game_new.apk that is modified. Now you need to proceed with normal signing and zip aligning prior to uploading to Google Play.
https://www.scirra.com/tutorials/1071/removing-permissions-from-cocoonjs-compiled-apk
You cannot remove it. Try other tools like Phonegap. phonegap
I'm trying to modify the Androidmanifest.xml for the browser on my device so that I can execute an app by loading a URI in the browser.
I've been running around the file system in ADB SHELL all day, but can't seem to find it. Plus there is no FIND, nor LOCATE command on the system.
You can theoretically find the Androidmanifest.xml file in the APK.
Every APK contains the compiled source code of the application. There is no useable decompiler for APKs at the moment so it is not possible to change the content of one.
In addition to the compiled code and the other resources of the application, an APK also contains a signature from the developer, which will become invalid when the content is changed to verify the source of an APK. An Android system won't install an APK with an invalid signature, so even if you could change the content of the APK, you still couldn't use it.
The conclusion: You cannot do what you are trying to do.
Android Studio on Windows 10/11, it’s in: app/src/main.