Basically I want to be able to decompile apks. And jar files directly on my phone. Can I do that?
Yes, you can. At least, for the most part. The main constraining factor is the small amount of memory available on the device.
1. run the dx util on baksmali.jar, to produce a classes.dex file
2. add the classes.dex file to a new jar (or you can just add it to baksmali.jar)
3. push the jar containing classes.dex to the device somewhere (let's say /data/local/baksmali.jar)
4. dalvikvm -classpath /data/local/baksmali.jar org.jf.baksmali.baksmali <normal baksmali options>
5. bonus points if you then proceded to run baksmali on baksmali.jar (and then the universe implodes)
note: I just tried this with the latest version of baksmali, and there's some weird issue with the baksmali jar file, where it contains duplicate entries of every class file, which causes dx to choke on it. I'll see if I can get that fixed soon, and get a new build out. In the meantime, you can probably find an older version without that problem.
Sweet, thanks for your input. I was out last night and I had this idea for an edit to make, only to become sad because I didn't have access to a computer.
This will help me out a lot.
JesusFreke said:
Yes, you can. At least, for the most part. The main constraining factor is the small amount of memory available on the device.
1. run the dx util on baksmali.jar, to produce a classes.dex file
2. add the classes.dex file to a new jar (or you can just add it to baksmali.jar)
3. push the jar containing classes.dex to the device somewhere (let's say /data/local/baksmali.jar)
4. dalvikvm -classpath /data/local/baksmali.jar org.jf.baksmali.baksmali <normal baksmali options>
5. bonus points if you then proceded to run baksmali on baksmali.jar (and then the universe implodes)
note: I just tried this with the latest version of baksmali, and there's some weird issue with the baksmali jar file, where it contains duplicate entries of every class file, which causes dx to choke on it. I'll see if I can get that fixed soon, and get a new build out. In the meantime, you can probably find an older version without that problem.
Click to expand...
Click to collapse
The problem seems to be within the buildprocess as the generated classes for baksmali and smali are added twice to the *-dev-jar-with-dependencies.jar. As I'm not familar with maven I didn't fixed the source of the error but I managed to get it working.
I attached a small pythonscript which is able to remove the dublicated files within the jar. Just run it over the file and get a fixed version which is processable by dx.
The script:
Code:
#!/usr/bin/python
import sys
from zipfile import *
if len(sys.argv) != 3:
print("Usage: %s input.jar output.jar" % sys.argv[0]);
sys.exit(-1)
input = ZipFile(sys.argv[1], "r")
output = ZipFile(sys.argv[2], "w")
seen = []
for file in input.namelist():
if file not in seen:
output.writestr(file, input.read(file))
seen.append(file)
else:
print("dub found: %s" % file)
input.close()
output.close()
sorry ...
Wrong place
JesusFreke said:
Yes, you can. At least, for the most part. The main constraining factor is the small amount of memory available on the device.
1. run the dx util on baksmali.jar, to produce a classes.dex file
2. add the classes.dex file to a new jar (or you can just add it to baksmali.jar)
3. push the jar containing classes.dex to the device somewhere (let's say /data/local/baksmali.jar)
4. dalvikvm -classpath /data/local/baksmali.jar org.jf.baksmali.baksmali <normal baksmali options>
5. bonus points if you then proceded to run baksmali on baksmali.jar (and then the universe implodes)
note: I just tried this with the latest version of baksmali, and there's some weird issue with the baksmali jar file, where it contains duplicate entries of every class file, which causes dx to choke on it. I'll see if I can get that fixed soon, and get a new build out. In the meantime, you can probably find an older version without that problem.
Click to expand...
Click to collapse
I realize this is a very old thread, but it is exactly what I am looking for However, it seems there are Java 8 features in smali/baksmali now and dx does not work. Is there a workaround for this or any other way to run smali/baksmali from terminal on Android? Thanks!
The older versions of smali may still work for you. Or what I've done is use Termux and download the jdk for arm64 and used the ndk to compile smali on my device.
Delgoth said:
The older versions of smali may still work for you. Or what I've done is use Termux and download the jdk for arm64 and used the ndk to compile smali on my device.
Click to expand...
Click to collapse
Thanks for the reply
However, I am not trying to compile smali on my device. I am trying to run the latest smali/baksmali on my device in Termux. Unfortunately, the older versions will not work for my needs. If you can help I would really appreciate it
But compiling the latest build of small on the device will allow you to use the latest build of smali.
How to Recompile The HP TOUCHPAD Android Kernel for DirtyUnicorns 8.1 and Shumash SKZ DirtyUnicorns 8.1 and Evervol 7.1
This is done on a Linux OS (Ubuntu 18.04 x64). If you are using other OS, then install Linux as a virtual machine.
The process is the same for all Kernel, but I have only done it with the last two version of Android and can verify that it works.
You can get the kernel source code from other version and try to compile it.
You many need to install the following packages on your Linux OS:
sudo apt-get update
sudo apt install python-pip
sudo apt-get install libncurses5-dev libncursesw5-dev
To recompile the Kernel you need to download an arm cross compiler, there are two options, google android or Linaro.
Get the Android arm cross compiler here:
https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/+archive/26e93f6af47f7bd3a9beb5c102a5f45e19bfa38a.tar.gz
You can also use Linaro:
https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/armeb-eabi/gcc-linaro-4.9.4-2017.01-x86_64_armeb-eabi.tar.xz
Get the Kernel source for:
DirtyUnicorns:
https://github.com/DirtyUnicorns/android_kernel_htc_msm8960/archive/o8x-caf.zip
Shumash SKZ overclock Kernel for DirtyUnicorns 8.1
https://github.com/shumashv1/android_kernel-3.4_hp_tenderloin/archive/o-8.1.zip
Shumash SKZ overclock Kernel for Evervolv 7.1
https://github.com/shumashv1/android_kernel-3.4_hp_tenderloin/archive/ng-7.1.zip
1. Create a folder on your home directory
Code:
arm-eabi
2. Extract (unzip) the Android cross compiler file arm-eabi-4.8-26e93f6af47f7bd3a9beb5c102a5f45e19bfa38a.tar.gz into the arm-eabi direcory:
You should have the following directory structure
(Your ID will be different than ubuntu) but all the directories needs to have the following structure.
Code:
/home/ubuntu/arm-eabi/share
/home/ubuntu/arm-eabi/libexec
/home/ubuntu/arm-eabi/lib64
/home/ubuntu/arm-eabi/lib32
/home/ubuntu/arm-eabi/lib
/home/ubuntu/arm-eabi/include
/home/ubuntu/arm-eabi/bin
/home/ubuntu/arm-eabi/arm-eabi
3. Extract (unzip) one of the Kernel file that you will like to recompile into your home directory:
4. Rename the extracted folder ( example : android_kernel_tenderloin_DU_msm8960-o8x-caf )
to: kernel
It should have all folders under kernel directory
(Your ID will be different than ubuntu)
Code:
/home/ubuntu/kernel/crypto
/home/ubuntu/kernel/block
/home/ubuntu/kernel/arch
( and many more)
That is all that is need it to recompile, but the folder location and structure is very important for the scripts to work.
The configuration file to make the Kernel for the two versions of the touchpad is located in:
Wifi standard version
/kernel/arch/arm/configs/tenderloin_android_defconfig
4g version
/kernel/arch/arm/configs/tenderloin4g_android_defconfig
5. Open a terminal window in the kernel directory and paste the following commands:
Code:
export CROSS_COMPILE=~/arm-eabi/bin/arm-eabi-
## You can make changes directly to the tenderloin_android_defconfig using a text editor if you know what you are doing or use the on screen menu.
## replace the configuration file for your model at the end.
Code:
./make_defconfig.sh tenderloin_android_defconfig
Now you have the Linux/arm 3.4.113 Kernel Configuration screen to make all your choices.
If the menu does not comes up is due to packages you need to install on your OS for ncurses to work, first mentioned.
There is too much information to go over and explain, you will have to learn as you go, not all settings apply to the device. There are options and modules for many kernels not only just the TP.
When you are done, or feel that you have done anything after looking at the DNA of an Android kernel for the TP then press:
the esc key twice to exit and save the new changes to the configuration file.
6. Ready to make the configuration active to recompile:
Code:
make ARCH=arm tenderloin_android_defconfig
7. Start the recompile process:
Code:
make ARCH=arm -j4 CROSS_COMPILE=~/arm-eabi/bin/arm-eabi- kernel.uImage
Once is finish your new kernel uImage will be at:
kernel/arch/arm/boot/kernel.uImage
8. Copy the kernel.uImage file to your desktop or any other place out of the Kernel folder.
9. This command will reset ad clean all your settings from making the Kernel, so that you can start the process again.
Code:
make mrproper
Now you have a modified kernel and need to combine it with the ramdisk from the same ROM kernel (boot.img) that is in the ROM zip file.
Extract the boot.img from the ROM and follow the steps on how to unpack the boot.img using this link:
Now that you have access to the ramdisk, you can make system read and write and many more options on every file!
With the Kernel settings and Ramdisk you have completely total control, is the DNA settings of the device.
https://forum.xda-developers.com/hp-touchpad/development/make-root-permanet-read-write-to-t3846567
Once unpack rename kernel.uImage to kernel.uImage_original (or delete it)
Copy the new kernel.uImage to the folder and repack.
You now have your own modified kernel and can place it in the boot directory of your tablet.
If it finished booting to Android, all is good! if not start again.
Your HP Touchpad will not get bricked by any modification you will make to the kernel. It can freeze and you can do a hard reset and boot from the original kernel.
Now if you encounter a problem with your ROM, feel is slow or any other issues you know how to fix it yourself and learn how time consuming and fun is to get this working. Be part of the community and at least try to improve on the great work that others have done.
Many thanks to everyone that made all this work possible all credits go to:
Milaq, Jcsullins, Invisiblek, Flintman, Shumash and the many others! the list is longer than all the settings of the kernel!
All that explanation to run the following commands:
Code:
export CROSS_COMPILE=~/arm-eabi/bin/arm-eabi-
./make_defconfig.sh tenderloin_android_defconfig
make ARCH=arm tenderloin_android_defconfig
make ARCH=arm -j4 CROSS_COMPILE=~/arm-eabi/bin/arm-eabi- kernel.uImage
make mrproper
I am trying to install a clean Android System WebView (packagename: com.android.webview) onto stock LG G5 RS988 RS98821d Android 7.0 that is rooted.
I downloaded an arm64 WebView APK from the Bromite Releases GitHub page:
https://github.com/bromite/bromite/releases
I tried installing the Bromite WebView APK to "/system/app/webview/" (0644 permissions) and rebooted, but the WebView implementation could not be used.
There are instructions regarding installing Bromite System WebView available:
https://github.com/bromite/bromite/wiki/Installing-SystemWebView
From my reading of the installation instructions, "res/xml/config_webview_packages.xml" from "/system/framework/framework-res.apk" must contain the an entry for the package with the particular package name ("com.android.webview" in this case).
After examining the stock "config_webview_packages.xml" member file, it appears that a reference to "com.android.webview" is not present. The "config_webview_packages.xml" XML file also appears to not be easily readable in a text editor. My guess is that it has some kind of signing.
What must be done to get the system to allow the newly installed WebView? My impression is that the "config_webview_packages.xml" XML file must be edited, but it is not clear how to do so, given that it does not appear to be just plain text.
I have attached a copy of the "config_webview_packages.xml" XML member file and the original framework-res.apk file zipped into a ZIP 2.0 archive.
XML files inside apks are compressed, you should unpack the framework-res.apk using a tool for apk editing, not just a zip archiver program. On Android, you can use APK Editor Pro, for example.
By the way, have you already uninstalled Chrome? If Chrome is installed, it will be forced as the standard WebView provider.
tremalnaik said:
XML files inside apks are compressed, you should unpack the framework-res.apk using a tool for apk editing, not just a zip archiver program. On Android, you can use APK Editor Pro, for example.
Click to expand...
Click to collapse
It was my impression that the APK files were zip files with a particular signature block. I shall try a tool like APK Editor Pro and report back.
tremalnaik said:
have you already uninstalled Chrome? If Chrome is installed, it will be forced as the standard WebView provider.
Click to expand...
Click to collapse
I have uninstalled/removed both Chrome and the Android System WebView (Google Apps version).
Ascii3 said:
It was my impression that the APK files were zip files with a particular signature block. I shall try a tool like APK Editor Pro and report back.
Click to expand...
Click to collapse
Now I'm on PC and I remember the name of the tool I use sometimes on PC: APKChanger. It's very complete, although very heavy (about 650MB with my current configuration);
If you have platform tools installed on your pc, or the whole Android Studio, you can also use
Code:
aapt d xmltree framework-res.apk res/xml/config_webview_packages.xml
to see the list of allowed webview packages.
Ascii3 said:
I have uninstalled/removed both Chrome and the Android System WebView (Google Apps version).
Click to expand...
Click to collapse
So we can be sure the problem is not the system forcing Chrome as default WebView provider. So, as Bromite's wiki states, "Changing the package name does not make installation easier/possible;", so the only solution is to add com.android.webview to config_webview_packages.xml, or, if it is already there, remove the requirement for Google's signature on the webview package. EDIT: I checked, on your file com.android.webview is missing, you just need to add it:
Code:
E: webviewproviders (line=20)
E: webviewprovider (line=21)
A: description="Chrome Stable" (Raw: "Chrome Stable")
A: packageName="com.android.chrome" (Raw: "com.android.chrome")
A: availableByDefault=(type 0x12)0xffffffff (Raw: "true")
E: webviewprovider (line=24)
A: description="Google WebView" (Raw: "Google WebView")
A: packageName="com.google.android.webview" (Raw: "com.google.android.webview")
A: availableByDefault=(type 0x12)0xffffffff (Raw: "true")
A: isFallback=(type 0x12)0xffffffff (Raw: "true")
E: webviewprovider (line=27)
A: description="Chrome Beta" (Raw: "Chrome Beta")
A: packageName="com.chrome.beta" (Raw: "com.chrome.beta")
E: signature (line=28)
C: "MIIDwzCCAqugAwIBAgIJAOoj9MXoVhH6MA0GCSqGSIb3DQEBBQUAMHgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEUMBIGA1UEAwwLY2hyb21lX2JldGEwHhcNMTYwMjI5MTUxNTIzWhcNNDMwNzE3MTUxNTIzWjB4MQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzEUMBIGA1UECgwLR29vZ2xlIEluYy4xEDAOBgNVBAsMB0FuZHJvaWQxFDASBgNVBAMMC2Nocm9tZV9iZXRhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo/wW27nRxVqGbFOyXr8jtv2pc2Ke8XMr6Sfs+3JK2licVaAljGFpLtWH4wUdb50w/QQSPALNLSSyuK/94rtp5Jjs4RSJI+whuewV/R6El+mFXBO3Ek5/op4UrOsR91IM4emvS67Ji2u8gp5EmttVgJtllFZCbtZLPmKuTaOkOB+EdWIxrYiHVEEaAcQpEHa9UgWUZ0bMfPj8j3F0w+Ak2ttmTjoFGLaZjuBAYwfdctN1b0sdLT9Lif45kMCb8QwPp0F9/ozs0rrTc+I6vnTS8kfFQfk7GIE4Hgm+cYQEHkIA6gLJxUVWvPZGdulAZw7wPt/neOkazHNZPcV4pYuNLQIDAQABo1AwTjAdBgNVHQ4EFgQU5t7dhcZfOSixRsiJ1E46JhzPlwowHwYDVR0jBBgwFoAU5t7dhcZfOSixRsiJ1E46JhzPlwowDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAZO2jB8P1d8ki3KZILvp27a2VM3DInlp8I8UgG3gh7nBQfTrnZr5M1PL8eFHqX7MEvAiGCMTcrPklEhjtcHK/c7BcdeCWq6oL56UK3JTl33RxJcjmjrz3e3VI6ehRSm1feNAkMD0Nr2RWr2LCYheAEmwTPtluLOJS+i7WhnXJzBtg5UpUFEbdFYenqUbDzya+cUVp0197k7hUTs8/Hxs0wf79o/TZXzTBq9eYQkiITonRN8+5QCBl1XmZKV0IHkzGFES1RP+fTiZpIjZT+W4tasHgs9QTTks4CCpyHBAy+uy7tApe1AxCzihgecCfUN1hWIltKwGZS6EE0bu0OXPzaQ=="
E: webviewprovider (line=30)
A: description="Chrome Dev" (Raw: "Chrome Dev")
A: packageName="com.chrome.dev" (Raw: "com.chrome.dev")
E: signature (line=31)
C: "MIIDwTCCAqmgAwIBAgIJAOSN+O0cdii5MA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDETMBEGA1UEAwwKY2hyb21lX2RldjAeFw0xNjAyMjkxNzUwMDdaFw00MzA3MTcxNzUwMDdaMHcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDETMBEGA1UEAwwKY2hyb21lX2RldjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOYPj6Y9rVt8xizSHDYjDEkDfFZAgSiZ9T6tevkQXsFyfaq3Gk3h2qssi29G6cTPJ2VXFKlVB71wSXv5p9/LEcDQPWQiO3Q2cLmgUXxyhJWXI3g96tPAhZQX2q6SC37ZQdiBR/raMO70DAkvCyBGtNplsvutzSE3oZ7LYfzB8vTbe7zCh3fDYSS/7xb3ZVvFqydHS40uVq1qqg1S80Pge7tW3pDGsPMZN7yA4yfmsvA1rbHm9N8t3Rc9hqzh6OxNAAgRB535YcsWL7iF+mpdFILXk3jLYT0nMvMnB83rsdgnRREjlGQYHl2mh8+6CqujsW/eICDq/LR6BYDyqHhk0ECAwEAAaNQME4wHQYDVR0OBBYEFKzsl07JglgpbeYDYGqsgqRDo+01MB8GA1UdIwQYMBaAFKzsl07JglgpbeYDYGqsgqRDo+01MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBACka6SFF6xAcj8L8O6R36++E09DTiGZEjvKT8eIycgcQQ+p1WUmPb6M2EJpN6zvvSE62ussmXdzf8rIyc0JXA8jbViZt62Y39epNENFxPTLN9QzXlT+w8AW73Ka3cnbOuL5EgoDl8fM79WVlARY3X+wB/jGNrkiGIdRm2IZIeAodWgC2mtXMiferyYBKz2/F2bhnU6DwgCbegS8trFjEWviijWdJ+lBdobn7LRc3orZCtHl8UyvRDi7cye3sK9y3BM39k0g20F21wTNHAonnvL6zbuNgpd+UEsVxDpOeWrEdBFN7Md0CI2wnu8eA8ljJD45v0WWMEoxsIi131g5piNM="
E: webviewprovider (line=33)
A: description="Chrome Canary" (Raw: "Chrome Canary")
A: packageName="com.chrome.canary" (Raw: "com.chrome.canary")
E: signature (line=34)
C: "MIIDxzCCAq+gAwIBAgIJAML7APITsgV7MA0GCSqGSIb3DQEBBQUAMHoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEWMBQGA1UEAwwNY2hyb21lX2NhbmFyeTAeFw0xNjAyMjkxOTA5MDdaFw00MzA3MTcxOTA5MDdaMHoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEWMBQGA1UEAwwNY2hyb21lX2NhbmFyeTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANXfeAoZlr0ya1HBzIfAz/nLLjpPJeAPvuX5dueaxmiQgv2hNG22acriFuiiJI6TU0t8AIVJD5Ifbc4OOuA0zeFhdzWWGnmTRH6x27WI7bzOKnAqOvv21ZBmE9i8Vo++K13xWdTs3qVn1bn9oUONxFu0wKDzXYZhoj1Jom0RZGjXm16xuPlEuOzMcjiNBDoYuxPAXkMcK/G1gP4P4nAV8Rd/GGIjKRS/SUtcShhoAMOQhs4WIEkUrvEVRwhBDIbpM87oFbCVdBH38r0XS6F6CdhPJsKFhoEfq4c01HZqNmDpCPA8AAcCuSWqmXoTIqs7OqkWgduE2bInbWU7WMaTl+kCAwEAAaNQME4wHQYDVR0OBBYEFB/AsC4iPAqaLoNytNSx29qByI7+MB8GA1UdIwQYMBaAFB/AsC4iPAqaLoNytNSx29qByI7+MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAMb2Td3ro/+MGVnCPAbwBSOZMVLUKGqt6zr8CShW9mtFHnmy29EaWSYYAj1M4+6Vpkq85NsgBEck7rnUjV8A3Q0NKdTys1KRKJqVvQRBN6SwqQenSf/abxQCa8Z+69rh+3BkIU1HLtu5lrMDZwon5H91L5mpORn6vItd20uW132lwSDeUEW2CHslTrodoFuTUcSUlRiq/URfUH3baO1QHXkxpQwrBPKL5deJfcZnxh5MAtAGSQL7gHvayEFlDppETXdDO7vgGTH2dEK2TjKWALbGiKkxSqjRyTNt4/FOj10TqNRdUamj+ydVJgzGQ8bki4Vc6NnKm/r4asusxapkVR4="
E: webviewprovider (line=36)
A: description="Chrome Debug" (Raw: "Chrome Debug")
A: packageName="com.google.android.apps.chrome" (Raw: "com.google.android.apps.chrome")
On Android, I used APK Editor Pro 1.10.0 to modify res/xml/config_webview_packages.xml of /system/framework/framework-res.apk. A new APK with a generic signature was generated with the modification. I used the XML file editing option to select and modify the config_webview_packages.xml. The XML file editing functionality is given to be in beta and appears buggy.
I replaced the original /system/framework/framework-res.apk file with the patched one using the TWRP 3.2.3-0 file manager and attempted to boot to system. The system would start, but get stuck at the LG logo screen. I tried wiping data, and cache in recovery and booting again, but received the same result. I note that adb was available and usable after the boot process got stuck on the LG Logo screen.
My impression is that the patched framework-res.apk file is incompatible or defective. Perhaps APK Editor Pro 1.10.0 malformed the output APK (the XML editing feature appeared unfinished) or that the LG stock ROM expects framework-res.apk to have have a particular signature.
Perhaps a different APK editing tool should be tried. What could the problem be?
I have attached a ZIP archive containing the APK Editor Pro 1.10.0 modified framework-res.apk.
EDIT: Attachment has been removed; the file was defective and should not be used. Attachment is no longer necessary.
I have now patched framewor-res.apk successfully, and Bromite System WebView is working.
Did you use again APk Editor Pro or a PC tool?
The tools I used were Windows tools (and with a Java dependency in the case of Apktool) and were: Apktool 2.3.1 and WinRAR 5.6.1. I found that it is best to avoid newer versions of the tool unless trying to manipulate Android 9 Pie or newer resources.
Ascii3 said:
I have now patched framewor-res.apk successfully, and Bromite System WebView is working.
Click to expand...
Click to collapse
I know this is an old post, but how did you get it to boot?
I'm using apktool 2.5 and seems to be stuck on the boot screen as you were
burny02 said:
I know this is an old post, but how did you get it to boot?
I'm using apktool 2.5 and seems to be stuck on the boot screen as you were
Click to expand...
Click to collapse
From somewhere else it seems that you are now using Apktool 2.3.1.
After comparing my notes, my impression on what you are missing and some related notes:
The modified framework-res.apk should use the unmodified APK file's "AndroidManifest.xml" root file and META-INF directory contents. It is not sufficient for any of the content to be the same after decompiling.
Copy "AndroidManifest.xml" and META-INF directory from original framework-res.apk to modified framework-res.apk using zip program, if contents are different.
v2 APK signing scheme (which includes the APK file itself in validation), if present, would be broken, but the scheme's enforcement is not enforced on /system; v1 APK signing scheme (on APK contents ("AndroidManifest.xml" file and META-INF directory contents)) is still enforced.
I zipaligned output/modified framework-res.apk prior to transferring original "AndroidManifest.xml" file and META-INF directory contents, but I do not believe it matters for the purposes of getting a functional framework-res.apk.
EDIT: Some added things to keep in mind:
Sometimes clearing system cache and the runtimes cache is also necessary before system will boot after framework-res.apk replacement. Also make sure that the permissions of the replaced framework-res.apk file are at minimum whatever the original file permissions were. Depending on what software you use to replace the framework-res.apk file, the permissions set may be different.
I really appreciate the help, still does not work unfortunately.
Here is what I do:
adb pull framework-res.apk
apktool d framework-res.apk (tried most versions, mainly now 2.3.1)
Edit framework-res/res/xml/config-webview-packages.xml to:
Code:
<webviewproviders>
<webviewprovider description="Bromite WebView" packageName="com.android.webview" availableByDefault="true" isFallback="true" />
</webviewproviders>
Removing other dev versions with signatures etc
apktool b framework-res
zipalign -v 4 framework-res.apk framework-res-new.apk
Move META-INF and AndroidManifest.xml from the 1st original framework-res.apk > framework-res-new.apk (Have also tried moving res & resources from the new to the original...7Zip, WinRAR, CLI - Linux)
adb push framework-res-new.apk /system/framwork-res.apk
Modify permissions in TWRP > 0644
Move framework-res.apk from /system/ to /system/framework/framwork-res.apk (I read somewhere this is better than pushing directly. Neither worked)
Clear Davlik & Cache
Reboot
Hangs on boot screen
Any ideas if I am missing something important?
@burny02 - Please clarify whether the framework-res.apk you are trying to modify is for LG G5 stock ROM Android Nougat.
I note that you are using the "isFallback="true"" flag with the webviewprovider tag. The purpose of the isFallback attribute set to true (its default is false) is to specify that the WebView provider should be disabled by deault and should only become available when allow other WebView providers are disabled. Using the attribute with the true value with only a single WebView provider seems improper. I do not know if boot should fail if the attribute is present in the way that it is, but in both scenarios I would recommend its omission.
It has also been a while since I used Apktool versions and do not exactly remember the command lines. Do not take my not pointing to an issue with it as there necessarily not being an issue. One thing I would mention is that one typically first install a frameworks before decompiling and building. For the LG G5 RS988 Android Nougat, I believe installing the framework-res.apk as a framework was sufficient. You would specify on command line "apktool if framework-res.apk" and any tags you wish to explicitly specify, if any.
The moving of framework-res.apk to /system/ before /system/framework/ is oftentimes done by people to try to install a modified framework-res.apk with proper permissions and on a live system before the system crashes and reboots. Once framework-res.apk is copied to /system , but does not replace the framework-res.apk file, proper permissions can be set prior to using that file to replace the live framework-res.apk. It is still important to note that some software disregards permissions set when a file is relocated or copied, so this could be an issue if framework-res.apk is replaced with more restrictive permissions than the original framework-res.apk (less restrictive permissions should not usually be a problem for the app to be used). I particularity do not like the idea of the system crashing and prefer to make such changes offline (such as via the aid of a custom recovery).
Sorted. Got it working. Really appreciate the help, Ascii3
For anyone looking at this in the future, the isFallback back seems to stop booting, regardless of whether it is the only entry or not.
The procedure then works as above:
adb pull framework-res.apk
apktool d framework-res.apk (2.3.4 worked for me - SDK 24 Android 7.1 (LGG5))
Edit framework-res/res/xml/config-webview-packages.xml to:
Code:
<webviewproviders>
<webviewprovider description="Bromite WebView" packageName="com.android.webview" availableByDefault="true" />
</webviewproviders>
apktool b framework-res
Move META-INF and AndroidManifest.xml from the 1st original framework-res.apk > new framework-res-new.apk (Used 7Zip drag & drop)
adb push framework-res-new.apk /system/framework/framwork-res.apk
Modify permissions in TWRP > 0644
Clear Davlik & Cache
Reboot
I found the following unnecessary :
Installing framework (apktool if)
Zip-aligning
Moving to /system prior to /system/framework/ (Using TWRP, live system; it might be necessary)
burny02 said:
Sorted. Got it working. Really appreciate the help, Ascii3
Click to expand...
Click to collapse
Sure.
burny02 said:
For anyone looking at this in the future, the isFallback back seems to stop booting, regardless of whether it is the only entry or not.
Click to expand...
Click to collapse
The isFallback attribute is supposed to only be set to true for no more than one webviewprovider. Explicitly setting it to false (its default) should not be problematic (but does result in a larger config-webview-packages.xml file generated). Setting isFallback to true on the only webviewprovider item is not an intended use and apparently results in no boot.
burny02 said:
I found the following unnecessary :
Zip-aligning
Click to expand...
Click to collapse
I do not think zip-aligning apps is necessary generally . My understanding around the reason to do so is to try to optimize the packaged data to be more efficiently fetched in the manner which Android fetches the data.
@Ascii3 @burny02
Hello guys, sorry to exhume this post but I'm struggling and all other threads are maybe ten years old...
So I'm struggling to replicate what you did! I'm no expert but I can follow basic instructions.
So I do as you say, decompile framework-res.apk, modify the xml file (I just add the line). This step seems okay since I did some errors while editing the file and apktool would not recompile properly. Now this goes fine.
Then I got my freshly recompiled framework-res.apk, but 7zip on linux won't let me insert META-INF and AndroidManifest.xml. So I had to rename the extension .zip, do it, then rename in apk. Could this be an issue? It looks dirty.
Anyway, after this you didn't had to resign the apk? I read everywhere you had to, so I did. I did not zipaligned it since I used a resign tool I found on xda and I could not tell if I had to do it before or after resigning, but since you said you didn't zipalign it I thought whatever.
The problem is the following: after replacing framework-res.apk in /system/framework, the phone won't start, I get stuck on the starting screen and I could extract the following from logging:
01-24 04:15:17.470 +0000 4042 4042 I PackageManager: /system/framework/framework-res.apk changed; collecting certs
01-24 04:15:17.749 +0000 4042 4042 W PackageManager: Failed to scan /system/framework/framework-res.apk: Failed to collect certificates from /system/framework/framework-res.apk
Have you got any ideas of what I did wrong? It's my fourth soft-brick today, I'm getting a bit annoyed.
Thanks in advance
@LeSplendide did you ever get this working? Not sure if I'm having the same trouble, but I followed burny's instructions and my phone fails to boot. I checked logcat but I don't see anything relating to framework-res. I'm using magisk to overlay it because if I touch the /system partition for real, VoLTE stops working on my phone (known issue for this phone). I'm successfully overlaying stuff in /system/app and /system/priv-app so I do have overlaying generally working, though this is the first apk in the framework directory I've tried to overlay. Boy do I want to get this working. I've extensively degoogled and debloated this phone and the only glaring thing that remains is chrome handling webview.
TheShanMan said:
@LeSplendide did you ever get this working? Not sure if I'm having the same trouble, but I followed burny's instructions and my phone fails to boot. I checked logcat but I don't see anything relating to framework-res. I'm using magisk to overlay it because if I touch the /system partition for real, VoLTE stops working on my phone (known issue for this phone). I'm successfully overlaying stuff in /system/app and /system/priv-app so I do have overlaying generally working, though this is the first apk in the framework directory I've tried to overlay. Boy do I want to get this working. I've extensively degoogled and debloated this phone and the only glaring thing that remains is chrome handling webview.
Click to expand...
Click to collapse
I'm sorry I have no idea, rn Webview Implementation says I have Android System Webvew 102.0.5005 so I assume this is chrome webview? But I have no clue what I did or not but I know for sure I fixed my problem which was that Webview would crash when trying to sign in a google account on my MicroG'd LEAOS. Now this works so I guess I did make it work. All I found that could be a clue is a update.zip containing instructions and the webview in question. Iirc, the issue was that the zip needed to be signed so that twrp could flash it, so I think I just signed my zip and it worked but can"t tell for sure.
I have a system app (in /system/priv-app) which is from an older Android and uses a JNI lib which is incompatible with ABI changes in Android 11.
I was thinking about creating a modified version of those dependencies (namely libgui.so) reverting the ABI breaks and putting it into the apps /lib folder.
Question now: Is it possible that this app loads the modified lib instead of the system lib in Android 11+?
Currently I got:
/system/priv-app/foo/foo.apk -> /system/priv-app/foo/lib/libnative.so -> /system/lib64/libgui.so
And I want:
/system/priv-app/foo/foo.apk -> /system/priv-app/foo/lib/libnative.so -> /system/priv-app/foo/lib/libgui.so
Putting the lib into the priv-apps lib folder is not enough, it works only "sometimes".
Bonus points to do this without patchelf and friends.
Edit: It occured to me that if I can make this app use a specific VNDK version (installed as an apex module) then it would also work. But how would I do that?
To answer my own question: Using a `wrap.sh` script makes this possible, see https://developer.android.com/ndk/guides/wrap-script#creating_the_wrap_shell_script
Basically: Set the debuggable flag in the app manifest and put a script with executable permissions at `/system/priv-app/foo/lib/arm64/wrap.sh` and with contents:
Code:
#!/system/bin/sh
export LD_LIBRARY_PATH="$(dirname "$0")"
echo "Loading '[email protected]' with LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
exec "[email protected]"
This involves some startup latency as the whole Java VM need to cold boot but it does work. Somehow.
In the end it didn't work for me because of sharing those structs between parts of the old and new system doesn't work and using the full older VNDK (e.g. 29) via the APEX module "com.android.vndk.v29" breaks the app_process64 (Zygote/App launcher)
I want to install 2 different versions of an app. I researched a little and found that I need to change APK's package name with APK Editor. I decompiled the APK with APK Editor and changed everything related with package name. For example The app's package name was
Code:
com.oldapk.filee
, I changed to
Code:
com.newapk.file
. Then I compiled it again and installed new apk file. But I was unable to launch the new APK file, I enabled USB Debugging on my phone and started to looking crash logs. I saw that the package name was mentioned as
Code:
com.oldapk.filee
, I started thinking about what could It be wrong, I used
Code:
ack
on linux to check which files has
Code:
com.oldapk.filee
string and saw that 2 libraries (.so files) was including the old package name. I changed them in NotePad++ (Hex Editor Addon) to new package name but this time when the app launches, I was able to see starting screen but it was crashing in 0.5 seconds after I launched it. I checked the crash logs again and then I saw that the package name was still old. Maybe the changes that I made didn't effect. How can I edit these files?