Related
OK, So I've gotten to breaking down and recompiling those pesky .dex files, but I've run into a new problem.
This is a noob question, I'm sure, but .so files look like unformatted, binary files. How do I open then, edit them, etc? I need to read whats going on in my libs. :-(
Are these X11? I'm running ubuntu 10.04 x64 - so those could be difficult.
ie - unreliable 64 bit support.
$ sudo ln -s /usr/lib32/libX11.so.6 /usr/lib32/libX11.so
Click to expand...
Click to collapse
They're native library files, so platform specific machine code I imagine. Look for an ARM disassembler. I'm not familiar with linux internals, so don't know how you find the entry points, but it obviously will be widely documented. Is it impossible to obtain the source code? Assuming most are written in C/C++, reverse engineering from the machine code is not something I'd describe as a pleasant experience. If the source was well written assembly language & not too big, it can be almost enjoyable I guess. But then TBH walking through a randomly selected programmer's source, let alone object, files scares me, in a Tim Burton inspired bad trip kinda way. If you can find the source, it will be an order of magnitude less painful.
Try IDA Decompiler, it should disassemble all so files!
Most of the libs are open source in the aosp. Some are proprietary blobs with the only solution to them being reverse engineering.
.so disassembly
i know how to disassemble it
you will need orion's easy apk disassembler and apk manager
i've tested it once and it worked, but there´s a problem, i dont know how to re-assemble
1- rename the file .so to .apk like "libtestlib.so" to "libtestlib.apk"
2- put in the folder "place-apk-here-for-modding" of apk manager
3- open script.bat (or something like this) from Apk manager
4- use extract apk option
in the beggining my images inside the lib was corrupted so i used step 5 to fix
5- use option optimise images inside to fix images
6- go to project folder and copy classes.dex file to the root of easy apk disassembler's folder
7- open EasyApkDisassembler.EN.bat and use the "DISASSEMBLY a classes.dex with smali" option
8- give a name to the folder (like "libtestlib")
9- it will create a folder (like "out_libtestlib") with the disassembled files
Orion's easy apk disassembler http://forum.xda-developers.com/showthread.php?p=5826401
Apk multi tool (almost the same as apk manager) http://forum.xda-developers.com/showthread.php?t=1310151
I've tried to open libsurfaceflinger.so from my device with 7zip, and it worked too
thats it
@gkillershots
not working
i renamed .so to .apk and used extract option but getted error :
Processing archive: C:\APKMultiTools\place-apk-here-for-modding\libnative-lib.apk
Error: Can not open file as archive
"An Error Occurred, Please Check The Log (option 26)"
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.
hello everyone
I have updated to kennethpenn's 4.5.91 Gingerbread Beta 4 (must say, it is truly a phenomally put together build !)
I have also noticed that many of the mods that i had applied to 1.8.3 have not been updated for 4.5.91, so i decided to make the changes myself.
Now, I have a pretty decent knowledge of Unix-based operating systems ( I have used Red Hat Linux, Ubuntu, SUSe Linux, OpenBSD, FreeBSD, Solaris, and now OS X) however, I would like to expand my knowledge to include Android.
The first one I attempted to do myself was the Wake on Volume Keys mod.
This is a very simple change to the android.policy.jar file, as you all well know.
For this, I used Windows XP, simply for the fact that I have 7zip and PeaZip installed on it. However, I can do all of this on OS X as well. The file archiver applications I have on OS X are:
1. The Unarchiver
2. Keka
I am going to list my method of applying this edit, and i would ask that someone with solid knowledge on this subject give me their feedback and guidance.
---------------------------------------------------------
My Method of editing android.policy.jar
---------------------------------------------------------
1. Using Root Explorer, I made a copy of /system/framework on my External SD Card
2. Mounting the Phone for USB Mass Storage on Windows XP that I have running in VirtualBox on my Macbook Pro, I moved the copy of the /system/framework directory to my Desktop
3. I downloaded smali-1.2.6.jar and baksmali-1.2.6.jar from code.google.com/p/smali/
4. I placed both of these .jar files in the copy of the framework-edited directory that I created on my Desktop
5. I renamed smali-1.2.6.jar to smali.jar and baksmali-1.2.6.jar to baksmali.jar for simplicity's sake
6. I moved the android.policy.jar file to /framework-edited directory on my Desktop
7. Using 7zip (I also have PeaZip, but for this, I used 7zip, if you think I should use PeaZip, please tell me) I extracted the files from android.policy.jar to end up with classes.dex and META-INF. I then moved classes.dex to /framework-edited so it is in the same directory as smali.jar and baksmali.jar
8. In Command Prompt, I entered:
Code:
cd C:\Documents and Settings\Owner\Desktop\framework-edited
in order to be working from the proper location where my files are located
9. Now, having Command Prompt working in the proper location, I entered the following commands:
Code:
java -jar baksmali.jar -o classout/ classes.dex
to create a new directory within /framework-edited called /framework-edited/classout
10. I then opened the /classout directory, and navigated to /classout/com/android/internal/policy/impl/ and opened the file KeyguardViewMediator.smali with Notepad
11. I used [Ctrl] + [F] to locate the line:
private isWakeKeyWhenKeyguardShowing(I)Z
12. I then looked at the lines DIRECTLY below the above line, and following the Original Post on how to manually apply this modification, I removed lines:
0x18
0x19
13. Upon removing these lines, I simply did a File -> Save As -> KeyguardViewMediator.smali and saved the file to my desktop
14. I [Cut] + [Pasted] the edited KeyguardViewMediator.smali file back to /classout/com/android/internal/policy/impl/ and replaced the original KeyguardViewMediator.smali file
15. With the edited KeyguardViewMediator.smali file in place, I went back to Command Prompt and entered the following commands:
Code:
java -Xmx512M -jar smali.jar classout/ -o new-classes.dex
To create a new file called new-classes.dex
16. Changing the name of new-classes.dex to classes.dex, I took the original META-INF file, and my newly created classes.dex files, and, using 7zip, created a new android.policy.zip archive
17. I renamed my newly created android.policy.zip to android.policy.jar, and transferred it to my External SD Card
18. Using Root Explorer, I navigated to /system/framework on my phone, and renamed android.policy.jar to 1122android.policy.jar.bac and [Copy] + [Pasted] my edited android.policy.jar to /system/framework
19. I then immediately powered off my phone, and rebooted into CWM Recovery, and cleared my Dalvik Cache, then rebooted the phone normally through CWM Recovery.
At this point, to my knowledge, I had successfully edited my android.policy.jar file and had manually added the Wake on Volume Keys modification, however, once the phone was fully booted and showing my lockscreen, I unlocked the phone as normal by sliding the slider to the right. As soon as the phone unlocked, I saw pop-ups for processes that had failed and were terminated. I'm not sure what the exact message the pop-ups had, but it was the normal pop-up message you get when a process force-closes. My only option was to click "Ok" so I clicked it, only to have another force-close pop-up.
Apparently, every single process on the phone had force-closed, BUT, the phone was waking when I press a volume key while the screen was off. I had no choice but to pull the battery out.
I decided to reboot into CWM Recovery and "install .zip from SD Card", Nottach's 1% Battery Mod / No Carrier Mod Uninstall Script
I installed Nottach's uninstall script because I hoped that it had an unmodified copy of android.policy.zip in it.
After installing the uninstall script, and rebooting the phone once again, I got to the lock screen, unlocked the phone, and found everything to be in perfect working order, just as before I edited anything,
But the Wake on Volume Keys mod was still applied!
So now, my questions / requests to all of you are:
1. Explain to me what I missed or did wrong that resulted in the force-closure of every single process on the phone prior to installing Nottach's Uninstall script
and
2. Educate me on the proper process that you developers use to apply small modifications such as this one to the android.policy.jar file, or any other related file on the phone for that matter.
My plan is now to change the color of the text on my lock screen (Clock, Date, and possibly Carrier) following this [Guide]
Any and all feedback is welcomed and greatly appreciated, as you will be helping me learn the beginnings of modding and developing
bump . . . . .
Perhaps this may help
http://forum.xda-developers.com/showthread.php?p=18226553
Does anyone have information or know the capabilities of the FM radio IC built in the HTC EVO series, do they use the same chip for all models, and are we exploiting all of its capabilities, like HD radio, etc. I see someone already has a hack for the HTC fm player that allows it to tune without an antenna/headphones. Nice, but I want more! if you have any info, i'll take whatever! Thanks!
Great forum on how to reverse engineer the HTC radio.apk
Follow here: http://forum.xda-developers.com/showthread.php?t=725870
TUTORIAL: Reverse engineering HTC FM Radio for noobs (on EVO 4G)
Okay, I'm writing this because I want to help any other newbies trying to learn how to reverse engineer. The technical details involved in this are extremely daunting, so the purpose of this tutorial is to first explain in layman terms exactly what you're trying to accomplish and what to expect. Then we'll go over the details. That way you're not completely blind going into this. I'm fairly new to the scene, so I'm not as knowledgeable as everyone else. If you see any errors in my post, let me know so I can change. I'm going to assume you know a little bit of Java, can find your way around a computer, and know nothing about Android. The techniques used should work with other Android phones. For this tutorial I'm using Windows 7, Cygwin, and my stock (not rooted) EVO 4G mobile phone.
The FM tuner for the Evo is run by a Broadcom chip: BCM4329. This chip is pretty amazing in that it does wireless, bluetooth, and it has an FM receiver/transmitter. We're interested in the FM receiver / transmitter.
Now, all android phones are based on a Linux kernel. Basically they're Linux running computers. The Android operating system is then installed onto the linux system. Every app is then run off of Android.
Android is based on Java but it is not a Java system. It uses a virtual machine called Dalvik. Google did this to get around licensing issues with Sun Microsystems. So they pretty much invented their own machine language (called byte code) for the Java language. This makes things complicated for the reverse engineer because from what I've read, once Java is converted into this machine language or byte code, it can't be converted back.
So let's rehash.
If you were programming strictly in Java, you would see these extensions:
Java source code = .java
Compiled Java source code = Java byte code = .class
Compressed file to package your program = .jar (Java Archive)
But since you're programming in Android and Dalvik, you will see these:
Java source code = .java
Compiled Java source code = Dalvik byte code = .dex
Compressed file to package your program = .apk
(I haven't mentioned this, but HTC further Optimizes their .dex code)
Optimized Dalvik byte code = .odex
I'm writing all of these down because it's very easy to get confused with all of the extensions. (for me at least!). remember how I said once you go dex, you can't go back to java? That's where JesusFreke comes in. He's a senior member of XDA, and he created "baksmali" and "smali", two programs that can convert the Dalvik code back into a human readable format. These files have extensions of .smali
Decompiled Dalvik byte code = .smali
But what can you do with .smali files? That's where this other senior member, brut.all comes in: He developed apktool. apktool takes JesusFreke's work to the next level. This program in conjunction with NetBeans, actually lets you trace through any program using the .smali code taken from JesusFreke's programs!
apktool does this by converting those .smali files into "fake" .java files that can be used by the NetBeans (program that compiles and makes java programs) IDE. I say "fake" because apktool embeds the .smali code into java files as comments. However, once you attach a debugger to NetBeans, you'll see that the debugger will follow line by line every execution statement found in the smali code!
So...... you can take the program you want, plug it into Net Beans using a debugger (using the default ddms command provided by Android SDK), and you can trace everything you do in the program. I have it connected to my phone, so whenever I push a button while running my HTC FMRadio app or unplug my headphones,I see the corresponding response to the HTCFMRadio code I have loaded in NetBeans. I can now see in real-time how the program operates from my own interactions... JAM.
Technical Aspects: How to get from ground zero to tracing HTCFMRadio?
1.) Download Android SDK - Go to google development site and follow instructions: Make sure to download the latest Java JDK. Once that is installed, download NetBeans 6.8. Unfortunately, smali debugging does not work with the lastest versions of NetBeans.
Download the "Java SE" version for minimal space
http://netbeans.org/downloads/6.8/index.html
You can follow the rest of Google walkthrough and download Eclipse and ADT plugin, but it's not pertinent to this. You're going to be using adb and ddms from the android SDK extensively, so make sure the path for </android SDK/tools> is included in the PATH variable in your ENVIRONMENT SETTINGS. To get here, right click My computer, click properties, Advanced Settings, ENVIRONMENT SETTINGS.
2.) Search for 7z and download it. It is an awesome and free compression tool that will be extremely useful. It can be used to "unzip" .jar, .apk, and other compressed formats.
3.) Get the Radio app. You can do this by going to "shipped-roms" website, downloading the latest Supersonic image, and following the directions in the unlockr tutorial for HTC kitchens at the unlockr website... (once you have extracted the files from the image, you can look in the system/app and system/framework directories to get the files listed below) or:
you can pull the following files from your phone:
Using the command prompt type (and with phone plugged in, and with USB debugging enabled on phone):
adb pull /system/app/HtcFMRadio.odex
adb pull /system/app/HtcFMRadio.apk
adb pull /system/framework ./framework
This will put HtcFMRadio.odex and HtcFMRadio.apk in the current directory and create a framework directory with more files. A couple of the files in the framework are needed for the HtcFMRadio app, but for simplicity, we're just going to pull the whole directory.
Now that we have the files, we have to make a few changes to make the app installable and to be viewable by the debugger. To do this we have to decompile the .odex format into a human readable format we can edit. That brings us to:
3.) Download baksmali and smali from Project Hosting on Google Code (google search smali).
Usually an Android application is made up of one file, an apk file. Inside the apk file is an AndroidManifest.xml file, a classes.dex file (compiled Java code for the program), and other folders. The other folders contain either graphics or other .xml files that tell the program how it should look to the user. We don't have to worry about those for now. This is important because APKTOOL only opens programs set up this way. But wait up? We didn't download one .apk file, we downloaded an .apk file and an .odex file! What gives? Well, if you right click the apk file and open it (using 7z), you'll see that it's missing the classes.dex file. The dex file for the app is actually the HtcFMRadio.odex file we downloaded. So, to make this system app more like a nominal app, we have to find a way to convert the HtcFMRadio.odex to a classes.dex file. That's easy with baksmali and smali!
Once you download goto command prompt and type:
java -jar baksmali-<version>.jar -d framework -x HtcFMRadio.odex
(Remember to match baksmali-<version>.jar with the filename of baksmali you downloaded)
If done correctly, you should see a newly created \out directory
This creates an out\com\htc\fm directory with many .smali files.
Now let's reverse the process and put it back as a dex file. Type at command prompt:
java -jar smali-<version>.jar out -o classes.dex
If done correctly you'll see a newly created classes.dex.
now, right click on HtcFMRadio.apk (select 7z and open). Drag classes.dex into the file. Say yes to the prompt. Now you have a normal apk file APKTOOL can read!
4.) Download APKTOOL from Project Hosting on Google Code and the helper apps for your OS. (If you're extracting files for windows OS you should have apktool.bat and aapt.exe). Extract (again using 7z, don't you love this program?) apktool.jar (keep it as a jar file, don't extract the stuff inside of it), apktool.bat, and aapt.exe to the directory you're working on. To make things neat, you can also delete HtcFMRadio.odex (you don't need it anymore) and classes.dex (make sure you put it in the HtcFMRadio.apk file first!)
If this is the first time you're using apktool, then you have to install the htc framework so apktool can baksmali the Radio app. You only have to do this once:
apktool if ./framework/com.htc.resources.apk
Alright, at the command prompt:
apktool d -d HtcFMRadio.apk
This extracts the contents of HtcFMRadio.apk and places them in the HtcFMRadio directory. However, there are two major differences between this content and the content created in step 3. If you go into the smali directory you'll see that instead of .smali files, you'll see .java files. And if you go back and edit the AndroidManifest.xml file, you will also see that it's in text! Android applications convert their xml files to binary format. Now that APKTOOL has converted everything to an IDE friendly format, we can use NetBeans to edit everything. The first thing we're going to do is edit AndroidManifest.xml (using notepad) and add the following:
android:debuggable="true" to the Application tag.
IT should now look like this:
<application android:theme="@android:style/Theme.Black.NoTitleBar" android:label="@string/fm_app_name" android:icon="@drawable/fm_radio" android:taskAffinity="android.task.fmradio" android:description="@string/htc_corp" android:allowTaskReparenting="true" android:debuggable="true">
This permission lets the debugger watch the program while it's running on the phone.
We are going to run into two problems if we try to install this program. One is that Android doesn't let you install more than one copy of a system app. The second issue is that if we change the signature of our system app, then we'll have to change the signatures of our other system apps as well! Ahh.... So, to get around that, we're going to trick Android into thinking we have a completely new program. We're going to do that by renaming the com.htc.fm class to com.htc.modradio class. Next step:
5.) Cygwin (or Linux virtual machine)
The easiest way that I can think of to replace strings in multiple files is by using linux. You can most definitely do it in WIndows, but I dont know how. If you let me know how, I can put it in this tutorial.
(update: you can use Notepad++ to easily find/replace strings in multiple files for Windows. You still, however, want to download Cygwin if you're going to develop with Android-NDK.)
For now, just search for Cygwin (Cygwin is a program that lets you run Linux commands from a command prompt using your Windows directories), and install it. Make sure to have the Perl option selected. You'll need Perl to make the following commands work.
Once you get Cygwin up and running
cd <to your HtcFMRadio directory>
in my case it's
cd /cygdrive/c/Users/Jerry/Desktop/HtcFMRadio
now type the following commands in this order:
this command changes all occurances of htc/fm to htc/modradio in your xml and .java files.
find ./ -type f | xargs perl -pi -e 's/htc\/fm/htc\/modradio/g'
this command changes all occurances of htc.fm to htc.modradio
find ./ -type f | xargs perl -pi -e 's/htc.fm/htc.modradio/g'
If you don't follow this order, your source code will get messed up.
If using cygwin, a bunch of .bak files will be created. Using windows search, find all .bak files in your HtcFMRadio directory, then select them all and delete them (Make sure they are only files with .bak!)
Now just rename the fm directory to modradio. It is located in HtcFMRadio/smali/com/htc
Now go to your windows command prompt and type:
apktool b -d .\HtcFMRadio modradio.apk
Now sign and install modradio.apk on your phone.
adb install modradio.apk
If you have never signed before, then you need to use keytool and jarsigner. These two files are in your JDK directory, so make sure you include your JDK directory in the PATH variable of your ENVIRONMENT SETTINGS. (To get here, right click on My Computer, click Properties, Advanced Settings, Environment Variables. Once you make change, open up a new COMMAND prompt to see changes).
cd to the directory which has modradio.apk
now type:
keytool -genkeypair
Answer all questions, then use the same password for all password prompts.
Next type:
jarsigner -verbose modradio.apk mykey
Type in the password you created in the above step. Your apk should now be signed.
Next install:
adb install modradio.apk
Success!
6.) Testing the app on phone
Go to your phone and you'll now see a new FMRadio icon next to your first. Click on it and watch it open. It should now be able to play music. Keep it open.
7.) Using Netbeans
Go into HtcFMRadio and delete the build directory created by APKTOOL.
Now open up Net Beans and click on File, New Project, Select Java Project with Existing Sources, click on Next
Select HtcFMRadio directory for Project Folder, rename Project Name to whatever you want. Let's type in ModRadio. click on Next
Next to "Source Package Folders" click on "Add Folder" and select the smali directory.
Click Finish. For a quick tutorial by Brut.all, search APKTOOL in youtube and click on: Apktool Demo 2 - Smali improvements
Right click on Libraries. Click on "Add Jar / Folder". You want to add Android.Jar. Since I have Android 2.1 loaded I went to /platforms/android-7 located in my android SDK directory.
Your project is now ready for editting!
8.) Running the Debugger to trace through program.
Next go back to Windows command prompt and type ddms. This runs the Dalvik Debug Monitor. A window should open up. In the left hand side you should see com.htc.modradio. That's our app! To the right you're going to see 2 numbers, you're interested in the one to the right, 4 cells away from com.htc.modradio. This number is a port number, and you're going to use it to communicate with NetBeans. (In my case it is 8603)
Go back to NetBeans and click on Debug, Attach Debugger.
In the host field type: localhost
In the Port field: type in the second number you saw. (8603)
If everything is working you'll see a bug appear next to com.htc.modradio in the Dalvik Debug Monitor. Look at the bottom bar of NetBeans for feedback. If you get errors make sure the numbers match, or try port 8700 and make sure you select com.htc.modradio in the Dalvik Debug Monitor. Port 8700 is the default port used for whatever program you select in Dalvik Debug Monitor.
9.) Setting a breakpoint
I'm making this a seperate step because it is completely arbitrary. When creating a break point be sure to follow this rule:
You must select line with some instruction, you can't set breakpoint on lines starting with ".", ":" or "#".
Rather than looking for a spot to breakpoint, though, I'll tell you where to put one so you can quickly see how the debugger traces through the code. You aren't "REQUIRED" to do the next step, but if you want to trace you have to put a breakpoint somewhere.
In Net Beans click on the Project tab, click on Source Packages, com.htc.modradio, and then doubleclick on BroadcomFMTuner.java
We're going to insert a breakpoint. Scroll down to line 3226 and on your keyboard press: CTRL-SHIFT-F8, select line in dropdown box and hit ok. (To keep it simple, I usually look for "invoke" instructions to set breakpoints at)
Now go to your phone and click on the physical "back" button on your phone. This will clear the radio,(you should still be able to listen to music). Drag your status bar down. You should see a radio icon. Click on it again. The radio backgroudn will appear, but you wont' see any text or anything. Now go back to your netbeans application. You should now see debug options highlighted! Click on Step Over (F8) to step through!
Great work on other HTC phones, not sure it applies here...
Sounds like HTC uses an all in one bluetooth/fm radio chipset... possibly broadcom, this fella has gotten somewhere!
follow here: http://forum.xda-developers.com/showthread.php?t=497977
APP:17FEB10:RDS FM Radio R&D: Get radio text, Alt Freqency, free TMC etc
Microsoft hasn't defined a tuner API for Windows Mobile platform (yet) and manufactures such as HTC do not publish their API for FM radio.
GFMAPI is an FM Radio interface that designed to be used on different models of Windows Mobile devices.
It makes all FM RDS based applications such as Radio players, Radio Alarm, TMC navigation works on different devices.
What's new?
Download EtenTest and GFMAPI 1.0.
Currently it works with M900 and M800, tested with PowerRadio and hyperGPS.
This is for Eten/Acer devices only.
End-User and application developers (Downloads)
User should try to use the GFMAPI in the application package because it may need to signed with privileged certificate and version of interface may be different.
App Developers can find FMAPI.h and a test application APITest in the GFMAPI for HTC devices 1.6. Source code is included to help your development.
The interface is defined in C language with sample code.
Thank for NetRipper made a .Net CF library for GFMAPI.
Note: the latest FMAPI.h is in GFMAK and the GFMAPI will be updated. They only has minor differences.
Supported Devices
* BRF6350 Chipset:
HTC Diamond, HTC Raphael (not CDMA), HTC Blackstone, HTC Polaris, HTC Topaz, SE Xperia X1
NOTE: if your X1 has new media panel that integrated with FM Radio function, you may have to disable this panel (I don't know how).
Download GFMAPI for HTC devices 1.6
* BCM432x Chipset:
HTC Rhodium, HTC Leo, HTC Mega
Supports radio functions if renaming FMSDKWrapper.dll to FMS_API.dll with the above driver. RDS data cannot be received.
We are working on this device. Related thread: FM Transmitter on HD2
* SI470X Chipset:
HTC Artemis: NOT supported.
Samsung Omnia: Samsung i9x0 Omnia
Samsung Omnia II: GFMAPI.dll for Omnia II and its Cab format This is an excellent work done by phjz.
Eten/Glofiish/Acer M800/M900/V900/X900/X650/S200: see "what's new". Please help me test it.
Device adaption developers
Generic FMAPI Adaption Kit will help you implement the driver for your device. Use APITest in the GFMAPI to test your driver.
Please read readme.txt in the package. Feel free to ask me if you need help.
If you have a device that is not supported by GFMAPI
I currently only have a HTC Raphael so I need your help to get your device supported.
First of all, you should Search in this Thread to check anybody posted it before.
Extract FM radio related files and upload to the forum.
Note: You cannot simply copy files from/to device. You need dump the ROM then extract files from the ROM. Search this forum to find how.
If you have good VC++ and IDA pro with ARM skills, please join us to discover FM Tuner API on those devices then make RDS application working on your device.
* HTC Rhodium/TP2, HTC Leo/HD2, HTC Mega/Touch2:
http://forum.xda-developers.com/show...&postcount=783
http://forum.xda-developers.com/show...&postcount=813
http://forum.xda-developers.com/show...&postcount=794
Rhodium Test
Current status: 6Fg8 identified that raw RDS data is in the Broadcomm BTTray process, not in the FmRadioSDK.DLL. Still not trace it down to function/module level.
* Artemis:
Artemis Test
Far far away from any progress and not many users.
BBCBBA uploaded FM radio related file for Gigabyte GSmart S1200. This device supports RDS by using deviceIoControl directly communicating with the driver. I can see it is possible to make a GFMAPI driver just need a lot of effort.
Applications based on GFMAPI
* FM TMC driver for navigation: Beember's HyperGPS.
* A powerful RDS FM Radio application: 6Fg8's Power Radio
This project focuses on RDS API now. TMC related topic has been moved to the TMC thread because it is too attractive and posts will flood the thread.
Origin research project
Many people ask questions related to FM radio in the forum have been solved by this project:
* Does FM Radio supports RDS text and traffic information?
* Does FM Radio supports more than 20 saved channels and give a friendly alias, such as "BB Radio 4" rather than 920.2MHz ?
* Does FM Radio supports automatically or manually change frequency when signal getting pool during traveling?
* Does FM Radio support RDS-TMC traffic information for navigation system?
The answer is yes. The Bluetooth/FM radio chip BRF6350 on your phone is very powerful but HTC FM radio only provides basic functionality.
Unfortunately HTC doesn't publish FM Service API to us.
So I disassembled FM player by using IDA pro and know usages of FMS api.
After a week sleepless night, I wrote my FM radio tool, xFMRadio, utilizes most functions provided by FMS API, provides RDS and other data for further research.
With help from this thread, we have exposed most secret of FM and RDS system on HTC devices and we can make useful applications now.
This application is written for research so that UI is not nice. It only works on BRF6350 based HTC devices.
Download xFM Radio v0.4
If doesn't have sound on your device, try xFM Radio v0.4B, which removed audio volume initialization.
Brief user guide for xFMRadio
Default settings: Audio Source: 1 (earphone), RDS =1, Verbose =1, AF = 1. ( but I don't know if automatic AF is working. have to verify during long distance traveling.)
Verbose: 0 -no log; 1 - status only; 2 - TMC raw data; 3 - all types of log
Row 1: Input argument. Set Frequency in KHz, AF list: alternative frequencies for the current station.
Row 2: Frequency, station name, Band: World/Japan - use this to listen police station etc
Row 3: Signal Strength, Stereo/Mono, UTC Date/Time (update once per min if supported)
Row 4: -100KHz, Previous Channel, Next Channel, +100Hz, Mute, Mono/Stereo
Row 5: Headset/Speaker, De-emphasis, Stereo blend
Row 6: Radio Text
Row 7: status such as Music/Speech, TP, TA, PTY, TMC etc
Check if the channel support TMC: ROW 7 should display [TMC]. You can see TMC data by setting the top left input box to 2, and click on Menu->Verbose.
The current xFMRadio v0.4 does not display RDS raw data anymore.
You can use Save log menu to save log data.
FMS API version is displayed in the About dialog. Mine is 1.2.
xFMRadio 1.4 Debug...
it does not support HD radio.
Solved...
Fair enough... I was getting that impression anyhow, especially with the lack of responses. One could only dream that with all the digital aspects of modern comunication (bluetooth, cell, etc), that they would throw in HD digital FM along side it... but as I can see, this only fits in well with every other aspect of modern lackluster industrial corporate innovation. Peace out!
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.