I followed each one of your steps. I get an error when trying to install the signed zip. "Can't find update script" Can anyone please help me with this.
thank you
I'm doing option 2. I get it signed just get an error "Can't find update script"
This quick guide will teach you how to sign ROMs!
WARNING : YOU WILL NEED AT LEAST A BASE KNOWLEDGE OF HOW TO USE COMMAND PROMPT.
The knowledge of signing ROMs can prove useful to anyone! By knowing how to sign ROMs, you can modify your favorite ROM to add or delete APKs, so when you flash the ROM your favorite apps will be present! Or you can delete apps you don't use so they will not be installed when flashing the ROM!
Before starting, you need a couple of things. First you will need Java SE Development Kit and Java SE Runtime Environment . You can download them HERE.
After you have downloaded and installed both, you will need a very useful tool made by someone at XDA-Developers (if you know who it is please let me know).
Download this tool (attached) and unzip everything inside of it into one common folder. I personally unzipped everything into my Android SDK folder.
Signing
Now run the autosign.bat. You will have to go through commands 1(Set PATH variable for SDK) ,2 (Set CLASSPATH variable for signing tool) and 3 (Install registry entries). They are very easy to use and just follow the instructions. If you are asked to confirm and/or replace a file, always select yes!
Now you are finally ready to sign! There are two options to sign the .zip
1)Find the ROM (.zip) and right click and select "Resign Zip". If you use this option a command prompt box should quickly appear and disappear.
OR
2) Using the Autosign.bat, select option 4, and then write the directory and file name of the ROM. For example,
D:\Android\ROMs\YourROMHere.zip
It will hang for a bit at the part where it says "signing", and then it should say something along the lines of "Successfully completed if no errors above"
If this helped you, comment below!
http://androidforums.com/developer-101/8665-how-signing-roms.html
Anyone...... I know someone knows
You have to zip the contents of the rom, not the rom itself. i.e. if you sign the rom folder, it will be ROM_Signed.zip->ROM->system/data/metainf... you get the picture. Go into the folder you want to zip and then sign, select the contents, and zip them. It will then be ROM_Signed.zip->/system/data/metainf. Then just sign it.
update-script is a script that tells the flash utility what to do. It is located in the zip as part of the following directory structure:
META-INF/com/google/android
The contents can vary. For Darktremor A2SD 2.6.1, here's the contents:
show_progress 0.1 0
copy_dir PACKAGE:system SYSTEM:
show_progress 0.1 10
PACKAGE is used by android to reference the actual zip file, or package file.
SYSTEM is used to represent /system
DATA is used to represent /data
CACHE is used to represent /cache
BOOT is used to represent the boot partition (which is where you flash boot.img)
RECOVERY is used to represent the recovery partition. Never actually seen this used. I guess it used for an update.zip that you would flash via fastboot.
The zip file has to be structured in the same way as the file system on your phone. If you want to install something to, say, /system/bin, you must have a system folder, which in turn has a bin folder.
What I would do is take one of the available ROMs and unzip it. Then look for their update-script. Usually ROM packages are more detailed in the update-script.
If you don't have update-script in your zip file, the flash utility in recovery won't know what to do.
networx2002 said:
I followed each one of your steps. I get an error when trying to install the signed zip. "Can't find update script" Can anyone please help me with this.
thank you
I'm doing option 2. I get it signed just get an error "Can't find update script"
This quick guide will teach you how to sign ROMs!
WARNING : YOU WILL NEED AT LEAST A BASE KNOWLEDGE OF HOW TO USE COMMAND PROMPT.
The knowledge of signing ROMs can prove useful to anyone! By knowing how to sign ROMs, you can modify your favorite ROM to add or delete APKs, so when you flash the ROM your favorite apps will be present! Or you can delete apps you don't use so they will not be installed when flashing the ROM!
Before starting, you need a couple of things. First you will need Java SE Development Kit and Java SE Runtime Environment . You can download them HERE.
After you have downloaded and installed both, you will need a very useful tool made by someone at XDA-Developers (if you know who it is please let me know).
Download this tool (attached) and unzip everything inside of it into one common folder. I personally unzipped everything into my Android SDK folder.
Signing
Now run the autosign.bat. You will have to go through commands 1(Set PATH variable for SDK) ,2 (Set CLASSPATH variable for signing tool) and 3 (Install registry entries). They are very easy to use and just follow the instructions. If you are asked to confirm and/or replace a file, always select yes!
Now you are finally ready to sign! There are two options to sign the .zip
1)Find the ROM (.zip) and right click and select "Resign Zip". If you use this option a command prompt box should quickly appear and disappear.
OR
2) Using the Autosign.bat, select option 4, and then write the directory and file name of the ROM. For example,
D:\Android\ROMs\YourROMHere.zip
It will hang for a bit at the part where it says "signing", and then it should say something along the lines of "Successfully completed if no errors above"
If this helped you, comment below!
http://androidforums.com/developer-101/8665-how-signing-roms.html
Click to expand...
Click to collapse
HeroMeng said:
You have to zip the contents of the rom, not the rom itself. i.e. if you sign the rom folder, it will be ROM_Signed.zip->ROM->system/data/metainf... you get the picture. Go into the folder you want to zip and then sign, select the contents, and zip them. It will then be ROM_Signed.zip->/system/data/metainf. Then just sign it.
Click to expand...
Click to collapse
It took my brain a min, but i got it.
Thanks
Hi,
I'm new to the business and I spent some time to learn the environment trying different applications and different approaches for almos every action I took. Today, I have not much bigger knowledge, but I finally decided to take few things in my own hands because existing software is not fulfilling my wishes.
I started with this simple script which eases the pain of reinstalling all applications after ROM upgrade. There are few such tools already, but I found those quite bloated with unnecessary thing for my own approach.
With this script I assume:
1. There is/was SSHDroid installed (or any tool with busybox and you can access shell command line) both in old and new ROMs and your ROM have bash installed in /system/bin/.
2. Backup/restore operation includes only INTERNALLY installed applications, it completely ignores SYSTEM and SDCARD installed ones.
3. This is TEMPORARY backup so it should be as fast as possible not caring about occupied space (!). Althought I added -zip parameter to enable compression if you are running out of space on your sd.
4. Installed ROM is clean with no additional apps installed (excluding those needed by the script)
5. You have basic knowledge about bash scripting, because I take NO RESPONSIBILITY of the script behavior or data loss it can do.
So, basically it is simple. It runs like this:
1. On old ROM type: sbackup -backup
2. Flash your ROM
3. On new rom type: sbackup -restore
Just like that. The applications data is tar'ed in one file per application so if you want to get rid of any, just delete it from backup directory. The directory name is same as script name on sdcard but you can change it adding a parameter without a '-' sign at runtime (first non-option parameter is treated as backup directory path). The file is zipped because this forum disallows files without an extension so... it is zipped ;D
It was tested on my fresh LeeDroid 3.3.3 GB AFTER i installed some apps. I backed them up and then restored. All seems to be perfect right now, but I will test it more thoroghly very soon because I'm planninig to have CM7 based ROM too just to choose that I need Sense or not (two nandroids for fast switch weekly ;P).
With this script and MyBackup functionality of backing up contacts, sms, history and similar it should be quite complete approach to restore all the data needed on the fresh ROM. In the future maybe I will look at the MyBackup part too. Maybe.
Feel free to comment, use, suggest or anything you like, and have fun ;P.
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
jgrimberg1979 said:
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
Click to expand...
Click to collapse
And thats why I mentioned in topic about not being a newbie (and I meant not forum newbie but more a linux newbie). The thing is, it's a simple script - without any user-proof capabilities, comments inside or something BUT...
But ok, I will try to help you run it. First of all, you have to set permissions to the script. It has to have executable permission to be run by the system (and I mean filesystem permission). This can be done by chmod instruction of busybox. Most of the times it's done like this:
chmod 755 filename
This is a reason of not running form sdcard if your sdcard is NOT ext filesystem (it is usually windows fat filesystem not to generate problems with reading it under windows).
Second thing to run is to have /system/bin/bash because first line of the script (a comment like this: #!/system/bin/bash) instructs busybox to execute script using bash. This can be simply changed by modifying this line, but you have to remember that changing the shell executing script have consequences. Differens shells have sometimes different syntax, althoght i wrote this script simply so it should run on most of them, especially sh.
Third thing is to have write permissions to the directory in which the backup will be created. In original version of the script it is /sdcard, because backup is made in /sdcard/sbackup. So, you have to check it (second error - problems with creating directory).
And a last tip - it can be run from ANYWHERE. Even if your partition does not alolow executing, you can do it like this:
bash-3.2# /sdcard/test
bash: /sdcard/test: /system/bin/bash: bad interpreter: Permission denied
bash-3.2# . /sdcard/test
OK
bash-3.2#
First try does not succeded, but second did. The trick is a dot which means to execute file with a shell not caring about why or permissions.
And thats most simple introduction I could write. It applies to ANY script you want to run.
Please anyone - if you want me to help, paste your results here because without a precise error message it can be very hard to deduce what caused for example permission denial or anything usual.
For now, I won't add any more error handling, but if there will be more users caring about, I will add it.
Overview:
This thread is a guide on how to fix the apply_patch_check error message experienced during an upgrade of the Android OS. Specifically, this will detail the steps for an upgrade of Jelly Bean from 4.1.1 to 4.1.2 on the Nexus 7 with CWM Recovery for a user of Windows. I'm sure similar steps will work for other recoveries/upgrades/devices and PC OSes.
You should only bother with this if you don't want to flash the entire system.img file to your phone, which is way easier.
Here is an example of the error message I'm talking about:
Code:
assert failed: apply_patch_check("/system/app/Chrome.apk", "819b34b66335c6faec86404d736a002b8871600", "9d6b55e63b0bf20bea433fb1ee7089f88ab73fb6")
E: Error in /sdcard/03a4eaf95f73.signed-nakasi-JZO54K-from-JRO03D.03a4eaf9.zip
(Status 7)
Installation aborted.
A few notes about the error:
This doesn't have to happen with the Chrome.apk specifically -- it could happen with any app in /system/app or .so in /system/lib.
Those random strings of numbers/letters are SHA-1 hashes of the apk.
The first one is the hash of the apk installed on your device. In my example, this happens to be the version of Chrome that comes with JB 4.1.2.
The second one is the expected hash of the apk that comes with JB 4.1.1.
Cause of the problem:
The reason this error occurs is because the file was somehow modified from its original state. In my case -- and most likely your case -- this was done by Titanium Backup. TB has an option to "Integrate updates of system apps into ROM", which will cause the apk in /system/app (and associated library files in /system/lib, if needed) to be overwritten with the updated apk.
Solution:
Download this zip file which contains the full /system/app and /system/lib directory from the JB 4.1.1 factory image. *
Extract the zip to a location of your choosing on your PC.
In the extracted folder, locate the .apk or .so file referenced in the error message on your device.
Copy this file to your device via your preferred method (USB cable works fine). I put my file in /sdcard/Download.
On your device, use a root file explorer to move the file from /sdcard/Download to /system/app (or /system/lib).
If you don't have a program that can do this, I use ES File Explorer. Be sure to go to Settings > Root Settings and turn on Root Explorer, Up to Root, and Mount File System.
Reboot into your Recovery and try to install the update again.
Repeat steps 3-6 for each subsequent file that produces an error. You will basically need to do this for each app you integrated using TB and maybe a few library files, too. **
* Future updates (above 4.1.2):
Since I won't be keeping the zip file from step #1 up-to-date, here's how to get the directories that I included in the zip for yourself:
Obtain a factory image for your device's current Android version (the version you're updating from).
For JB 4.1.1, this file is called nakasi-jro03d-factory-e102ba72.tgz.
If you're reading this guide at a later date, the JB 4.1.2 file is called nakasi-jzo54k-factory-973f190e.tgz.
You can try your luck at the official Google site, but they seem to only provide the version you're trying to update to, not from.
Extract the .tgz file somewhere on your PC.
Locate the image-naksi-jro03d.zip file and extract that, as well.
In the folder you just extracted from the previous step, located the system.img file.
Download and use a program called sgs2toext4 (View attachment 645320) to convert the system.img to system.ext4.img. ***
Download and use a program called Linux Reader to open system.ext4.img.
Do this by going to Drives > Mount Image > Next > select your file.
It will then be listed under the Hard Disk Drives section in red as "Linux Ext Volume 1".
Navigate to: Linux Ext Volume 1/system.
Right-click on the app (or lib) directory and pick Save > Next > Output to dir of your choice.
You now have the directories that were included with the zip file from Solution step #1, so just follow those steps now.
** How to avoid repeating steps:
If you'd rather not have to try to reinstall after updating only one file, just to find another file that needs updating, try this:
Obtain the /system/app and /system/lib folders from the factory image and save them to your PC.
For the sake of this guide, let's say you save them to C:\factory_app and C:\factory_lib.
Copy the /system/app and /system/lib directories from your phone to your PC.
For the sake of this guide, let's say you saved them to C:\phone_app and C:\phone_lib.
Download the File Checksum Integrity Verifier utility from Microsoft.
Start > Run > cmd
fciv.exe -sha1 -xml factory_app.xml -wp C:\factory_app
fciv.exe -sha1 -xml factory_app.xml -v -bp C:\phone_app
Don't ask me why, but you need to use -bp instead of -wp for the second command.
Don't forget the -v on the second command.
The output of the last command will show you the list of files that are different. These are the files you need to take from C:\factory_app and put into the /system/app directory on your phone.
Do the same for the lib directories (just replace all instances of "_app" with "_lib" in the previous commands).
Summary:
I hope that this post helped some of you who really didn't want to have to flash the system.img or wipe your device just to update. In the future, use TB to back up the original.
I wouldn't normally bother writing up a guide like this (it took almost as long to write as it did to figure out how to do this) but I couldn't find this solution anywhere even though I saw that I wasn't the only person with the problem. Sorry for not posting this guide sooner (update has been out for a while now), but the forum required me to make a bunch of useless spam posts before I could include any links in my guide and I didn't get around to making those posts right away.
*** I would like to thank balamu96m for his guide on extracting data from the system.img file and drphrozen for making the sgs2toext4 program.
Thanks for this. Will try now.
Worked great. Had to copy the apk and odex file.
Good job! It's great to see the steps for Windows users!
Just a heads up that I simply extracted the files I needed from and on my N7 using Root Explorer, without using my PC at all.
Great guide! Method worked perfectly on my Nexus 7 going from 4.1.2 to 4.2, thanks
Please... is there some other way to update the files w/o installing Java on my Windoze PeeCee? I accidentally messed up my YouTube.apk with Titanium Backup... now I can't update from 4.1.2 --> 4.2 JB.
EDIT: JavaPortable FTW... updating (fingers crossed)
EDIT: SUCCESS TY OP!
For anyone who flashed the 4.2 clock/keyboard already
Hey, for anyone who flashed the 4.2 clock and keyboard on their Nexus 7 already and need to roll back to do the 4.2 update, I used OP's method to make a flashable zip that puts the 4.1.2 clock and keyboard back.
Worked perfectly for my Nexus 7 to get me up and running. Hope it helps anyone!
cantthinkofa.com/files/RestoreClockKeyboard.zip
galaxy nexus
Hi can you post a guide for galaxy nexus? Or if it is the same, can you post the link of JB factory image for galaxy nexus? Sorry, I can't find any thread for galaxy nexus, and I don't want to complete flash the stock image since I don't want to wipe my phone.
Thanks in advance!
Nice Guide
perfect, the guide works just fine. Now finally running 4.2.
Awesome guide... Thanks... Happily running 4.2 now aften beeing stuck at libutils.so...
Sent from my Nexus 7 using xda premium
damagno said:
Hi can you post a guide for galaxy nexus? Or if it is the same, can you post the link of JB factory image for galaxy nexus? Sorry, I can't find any thread for galaxy nexus, and I don't want to complete flash the stock image since I don't want to wipe my phone.
Thanks in advance!
Click to expand...
Click to collapse
I don't have a Galazy Nexus, but I think the steps should be the same. Here is a link to the factory images: https://developers.google.com/android/nexus/images#takju . It looks like they now have links for older versions, rather than just the newest images (which is how it was when I made my guide). So that's pretty sweet.
Thanks a lot man, i succeeded to "patch" my system files to update from 4.2 to 4.2.1. I first check what files didn't correspond with fciv (9 files counting both apks and odex) and then replaced them in system/app. In fact they were the apps I previously integrated with tb (learned lesson: never do it if you want to remain stock and receive OTAs). I also noticed many not-matching files in system/lib but i didn't touch them and the update went smooth the same.
Another thing: when in the OP you say it's way easier just to reflash the system.img you mean just run from bootloader "fastboot flash system system.img" (taken from the factory image as usual) or there's some other thing to do in order to fix the system partition in the right way?
GallStones said:
Thanks a lot man, i succeeded to "patch" my system files to update from 4.2 to 4.2.1.
Click to expand...
Click to collapse
I was wondering if you could tell me how you did it? I'm searching a way to install 4.2.1 with no avail as of yet :crying:
GallStones said:
Thanks a lot man, i succeeded to "patch" my system files to update from 4.2 to 4.2.1. I first check what files didn't correspond with fciv (9 files counting both apks and odex) and then replaced them in system/app. In fact they were the apps I previously integrated with tb (learned lesson: never do it if you want to remain stock and receive OTAs). I also noticed many not-matching files in system/lib but i didn't touch them and the update went smooth the same.
Another thing: when in the OP you say it's way easier just to reflash the system.img you mean just run from bootloader "fastboot flash system system.img" (taken from the factory image as usual) or there's some other thing to do in order to fix the system partition in the right way?
Click to expand...
Click to collapse
Yes. I am having the same issue. I cannot update mine from 4.2 to 4.2.1. I wonder to know which original stock image you have used. Can you list a detail procedure?
Thank you very much.
Ric
dev/block/param
legom said:
Overview:
This thread is a guide on how to fix the apply_patch_check error message experienced during an upgrade of the Android OS. Specifically, this will detail the steps for an upgrade of Jelly Bean from 4.1.1 to 4.1.2 on the Nexus 7 with CWM Recovery for a user of Windows. I'm sure similar steps will work for other recoveries/upgrades/devices and PC OSes.
You should only bother with this if you don't want to flash the entire system.img file to your phone, which is way easier.
Here is an example of the error message I'm talking about:
Code:
assert failed: apply_patch_check("/system/app/Chrome.apk", "819b34b66335c6faec86404d736a002b8871600", "9d6b55e63b0bf20bea433fb1ee7089f88ab73fb6")
E: Error in /sdcard/03a4eaf95f73.signed-nakasi-JZO54K-from-JRO03D.03a4eaf9.zip
(Status 7)
Installation aborted.
A few notes about the error:
This doesn't have to happen with the Chrome.apk specifically -- it could happen with any app in /system/app or .so in /system/lib.
Those random strings of numbers/letters are SHA-1 hashes of the apk.
The first one is the hash of the apk installed on your device. In my example, this happens to be the version of Chrome that comes with JB 4.1.2.
The second one is the expected hash of the apk that comes with JB 4.1.1.
Cause of the problem:
The reason this error occurs is because the file was somehow modified from its original state. In my case -- and most likely your case -- this was done by Titanium Backup. TB has an option to "Integrate updates of system apps into ROM", which will cause the apk in /system/app (and associated library files in /system/lib, if needed) to be overwritten with the updated apk.
Solution:
Download this zip file which contains the full /system/app and /system/lib directory from the JB 4.1.1 factory image. *
Extract the zip to a location of your choosing on your PC.
In the extracted folder, locate the .apk or .so file referenced in the error message on your device.
Copy this file to your device via your preferred method (USB cable works fine). I put my file in /sdcard/Download.
On your device, use a root file explorer to move the file from /sdcard/Download to /system/app (or /system/lib).
If you don't have a program that can do this, I use ES File Explorer. Be sure to go to Settings > Root Settings and turn on Root Explorer, Up to Root, and Mount File System.
Reboot into your Recovery and try to install the update again.
Repeat steps 3-6 for each subsequent file that produces an error. You will basically need to do this for each app you integrated using TB and maybe a few library files, too. **
* Future updates (above 4.1.2):
Since I won't be keeping the zip file from step #1 up-to-date, here's how to get the directories that I included in the zip for yourself:
Obtain a factory image for your device's current Android version (the version you're updating from).
For JB 4.1.1, this file is called nakasi-jro03d-factory-e102ba72.tgz.
If you're reading this guide at a later date, the JB 4.1.2 file is called nakasi-jzo54k-factory-973f190e.tgz.
You can try your luck at the official Google site, but they seem to only provide the version you're trying to update to, not from.
Extract the .tgz file somewhere on your PC.
Locate the image-naksi-jro03d.zip file and extract that, as well.
In the folder you just extracted from the previous step, located the system.img file.
Download and use a program called sgs2toext4 (View attachment 645320) to convert the system.img to system.ext4.img. ***
Download and use a program called Linux Reader to open system.ext4.img.
Do this by going to Drives > Mount Image > Next > select your file.
It will then be listed under the Hard Disk Drives section in red as "Linux Ext Volume 1".
Navigate to: Linux Ext Volume 1/system.
Right-click on the app (or lib) directory and pick Save > Next > Output to dir of your choice.
You now have the directories that were included with the zip file from Solution step #1, so just follow those steps now.
** How to avoid repeating steps:
If you'd rather not have to try to reinstall after updating only one file, just to find another file that needs updating, try this:
Obtain the /system/app and /system/lib folders from the factory image and save them to your PC.
For the sake of this guide, let's say you save them to C:\factory_app and C:\factory_lib.
Copy the /system/app and /system/lib directories from your phone to your PC.
For the sake of this guide, let's say you saved them to C:\phone_app and C:\phone_lib.
Download the File Checksum Integrity Verifier utility from Microsoft.
Start > Run > cmd
fciv.exe -sha1 -xml factory_app.xml -wp C:\factory_app
fciv.exe -sha1 -xml factory_app.xml -v -bp C:\phone_app
Don't ask me why, but you need to use -bp instead of -wp for the second command.
Don't forget the -v on the second command.
The output of the last command will show you the list of files that are different. These are the files you need to take from C:\factory_app and put into the /system/app directory on your phone.
Do the same for the lib directories (just replace all instances of "_app" with "_lib" in the previous commands).
Summary:
I hope that this post helped some of you who really didn't want to have to flash the system.img or wipe your device just to update. In the future, use TB to back up the original.
I wouldn't normally bother writing up a guide like this (it took almost as long to write as it did to figure out how to do this) but I couldn't find this solution anywhere even though I saw that I wasn't the only person with the problem. Sorry for not posting this guide sooner (update has been out for a while now), but the forum required me to make a bunch of useless spam posts before I could include any links in my guide and I didn't get around to making those posts right away.
*** I would like to thank balamu96m for his guide on extracting data from the system.img file and drphrozen for making the sgs2toext4 program.
Click to expand...
Click to collapse
my error 7 was generated by emmc: dev/block/mmdblk0p7 (the file is "param" any suggestions?
Thanks. After searching for a lot of time, this post helped me updating my SGS3.:victory: I previously tried to integrate youtube update into rom using titanium backup.
GallStones said:
Another thing: when in the OP you say it's way easier just to reflash the system.img you mean just run from bootloader "fastboot flash system system.img" (taken from the factory image as usual)
Click to expand...
Click to collapse
Yes, that's what I mean. The reason I didn't want to do this on my device is because I had modified some other system files that I wanted to keep the modifications for.
Wow, thanks a lot OP! Your guide helped me fixing an error during the update to 4.2.2 on my Nexus 4.
please include a video ,im getting lost in the details
solved.
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.