Database Users

[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!

nice tutorial

Nice tutor! I'm glad that finally someone is interested in smali debugging feature ;-)
About package name changing: I must warn you, that this isn't always that easy. It's advanced task, you must understand, what are you doing - otherwise you will get FCs for some apps and you won't know, why. And you don't have to change Java classes package name, so actually changing com.example.android should be enough - there is no need for changing com/example/android and dir names.
And I have few words about the background/theory: dexes, smali, (de)compiling, etc., but I will write them tomorrow

So I don't have to change the directory names for all of the invokes? Which means I don't have to rename the directory either? That sounds much easier. So you're saying to only replace the name in the application tag in the AndroidManifest.xml file?

Wow I'm a noob
Your badass tutorial just made me realize how much further I have to go. Great work!
BTW, if someone could figure how to make use of the FM transmitter and create an FM modulation app I think that could be popular. Not everyone has cars with input jacks and I know I really could of made use of it for my vacation I just took.
Once you understand how the software interacts with the Broadcom chip it shouldn't take too much should it? I would envision something working just like wifi tether does. No need to turn on the radio, the app just takes control.

Cool! Thanks! Will this work with eclipse also?

oikjdfkrjhr said:
Cool! Thanks! Will this work with eclipse also?
Click to expand...
Click to collapse
According to Brut.all, no.
"Google smali debugging - you'll find an article written by Brut.all"
Eclipse can open the files, but certain workarounds have to be done to get the same tracing to work.

A FM Transmitter that is able to transmit audio to a receiver without any addition cords hardware etc would IMO make the EVO 4G Un-Stoppable!!! I'll donate to support the dev/s in this effort

Will this get FM Radio working on any android phone with that broadcom chip?

Wow, great tutorial. I was looking for the hitch-hackers guide to my new galaxy and I think I found it. Cheers

Thanks this is great. I almost got it 100% working. But there's one problem. I'm debugging some other apk. And I can't set any breakpoints because, since the apktool made fake java files, all the code is comments, so there's no place to set any breakpoints since there's no real executable code!
Help how to get around this?
At the beginning of a class I tried to add something like... int a=0; while keeping the same amount of lines... just before comment start...
Code:
package com.example.app; class MainActivity {
int a = 0; /*
.class public Lcom/example/app/MainActivity;
.super Landroid/app/Activity;
.source "MainActivity.java"
and put a breakpoint there, but it still says its not an executable location.
Any ideas? This is cool and I'm so close with your great tutorial. Thanks!

oikjdfkrjhr said:
Thanks this is great. I almost got it 100% working. But there's one problem. I'm debugging some other apk. And I can't set any breakpoints because, since the apktool made fake java files, all the code is comments, so there's no place to set any breakpoints since there's no real executable code!
Click to expand...
Click to collapse
http://code.google.com/p/android-apktool/wiki/SmaliDebugging
I tried to use Eclipse, but seems it forbids to add breakpoint on unknown (commented out) line :-/ I workarounded this and added breakpoint, then I was able to debug normally, but you should treat apktool debuging as unworkable on Eclipse - at least until someone will find some solution.
Click to expand...
Click to collapse
And actually midnjerry said this to you just few posts above.

neomagik said:
Will this get FM Radio working on any android phone with that broadcom chip?
Click to expand...
Click to collapse
Unfortunately not.
Refer to IntersectRaven's posts regarding enabling the FM Tuner for the Nexus One. He needed to create drivers for a custom Linux kernel to be used with a Desire ROM.
Smali debugging is important, however, because it allows developers to learn the code that implements the "undocumented" hardware for their phone (in this case, HTC phones with a working FM Radio app).

oikjdfkrjhr said:
Thanks this is great. I almost got it 100% working. But there's one problem. I'm debugging some other apk. And I can't set any breakpoints because, since the apktool made fake java files, all the code is comments, so there's no place to set any breakpoints since there's no real executable code!
Help how to get around this?
At the beginning of a class I tried to add something like... int a=0; while keeping the same amount of lines... just before comment start...
Code:
package com.example.app; class MainActivity {
int a = 0; /*
.class public Lcom/example/app/MainActivity;
.super Landroid/app/Activity;
.source "MainActivity.java"
and put a breakpoint there, but it still says its not an executable location.
Any ideas? This is cool and I'm so close with your great tutorial. Thanks!
Click to expand...
Click to collapse
if you're using NetBeans, just keep trying to insert breakpoints at every "invoke" type statement.

A really interesting thread. Thanks for sharing your knowledge with us. A topic like this should have its own Forum like ‘Android Engineering Tutorial’. We need more tutorials like this one!

Bluetooth Driver Files released by HTC!
Just went to
http://developer.htc.com/
Bluetooth driver files released! We should be able to better control the radio now.

Any progress? I'll donate to the first person who gets an app to broadcast my music to my radio.
Sent from my HTC EVO using XDA App

@midnjerry,
sorry if this is way off topic, but it does deal with the fundamental aspects that you have established here.
Can I use this method to reverse engineer the Google Voice app, so that I can have the same program installed twice for my two different Google voice accounts?
I just want to name the application something else, so that I can install it twice with two different sign in names.

reekotubbs said:
@midnjerry,
sorry if this is way off topic, but it does deal with the fundamental aspects that you have established here.
Can I use this method to reverse engineer the Google Voice app, so that I can have the same program installed twice for my two different Google voice accounts?
I just want to name the application something else, so that I can install it twice with two different sign in names.
Click to expand...
Click to collapse
Yeah, I think you can do that. Just change package name of an app to something else.

Brut.all said:
Yeah, I think you can do that. Just change package name of an app to something else.
Click to expand...
Click to collapse
@Brut.all
Can I do that in Eclipse or do I need to use need to use Smali Debugging? Just asking because I am not looking to debug the program only install it twice.

Thoughts on native binutils

I did an extensive search to try and find if anyone built binutils to run native on android and came up empty. I did, however, find someone who claims to have gotten Fortran to compile and run on android (specificimpulses.blogspot.com/2011/01/my-android-speaks-fortran-yours-can-too.html) He seems to have problems at the linker phase. I was wondering what people thought about the possibility. I would like to mess around with arm assembler on my android device whilst out and about...

So this is awesome, I set the build and the host environment to arm-android-eabi and I magickally got out i686-elf binaries that run on my linux workstation...amazing! I didn't know that cirrus made a processor with the smarts to automagically execute arm-android-eabi target code when presented with it...
../binutils-2.19.1/configure --prefix=/opt/compilers/gcc/native-android --build=arm-android-eabi --host=arm-android-eabi --target=arm-android-eabi --with-sysroot=../android-ndk-r5/platforms/android-8/arch-arm
So in addition to that I tried to wipe my path clean and point only to the binutils and gcc under the ndk-toolchain directory but it gave me the infamous 'cannot create working executable'....wow? ya think, config?
Anyone know how to turn off the test for building working executables when cross compiling, or perhaps to point in the configure script options where to find crti.o which is what was missing at the link phase?

Strike that, I mean Via. my workstation uses a via processor, not that that is important here...

Success! Well, in as much as I was able to compile binaries of some of the binutils and run them on my g-tab. I haven't tried to assemble a piece of code and link it yet. What I did was use the info in android-ndk-r5/docs/STANDALONE-TOOLCHAIN.html
which suggested that I run:
$NDK/build/tools/make-standalone-toolchain.sh --platform=android-5 --install-dir=/tmp/my-android-toolchain
which created a standalone toolchain self enclosed. I then set path carefully so I was pointing to the toolchain directory's bins. Then I ran configure using
../binutils-2.19.1/configure --prefix=/root/android --host=arm-android-eabi --target=arm-android-eabi
and made a few comments to code--real hacks like casting &stat.time to a time_t * and changing #ifdef tests to force inclusion of the correct code. I also had to link:
ln -s /root/my-android-toolchain/bin/arm-linux-androideabi-ar /root/my-android-toolchain/arm-android-eabi-ar
just because I was tired and didn't want to f**k with the compile script to get it to point to the correct set of toolchain binaries. In the end, I copied over nm-new, ld-new, as-new, and strip-new to my gtab and ran them and got errors that I expected like:
as-new aa.s
Error: can't open aa.s for reading: No such file or directory. Indicating that at least gas was running native on my gtab...
Of course, that is a first tiny step....

Btb, I had to unzip into the /data directory on android for the executables to run. Ran them in a terminal emulator...

[FM TRANSMITTER] (dev needed)

this is an older tutorial i found for the evo way back. it needs to be updated..
this could possibly work on other android htc phones to that have the fm transmit capability....
the evos Broadcom chip has a built in fm receiver and also a transmitter.
according to some threads and diagrams ive seen the transmitter does have a power source, it just doesnt have and software code to actually work.
like hdmi the hardware was there but there was no code set up, therefore we didnt have full hdmi out. it had to be built from scratch.
the hardware for the fm transmitter is there we just need some one to build the code for it.
some one please take this on!!
This tutorial was originally posted in > android development and hacking > android software development.
i am reposting it here in the evo forums for guidelines
its a nice tutorial but its old. i think it was for android 2.0 ive followed the tutorial but i couldnt get it working, and i by no means have the experience to switch things up and get it working.
[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!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
i found a few things.
http://pdf.eccn.com/pdfs/Datasheets/Broadcom/BCM4329.pdf
http://www.broadcom.com/products/Bluetooth/Bluetooth-RF-Silicon-and-Software-Solutions/BCM4329

I didn't read all of this but I have to mention that byte code is not a type of machine code..
byte code is what is created when you compile a java file. The JVM or dalvik-VM in this case, then converts this byte code to machine code at run time.

[Toolkit][Windows&Linux(Wine)] Already Setup Adb/Fastboot Environment and Installer

[Toolkit][Windows&Linux(Wine)] Already Setup Adb/Fastboot Environment and Installer
First, I take donations.
Second, see the 2nd post about Windows XP compatibilty.(XP requires that the tool be used on a usb drive or a partition that does not contain the current running operating system)
(For the other OSs it works fine on the drive with the running OS) (For Linux see the last post)
Third, XP users that don't have a removable drive available can use the XP-ONLY version on the local drive.
Fourth, read EVERYTHING here on the first and last post.
Fifth, adbClient is a download, unzip, connect to phone package that requires nearly no setup at all allowing you to use the android debugging bridge.
If you want to install adb and fastboot use the "instadb" command.(If you get an access denied error, you must have the administrator password and check your typing)
ANSWERS TO YOUR PROBLEMS:
If you want to update but continue to keep automagically using your work folder: you must copy the Work folder into the folder above the updated bin folder.
Like so: extract the new package. copy the old work folder into the new extracted folder. your work folder should sit right beside the launchadbclient script and the updated bin folder.
This tool can be moved anywhere alongside the work folder
HOW TO USE:
To launch the script extract the zip and run LaunchadbClient by double clicking on it.
Type "xt" without quotes to see a menu for commands.
Check out some package management by typing apk.
To install adb and fastboot to the system without fiddling with environment variables use the instadb command.
DRIVERS:
Visit this link first to enable usb debugging:
To utilize the Google usb driver extract its zip and right click the android_winusb.inf file and hit the install option.
If Google's drivers dont work or you have no drivers or adb doesn't mention any connected devices at the top of the window then you need to visit your manufacturers website for your phone's driver.
Here is the pdanet all purpose adb driver that is pretty much fail proof. if you have any issues with it uninstall it and try another one from below.
If all three of those driver suggestions are not applicable then read the "OTHER DRIVERS" category:
OTHER DRIVERS: The Universal Naked Driver is a good one. Or you can follow this exceptional tutorial for all purpose adb driver installation (I am not responsible for any issues with the tutorial, I just found it.)
I recommend Adb Konnect from the play store if drivers are a problem.
Sometimes your usb cable is keeping you from using adb, so try changing cables.(this actually just happened to me with my samsung usb cable and i ended up using my nexus 7 one instead)
DESCRIBE THE TOOL:
This tool is here to make my life(and your life) with adb easier.
It's the windows command line on steroids.
It is made for being put on a flash drive and being used on different computers.
Especially if you are using someone else's computer but want to keep an environment with your tools and files in it where you could just load it up from a flash drive.
It uses shortcuts for tools including and can autoroot etcetera among other features. This tool is free to use and distribute\modify with my name attached. It contains a presetup adb and fastboot environemnt and has extra binaries\scripts for working with the windows command line and android easier.
Overall it makes interfacing with android over adb much more interesting.
GETTING THE TOOL AND INFO:
1.9.5-XP_ONLY is for the Windows XP desktop only.
Version 3.2.9 is the latest stable release, Use this version please. Thanks for your interest.
If you want to take a snapshot of the latest development go here.

ANNOUNCEMENTS: I now have a donate button if you want to see more development.
I don't support 2.2 or 1.9.5 anymore. Only 3.x.
KNOWN ISSUES: tar might not work.
apklist won't auto exit because of the more pipe. just use control-c for now to unfreeze it
Some of the scripted adb commands stall.
EXTRA INFO:
The only thing that I own in the zip is the scripts. The copyright notice and license for android sdk and included files is included as Notice.txt and Noticeforadb.txt in the LicenseForAdbEtc.zip
With this tool their is no need to install adb or fastboot on your computer just run the script.
If you get an antivirus warning its because of the Zergrush, Psneuter, Framaroot, and ExynosAbuse root exploits.(And the Hstart binary sometimes)
I am not malicious anyway.(You can read my code easily)
You can copy the folder wherever you want. (I made sure it works)
Just don't have anything named bin in the same directory as the launch script.
EXTRA EXTRA INFO:
This tool is meant to be an extension to the command prompt and will pass anything that it doesn't understand over to the command interpreter.
It works in Wine. Extra launching needed. (See last post)
This is a tool for beginners and advanced users however beginners need to learn adb's commands before using this tool.
It will root 2.x and up(Support added for newer android versions). I suggest installing Supersu also.
Tool works on all windows versions: Wndows XP and above.
You are no longer encouraged to use the XP only zips for Windows XP.
For XP: If you use the tool on the local drive it throws errors however if you use it on a usb drive then it works fine
If you need to use it on a local drive then you can use the old win xp only version.
Windows 8 and 8.1 run the tool perfect.
Use the exit command to exit the tool.(It auto kills the adb server)
Links to third party tools used or included:
Recommended download: ApkMultiTool. Another recommended download: Mediatek flashtool
Framaroot
Exynosabuse
strace
Android Sdk
Stahlworks Binaries : Open source
Win32 Busybox Binary(pclouds) REPLACED WITH Tigress busybox
Freac Not in Slim builds.
Stericson Busybox Android Binary
Sqlite3 android
Supersu
Hstart for use with startup sound

This info applies to testing, finals, and anything else.
FUTURE CHANGES:
Code:
add start settings app and browser app command using am start
add intent disabler (Disable an app's MAIN so that it can be hidden from drawer and be unstartable "locked" )
add the ability to make img of a specified size and store it in /data and even loop mount it to sdcard
add the ability to live image the system and data partitions.
remember to make the user specify the filesystem for sdcard image
I need to backport all bug fixes and improvements to 1.9.5_XP-ONLY
use vbscripts to automate key sends (control-c) Not done due to batch sucking.
add su -c sh to start up root shell on device for use with things like strace. Not done due to batch sucking.
add if blank adb devices say you must connect with either cnt or plugging your device in. (But still show the output)
add variable for work folder
Migrate all custom data text files(hist,clr) to config folder in Work\ but keep defaults in regular bin folder.
add adbkiller script to the desktop by question on first startup.(Store info text file in userbin) (User variable then desktop)
clean output on adbp and adbps plus
change all du -smc to du -sm for single push/pull
add ability to do several pushes and pulls with du -smc in one operation
add parameters to adbp and adbps
add if not defined to destination and source file in adb and adbps to allow for hitting enter to quit in the middle of setting up a push or pull
cleanup and organize xt
include some sort of nano for windows binary for command line editing
include a compact notepad++
Remove extra binaries such as zip and unzip to point to busybox linkers (Skim through code to change "zip" to "busybox zip" or "sfk zip")
Pass all inputted commands to a script that can parse arguments before they are sent to they're respesctive scripts or binaries. (Mostly to catch /? and run it without call)
Remember to update adbClient Launcher to point to new folder.
Add first time greeting, explaining commonplace commands and the various folders using java.
add batch snake from [URL="http://www.dostips.com/forum/viewtopic.php?t=4741&mobile=on"]here[/URL] [URL="http://www.dostips.com/forum/viewtopic.php?t=4741&mobile=on"]and here[/URL] for fun
learn some design tips from batch snake.
add adb closer background script for when someone closes adbclient with the windows close button.
add ability to root adbps and adbp or just enable insecure adb debugging
setpass not using admin privileges, add call capability to use instadb privilege elevation code as an elevation module for the rest of my code)
search for commands

CHANGELOG:
This changlog is deprecated for the commits page on my github: https://github.com/lgrootnoob/adbClient_EnvironmentandTool/commits/master
Code:
With 1.3.1 adb/fastboot has been updated from platform-tools to rev. 19(Previously rev. 18.0.1)
Split 1.3.1 into xp only and vista up packages
Add a work command that will send you back to the work folder no matter where you are.
See third post.
Removed a couple of the zips in the post to make the download list easier.
Made license a separate download.
Add unroot function.
Implement extracter with a windows tar exe for extracting images from a tgz.
Make adb/fastboot installer for system. (%WINDIR%\system32) (To install the binaries just type instadb and follow the prompts)
(Installing adb and fastboot to the system makes adb or fastboot dependent applications operate without the need to setup complicated environment variables.)
(Before you would have had to make the environment variable point to the folder conanaining the binaries then you would have to check to make sure its setup properly. this will eliminate that issue)
Add the launch script into the package and update instructions. (JUST added launcher to make starting it easier.)
Issues with my implementations of certain processes inside the script.
Fixed updater typo.
Added sfk binary from stahlworks.(VERY useful tool [URL="http://stahlworks.com/products.html"]http://stahlworks.com/products.html[/URL])
Added zip and unzip binary from stahlworks
Added latest usb driver from google.
Add the launch script into the package and update instructions.
add win32 busybox and remove gnuwin32 tar command.
Apk install from file. And apk uninstall and apk installed lister. pm argument sender. apk command for menu
Version change in updater code. but server on mandatory downtime for a week.
Fixed problem with missing dlls in system32 install for adb and fastboot
^Fixed bugfix in 1.8 Whackamole:)
use nul to detect dirs
everything that is passed to cmd is called.(In 1.8.2+)
Added ls links to busybox and can use params like ls -l
Made links to busybox with batch files and parameters.
Added md5sum binary.
Make attempt at auto pushd popd implementation. To use this feature just cd to wherever then type back to go back.
New XP local drive version. (Remember that XP can run any version from a removable drive or drive that isnt the partition with the running OS on it.)
FIXED - Output cleanup and implementation of code rendering inner shortcuts unuseful)
add extra bin for user binaries in Work\userbin
added addpath command to append the current folder to the temporary path
Fix another bugfix.
testing version released so the version number on my server will not be updated until I have personally evaluated these builds for a couple of days.
implement pushd popd into my code
add windows tools from knife into adbclient.
made repo command.
added bin2hex binary
added deveject binary
move %clrsnd% %clrval% above the doneloop subroutine so busybox's ls command can properly highlight file names.
only use %clrsnd% %clrval% when needed (pretty much the same as I have done with adb devices and fastboot devices)
added zipalign binary
update updating system to live (ON)
add repo style p2p apt-get system called Gridlock(Thought of the name myself) (not p2p yet :( )
moved extended menu out of code and into a file to help clean up stuff.
add bash link for busybox
fixed up repo script address(dynamic)
added mkfloppy
fixed bug in apk installer code.
removed cmdmenusel and trashed the idea of using it for the preffered java dependency setup.
fixed small bug
changed exit for future dynamic handling of shutdown disk operations.
cat command takes over the beginning of the next echo so it has an echo. in its code.
Deprecated every addpath script and moving to modular addpath userspace script.
Also fixed varname bug in addpath script that made it worthless
Commented my info in.
fixed unrooting issue.
piped apklist to more.
Comment code/subroutines etc. and use whitespace to make it easier to read.(Half done, it needs more work)
everything below is for unreleased 2.3 version.
Strace helper
added goo.im opener
added audio converter freac (Freac has source code available freely on their webpage)
Remove just a couple lines from the inital output to make it fit the command prompt screen.
strace installer (chmod 777 adb push and su -c sh) for work with strace.
add data /T to top of script
added frontend for deveject binary because it is too complicated
make cnt a command that will take params so you can type cnt 192.168.1.81
^if no params are given it will ask for ip address
added send command to strace in testing
merged strace bug fixes into testing
fixed another path bug in testing
code now becoming very modular with me using scripted functions as commands in other scripts.
lgctnp always out to work dir now
fixed 'regression' in hist (Accidental reference to deprecated function broke it) (ALSO: fixed in clr)
project no subroutine/if statements: instead of using if statements on the users input on the main loop I will use batch files in my path that have the name of the user's command.
^This eliminates "" crashing.
add hash check for transmitted file. (Needs md5sum binary for android.) (Make it a question)
add busybox installer
add quick fixes menu for things like accidentally deleted launcher, etc.
fixed issue with busybox android binary got deleted.
added: 'mode con:cols=100 lines=50' for big console
fixed up lgctnp and dmsgnp code
add dmesg
quick patch for scroll height (It will be tweaked more in the future.)
[B]3.1.5 will be a temporary bug fix and binary addition in preparation for.......[/B]
make cd freac* point to full path instead
add startup Splash screen for christmas holiday
added Framaroot to rooter
added exynosabuse to rooter
adbsl is accidentally pointing to old doneloop subroutine and needs to be pointed to EOF
move from old pclouds busybox binary to [URL="http://intgat.tigress.co.uk/rmy/busybox/index.html"]tigress win32 busybox[/URL]
update android sdk dependent stuff (platform tools have been updated to 19.0.1)
update su and supersu
change call adbclient to call start adbclient so the intital launcher is exitable
java detector added
[B]3.2 Released![/B]
fix old subroutine pointers in devej
add startup sound
[B]3.2.1 Released![/B]
added screenshots to OP
patch instadb with set "installmaybe="
add size check for pulling/pulled or pushing/pushed files on adbp and adbps like the md5sum checker.'
update busybox/adb/fastboot/freac/anything else/check and update apk versions.
add question to adbp and adbps for redoing the push/pull operation if the user notices the hashes don't match
[B]3.2.4 Slim Released![/B]
change release naming scheme from final to only use final name for final release in 3.2.x, 3.3.x etc.
fix adbp to do you to "Redo pull operation?" instead of "Redo push operation?"
cleanup root.bat output organizing exploits by android version.
change subroutine pointer in ex from doneloop to :EOF
[B]3.2.5 Slim_ Maintenance Released![/B]
Google's usb driver updated to revision 9.
link every busybox applet
store busybox whoami value in variable and then put it into $~: set /p command
pointed launcher directly to bin folder name
updated binary and application dependencies
[I]Made some progress in porting a new xp desktop version: the path names need to have quotes around them.[/I]
[B]3.2.6 Slim Released![/B]
[I]INFO: adbClient is somewhat usable in Wine.[/I]
Framaroot and sfk updated.
Tigress busybox updated.
Fixed qfx mounting issue.
android busybox binary updated
updated supersu apk and su, [B]NOTE:[/B] It is ton of work to support 4.3 rooting but I will do it soon in 3.2.8 I will have to bundle cydiaimpactor somehow.
[B]3.2.7 Slim Released![/B]
2.2 removed(cached locally, so it will be unavailable. leaving the remnants of 1.9.5 even though xp is not supported by microsoft anymore)
[B]3.2.8 Released![/B]
GITHUB REPO: [url]https://github.com/lgrootnoob/adbClient_EnvironmentandTool[/url]
updated to usb driver v10
[B]3.2.9 Released![/B]

Bump:
Bump, any dev can use this tool to have their rom users debug the roms that they make easily if they like.

I have done enough testing to know that this works in Wine on Linux pretty good now.
However, special launch instructions are needed.
cd to the adbclient bin folder(Currently bin-3.2.6-Slim) and use the command:
Code:
WINEDEBUG=-all wine cmd /c adbclient.bat
- all on one line.
Adbclient should be started and you can connect to your phone wirelessly with cnt *.*.*.* (Insert ip address to the left).
Happy Linuxing.
EDIT: Bash port coming soon to a Linux computer near you.

Latest use of this tool as a library/environment for making a rooting package for phones.
http://forum.xda-developers.com/showthread.php?t=2738977

The changelog here will now go unmaintained in deprecation for a github repo: https://github.com/lgrootnoob/adbClient_EnvironmentandTool

3.2.9 released.

Lgrootnoob said:
I have done enough testing to know that this works in Wine on Linux pretty good now.
However, special launch instructions are needed.
cd to the adbclient bin folder(Currently bin-3.2.6-Slim) and use the command:
Code:
WINEDEBUG=-all wine cmd /c adbclient.bat
- all on one line.
Adbclient should be started and you can connect to your phone wirelessly with cnt *.*.*.* (Insert ip address to the left).
Happy Linuxing.
EDIT: Bash port coming soon to a Linux computer near you.
Click to expand...
Click to collapse
I don't like bash. :/

pcwizzy37 said:
I don't like bash. :/
Click to expand...
Click to collapse
bash is necessary for using some build systems to compile android source code. If the OP wishes to donate his time and efforts , I'm sure that an easy installer will be useful to someone. I believe that this tool deserves more response than it has received.
Sent from my LGL15G using Tapatalk

ibub said:
bash is necessary for using some build systems to compile android source code. If the OP wishes to donate his time and efforts , I'm sure that an easy installer will be useful to someone. I believe that this tool deserves more response than it has received.
Sent from my LGL15G using Tapatalk
Click to expand...
Click to collapse
I have no idea why I said that back then. I have been dailying Linux for years now and BASH is what I primarily use, also it's wierd because at that time was when I was migrating to Linux.

[TOOL][WIN]DroidShell - Windows Shell Integration for Android Development[02/02/16]

Greetings, and welcome to the home of a little set of utilities I'm calling "DroidShell".
What it is:
DroidShell is my attempt at bridging the gap between the various android utilities used for ROM modification and the Windows explorer system. It is a series of scripts that are automatically associated with .apk, .jar, and .iso files so that they are automatically decompiled on double-click or enter. Additionally, when a file is decompiled, a corresponding .dcp, dcf, or dci (decompiled package, decompiled framework, decompiled image) file is created, which allows for automatic recompiling, as well as optional cleanup, or resigning.
The goal of this project is pretty simple...to have all the tools needed for ROM work in one place, and have them easily accessible without having to have eighty command windows open or to have to go through a chain of commands to create a usable apk/jarfile.
Features:
One-shot setup. Extract the files, run install/installer.bat, and all of the necessary file associations and paths are created.
Batch terminal integration - provides integration for adb, fastboot, apktool, 7zip, zipalign, oat2dex, unpackbootimg, repackbootimg, baksmali and smali in windows command-line interface from path.
Automagic association with common android filetypes for decompilation.
Custom placeholder files - dcp, dcf, and dci - for packages, framework, and image files. Allows for automatic recompiling, and optional signing and cleanup of decompiled files.
Recompiled apks and jars are automatically repacked with modified files while excluding androidmanifest.xml, meaning signatures are unaffected.
For modifications requiring androidmanifest be changed, you can right-click a .dcp file to recompile with signature.
Auto-detection of framework-res file with prompting to install.
Popup dialogue boxes for errors and alerts.
(NEW) Right-click to decompile to java code. This cannot be recompiled, but is great for researching more complex mods. (Can also be invoked by using the command dj filename.apk)
(NEW) Support for sparse image system -> .img conversion.
(NEW) za command for zipaligning apk's.
(NEW)
Download:
https://github.com/d8ahazard/DroidShell/archive/master.zip
Source:
https://github.com/d8ahazard/DroidShell
Instructions...
You need the Java Runtime Environment (RE). Get it here.
Extract to a folder somewhere. Spaces in the path are probably not good. I put it in C:\DroidShell
Browse to the folder. Go into the install folder. Run installer.bat. (Installer needs admin priveleges. It will prompt for them, but in some cases, you may have to automatically run as admin)
Reboot.
You should now have shell integration. APKs, Jars, and .img files will automagically decompile.
It's late, I've been working on this all weekend...but it should be good to go. Please let me know if you have any thoughts.
CHANGELOG:
Code:
02.02.16 - v2.0
Update smali, baksmal to v. 2.1.1.
Add shell script for oat2dex (not implemented in context menus, just avaialable for now)
Update APKTool to latest version
Add dx.jar - for converting java classfiles to .dex (just available for now)
Add ext4 and ext2 tools - For manually unpacking images if needed. These are GUI based, not my work.
Add rimg2sdat - For converting .img to sparse (Not implemented yet)
Update sdat2img to latest version by xspirit, added python to installer as required.
Add zipalign function (Not implemented, can be called via "za filename.apk"
Add decompile to pure Java:
This utilizes a few tools to take apk's and jarfiles and decompile them to as close of an android package as we can get without having the actual source code. While we cannot at this time recompile these into apk's, it is very useful for analysis when trying to implement other mods. Like...really helpful. This one can be accessed by right-clicking a decompileable package and picking "decompile to java".
01.31.15 - v1.8
Added windows progress bar for file copies in system.img extraction.
Fixed some script errors.
01.29.15 - v1.7
Cleaned up installer, added more verbosity.
Better error checking in image extractor.
Add support for .list files, allowing double-click extraction of system.transfer.list and cm12-style image files.
Added custom language files for notepad++, allows syntax highlighting of .smali and logcat files.
01.27.15 -v1.6
Added support for system images. Requires installation of included OSFMount.
Added file associations for common plaintext android files to notepad++ if installed.
Converted several .bat files to .exe, allows for icons, inclusion of required files, and UAC prompting when needed.
01.26.15 - v1.5
Fixed fatfinger in APKtool detection causing error.
01.26.15 - v1.4
Added zipaligning
Added check to make sure apktool is present
Updated test-keys to latest AOSP version
Compiled batches to .exe with required files for AIO-packages
Fixed: Installer not always associating with files correctly.

Thanks a million

Version 1.5 uploaded.
Added Zipaligning
Check to make sure apktool.jar is found in %DROIDROOT% directory.
Updated signing keys.
Switch from .bat to .exe, allows modularization of functions, cleaner.
Modifications to installer to try and fix some issues with file associations.
Fixed issue between 1.4 and v 1.5 where I fatfingered a check.

Hell yes!

digitalhigh said:
Greetings, and welcome to the home of a little set of utilities I'm calling "DroidShell".
What it is:...
Click to expand...
Click to collapse
So many thanks for this! I'm going to use it like hell!

Excellent Job!

I'm bookmarking this, gona read it thuroughly at breakfas

So I'm curious - has anybody had a chance to give this a try yet?
Testing file association stuff is tricky, because Windows likes to keep track of the "user selected" association too. So, I had to add some extra commands to the installer script to clean up everything appropriately first.
Either way, I've ran it on like three different computers "clean" and had it work like a charm on all of them. I'd like to know how it works with WIndows 7 or XP.

I could be doing something wrong (windows is not my OS of choice, I use kubuntu 14.10 as my daily driver, and as such am mostly illiterate in dos/batch, I'm a sh/bash guy), but the installer bombed out (hung up without confirmation of success) on my windows 7 pro install (on a dell latitude e6400, with a dual core core2 @2.8ghz, quattro 160m graphics, 4gb of ddr2 @800mhz, booting off a 120gb Samsung evo ssd. Wouldn't think its relevant, but just in case).
Steps:
First I decompressed the .zip in the root of my C:\ drive, with 7zip (did not change file name, kept as "DroidShell_1.5").
Next I ran the installer script.
I then granted it admin privileges.
It killed my desktop, explorer.exe. I assume this is normal due to the terminal output:
Code:
SUCCESS: The process "explorer.exe" with PID 3260 has been terminated
Then I got:
Code:
file type 'apk_auto_file' not found or no open command associated with it.
Followed by 4 more identical errors, just replace "apk" with dfc, dcp, dci, img.
A bunch of successful operations.
Then:
Code:
ERROR: Invalid syntax.
Type "REG ADD /?" for usage
A bunch of successful operations.
Then:
Code:
ERROR: The system was unable to find the specified registry key or value.
The above output repeats 17 times.
Then 4 more operation success messages and it hangs, with my desktop killed.
Ctrl+alt+del, logout, log in, and I'm back in business. No noticeable increase in disk space, no newly installed programs (as expected).
I read the op, and from my understanding it doesn't require any dependencies? (Apktool, android SDK, android studio, etc). All the necessary dependencies are built in, right? It's a fresh install of windows 7 pro, with all available updates taken.
EDIT:
It worked perfectly regardless of the errors, see my post on page 2.

thisguysayswht said:
I could be doing something wrong (windows is not my OS of choice, I use kubuntu 14.10 as my daily driver, and as such am mostly illiterate in dos/batch, I'm a sh/bash guy), but the installer bombed out on my windows 7 pro install (on a dell latitude e6400, with a dual core core2 @2.8ghz, quattro 160m graphics, 4gb of ddr2 @800mhz, booting off a 120gb Samsung evo ssd. Wouldn't think its relevant, but just in case).
Steps:
First I decompressed the .zip in the root of my C:\ drive, with 7zip (did not change file name, kept as "DroidShell_1.5").
Next I ran the installer script.
I then granted it admin privileges.
It killed my desktop, explorer.exe. I assume this is normal due to the terminal output:
Code:
SUCCESS: The process "explorer.exe" with PID 3260 has been terminated
Then I got:
Code:
file type 'apk_auto_file' not found or no open command associated with it.
Followed by 4 more identical errors, just replace "apk" with dfc, dcp, dci, img.
A bunch of successful operations.
Then:
Code:
ERROR: Invalid syntax.
Type "REG ADD /?" for usage
A bunch of successful operations.
Then:
Code:
ERROR: The system was unable to find the specified registry key or value.
The above output repeats 17 times.
Then 4 more operation success messages and it hangs, with my desktop killed.
Ctrl+alt+del, logout, log in, and I'm back in business. No noticeable increase in disk space, no newly installed programs (as expected).
I read the op, and from my understanding it doesn't require any dependencies? (Apktool, android SDK, android studio, etc). All the necessary dependencies are built in, right? It's a fresh install of windows 7 pro, with all available updates taken.
Click to expand...
Click to collapse
Bombed out is a rough term. The installer is just writing a bunch of registry keys, and deleting some other ones to make sure other associations don't mess it up. So, some registry operations don't always work - there just there to be sure. I've actually worked on cleaning that up in the next iteration I'm cooking.
And yes, there shouldn't be any more size increase past extracting the original zip. All the files used are enclosed. "Installer" is just telling Windows that "droid shell is at location %CD%" and "use app xxx in %CD% to open file XX". A few extras for the right-click context menus and icons...so forth.
So, to know if it is working is really just a matter of finding an apk or .jar and double-clicking it. You should get a terminal window showing the process and a box confirming success or failure, plus a reason why if failure.
The only dependency is the Java Runtime environment, which is the same common necessity as for any other Apktool environment. You can get it here, and I'll throw that link in the OP in a second.
The next iteration of the installer is going to be a lot cleaner, plus be more verbose so you actually know what it's doing. My first thought in putting it out was just to see how well the decompile/recompile stuff worked.

Bombed out is a rough term. The installer is just writing a bunch of registry keys, and deleting some other ones to make sure other associations don't mess it up. So, some registry operations don't always work - there just there to be sure. I've actually worked on cleaning that up in the next iteration I'm cooking.
And yes, there shouldn't be any more size increase past extracting the original zip. All the files used are enclosed. "Installer" is just telling Windows that "droid shell is at location %CD%" and "use app xxx in %CD% to open file XX". A few extras for the right-click context menus and icons...so forth.
So, to know if it is working is really just a matter of finding an apk or .jar and double-clicking it. You should get a terminal window showing the process and a box confirming success or failure, plus a reason why if failure.
The only dependency is the Java Runtime environment, which is the same common necessity as for any other Apktool environment. You can get it here, and I'll throw that link in the OP in a second.
The next iteration of the installer is going to be a lot cleaner, plus be more verbose so you actually know what it's doing. My first thought in putting it out was just to see how well the decompile/recompile stuff worked.
Click to expand...
Click to collapse
I didn't mean to offend with the term "bombed out", it may have been a bit of a rough term. I just meant the script terminated my desktop and hung up.
It actually succeed regardless of the errors, and is working like a charm. I apologize, I should have actually tested it before posting. I shouldn't have assumed that it didn't work based off of the terminal output/behavior.
Also, I would like to say that I greatly appreciate the work that you put into this, and all your other projects here on xda. I'm running your 4.4.4 gpe port for the verizon m8 as my primary rom, and it is by far the most stable port I have ever had the pleasure of flashing.
Attached are screenshots of DroidShell successfully decompiling and recompiling an apk with a simple right click selection on windows 7 pro. Good stuff.

Thanks! tons

Thanks for the work. very useful.
The compiling and decompiling of apk is perfect on Win 7 pro.
From the OP, i also got the impression it would unpack / pack images, so i tried it with a system.img copied to the droidshell directory.
With the command c:\droidshell\unpackimg system.img, I got the error as shown in screenshot
Am I doing something wrong, or is this not supported yet?

arbit12 said:
Thanks for the work. very useful.
The compiling and decompiling of apk is perfect on Win 7 pro.
From the OP, i also got the impression it would unpack / pack images, so i tried it with a system.img copied to the droidshell directory.
With the command c:\droidshell\unpackimg system.img, I got the error as shown in screenshot
Am I doing something wrong, or is this not supported yet?
Click to expand...
Click to collapse
It only works for boot images at the moment. System images are a different beast.
Sent from my HTC6525LVW using XDA Free mobile app

digitalhigh said:
It only works for boot images at the moment. System images are a different beast.
Sent from my HTC6525LVW using XDA Free mobile app
Click to expand...
Click to collapse
Okay. Thanks for the info.

thisguysayswht said:
I didn't mean to offend with the term "bombed out", it may have been a bit of a rough term. I just meant the script terminated my desktop and hung up.
It actually succeed regardless of the errors, and is working like a charm. I apologize, I should have actually tested it before posting. I shouldn't have assumed that it didn't work based off of the terminal output/behavior.
Also, I would like to say that I greatly appreciate the work that you put into this, and all your other projects here on xda. I'm running your 4.4.4 gpe port for the verizon m8 as my primary rom, and it is by far the most stable port I have ever had the pleasure of flashing.
Attached are screenshots of DroidShell successfully decompiling and recompiling an apk with a simple right click selection on windows 7 pro. Good stuff.
Click to expand...
Click to collapse
Oh, no offense taken.
I came at this project, as I do with most, with the mindset of "OOOH, SHINY THING. I MUST SHOW EVERYONE." So, first thought was putting out the app, despite some of the install stuff being a bit dirty.
However, the next iteration is shaping up to be quite lovely. See below.
arbit12 said:
Okay. Thanks for the info.
Click to expand...
Click to collapse
So, it appears that this question has motivated me to try making that function a reality sooner than later.
However, as far as I can see, the *ONLY* application for windows that currently deals with system images right now is Ext2Explore, which is a bit old and doesn't have command-line support.
Fortunately, there's source code for it, so I'm currently downloading Visual Studio and will see if I can add command line functionality, as well as make it launch with UAC prompting.
If I can make this work, my plan is to make one handler for .img files that works like so:
1. Look at the file passed to it and see if it's a boot image. If it is, extract and exit.
2. If it's not a boot image, try to extract it as a system image. If it is, extract and exit.
3. If it's not a boot or system image - pass it to explorer and mount as usual.
I can do # 1 and #3 already...it's just getting #2 to go.
Also, I've added a check in the installer that looks for the installation of notepad++. If it finds it, it will create additional associations for .xml, .prop, conf, config, .smali, and whatever else I can think of that I could possibly need to edit in a ROM.
Then, lastly, with all these additions, I'd like to make the installer a bit more verbose. Give some options so it's not just an all or nothing install, make it prettier, etc.

digitalhigh said:
Oh, no offense taken.
I came at this project, as I do with most, with the mindset of "OOOH, SHINY THING. I MUST SHOW EVERYONE." So, first thought was putting out the app, despite some of the install stuff being a bit dirty.
However, the next iteration is shaping up to be quite lovely. See below.
So, it appears that this question has motivated me to try making that function a reality sooner than later.
However, as far as I can see, the *ONLY* application for windows that currently deals with system images right now is Ext2Explore, which is a bit old and doesn't have command-line support.
Fortunately, there's source code for it, so I'm currently downloading Visual Studio and will see if I can add command line functionality, as well as make it launch with UAC prompting.
If I can make this work, my plan is to make one handler for .img files that works like so:
1. Look at the file passed to it and see if it's a boot image. If it is, extract and exit.
2. If it's not a boot image, try to extract it as a system image. If it is, extract and exit.
3. If it's not a boot or system image - pass it to explorer and mount as usual.
I can do # 1 and #3 already...it's just getting #2 to go.
Also, I've added a check in the installer that looks for the installation of notepad++. If it finds it, it will create additional associations for .xml, .prop, conf, config, .smali, and whatever else I can think of that I could possibly need to edit in a ROM.
Then, lastly, with all these additions, I'd like to make the installer a bit more verbose. Give some options so it's not just an all or nothing install, make it prettier, etc.
Click to expand...
Click to collapse

Captain_Throwback said:
Click to expand...
Click to collapse
Don't get too excited. I've never touched C++ before, and ext2Explore was done in VisualStudio.net and a WYSIWYG editor called QT. I found updated source for the program from 2012 and have gotten it to import into QT, however, it needs MingW and some other dependencies. I'll be lucky if I can even get it to compile again, let alone work, let alone work with added command-line stuff.
However, that's still the goal.
Also, I want to add wget (windows equivalent) stuff to auto grab and install java and notepad++ while we're at it.

So, I think Ext2Explore is more work than it's worth.
OSFMount, on the other hand, just let me mount a system.img as a removable disk with read-write access. I'm going to go down this road...

Good to hear that. Extracting system.img on windows can be a real pain at times - this would be great.