Related
Hi everyone,
I was wondering if someone could point me in the right direction to create a flashable ROM from *SCRATCH*. I have googled everything I can think of and everyone seems to have the same answer -- take someone else's zip file and just replace the files with your own, then tweak the updater-script if necessary.
This seems kind of bogus to me, but perhaps I don't quite understand edify scripting. Certainly doing this with amend scripting would work, but that was deprecated a long time ago so I would like to use edify. I think the root of the problem is that I don't understand what the update-binary file is all about.
Can someone please explain how to create a zip without just using someone else's and tweaking it? I recently updated my framework-res.apk file and put new battery icons and new charging animation in it. Then I pushed it back over to my phone with adb and it works great. I would really like to know how to create a flashable zip from this. Sure, I could just download someone else's zip file and then swap out their framework-res.apk file with mine but that doesn't teach me the real, underlying process.
I am a developer for my day job so I'm not new to this type of stuff, but I am new to Android development. I can create the directory structure necessary and place my signed apk file where it needs to go. Furthermore I can write the updater-script file myself (in edify syntax). But then I need to somehow generate the update-binary file before creating the final, flashable zip and signing it.
So how exactly do I create the update-binary file? Do I need to run my updater-script file through a compiler or something? Or maybe the update-binary file is universal for every flashable zip (though if this were the case, then why have the file in every zip -- just put it on every phone and then you don't need to bloat every flashable zip file with it).
Can someone please explain? Also, if you can do it without mentioning or requiring any Windows specific tools that would be great. I run Ubuntu so most of the Windows tools are useless to me (yes I know I could run a virtual machine, or use Wine, etc.). I prefer to do everything with Linux or some platform-independent way.
Thanks!
I use linux too (gentoo) and I make mine pretty much from scratch. Just create a working directory somewhere (I use /usr/src/[my_package_name]/) then create a directory layout just like you'd want to see on the android device. For your example make a directory called "system" and then "system/framework" then copy your framework-res.apk to system/framework/. Now make a META_INF directory, and add "com" then "google" then "android" (so you have [my_package_dir]/META_INF/com/google/android/ ). Now copy the updater_binary (this is basically the command interpreter for edify scripts--amend commands are built-in to the recovery system). Now make your script. FOr your example above, your realy only need a few commands: mount the system dir, then copy the package file(s) over:
Code:
mount("ext3", "EMMC", "/dev/block/mmcblk0p25", "/system");
package_extract_dir("system", "/system");
You'll need to know the details for the specific device to know what arguments to use for the mount command. The above is for an Inspire or DesireHD.
Now just zip it all up (from your base package's directory):
Code:
zip -r -o my_package_file.zip META_INF/ system/
the "-r" means "recursive" and "-o" tells it what output file to use. The remaining arguments are the files (or directories in this case) to zip up.
That's great information...actually more detailed than what I needed but it's always better to have too much than too little. You answered my main question though which is what is the point of the update-binary file. If it's an interpreter for edify scripts then that makes total sense that it would be included in every zip (and furthermore be the same in every zip). I still think it's a bit of a waste though (just build that interpreter into the Android kernel itself so that people don't have to copy it around everywhere), but I'm not the one in charge of this stuff.
I guess I'm off to create a zip of my battery icons then. I'm on an Evo by the way, and if I remember correctly /system is mounted on /dev/block/mtdblock3. No big deal though, I can always cat /proc/mounts in a shell to find out.
Thank you very much!
P.S. You can save a few keystrokes on the zip command by dropping the -o and even dropping the .zip extension. Just try:
Code:
zip -r my_package_file *
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.
Introduction
After releasing my 'Update to .253' thread, I've figured it is something you might want to do your self, maybe because you like to use your own created FTF, or even want to modify your ROM a bit before flashing. This guide will help you through it, as secure and successful as possible!
Anyone can do it!
There is no need to unlock your bootloader to work this guide, however it did help me out of some sticky situations myself, as long as you keep a cool head while working on your ROM, you'll be able to get out of any situation.
The XDA mantra: MAKE BACKUPS!
Before you do anything on your phone, make sure you create a solid backup first. As CWM and TWRP both do not backup your internal storage, create a backup of it's contents too before trying to install your very own ROM.
Prerequisites
Flashtool version 0.9.x.x (the latest) - Windows / Linux / Mac
Needed to flash your phone, also needed to create the FTF bundle. The Linux version is already installed in the VM but you can download any other version too, to do the flashing and FTF building before hand in a desktop enviroment you are accustomed to.
[GUIDE] Download ANY firmware customization from Sony & create an FTF with Flashtool
This thread will help you make an FTF file for your DIY project, as we already have this excelent thread I will save myself the trouble of creating a guide for that
VMWare Player (76Mb) (Free for non-commercial use) and [NUT]'s UbuntuHost VM (Bittorrent: 4.84Gb)
The VM you download is OK to use on any 4.1.2 ROM as base.
If you wish to use a 4.2.2 ROM, you will need the DIYGuide UPDATE PACKAGE 1 (Bittorrent: 169Mb).
If you wish to use a 4.3 or 4.4 ROM, you will be needing DIYGuide UPDATE PACKAGE 2 (Bittorrent: 159Mb). Flashtool however needs to be updated to 0.9.15.0 if you are going to build a 4.4 ROM
See the index below for the link to the guide post that explains how to use it.
This you will need for the tricky bits, as modifying a ROM is safer on a Linux host with less chances of breaking file permissions. As most of the world around us uses Windows, I've created a VM to support you in your tasks. I've installed the Linux tools you need, for me this VM works just fine.
The VM needs about 10Gb space on your pc and you need around 1Gb of free RAM when trying to use it smoothly.
This VM also contains a build script, simple but effective, which will create the (unsigned) flashable zip for you, grabbing all the files it needs along the way and giving you time to edit what ever you want during the building process.
I've made sure you have fastboot and adb commands to be found in the PATH variable, and that the connection to most android phones and tablets will most probably work just fine. You can do adb and fastboot commands to your phone without having them in the directory where you keep the files, easy to use!
The VM has one user, which is called XDA Community. To log in on Ubuntu, use the following credentials:
User: xda
Password: xdauser
This user has SUDO privileges, so expect to type that password again when prompted to do so while installing packages or even when running the rombuilder script.
Download and install WinRAR or 7Zip to be able to unpack my VM.
Included in the ROM you will build using this DIY Guide
Your DIY ROM will be rooted with SuperUser (or SuperSU when you used an update package), including the reboot fix. It will also include XZDualRecovery 2.3 RELEASE (or newer if you used an update package). So you will end up with a cool ROM!
Extra's
You will be able to use my AROMA ROM Mutator package to fix your JB 4.1 ROM if anything might fall to pieces in the future regarding root. You'll also be able to use it to make the switch from SuperUser to SuperSU using the mutator, if you might change your mind in the future.
Guide Index
Chapter 1: Introduction and Prerequisites
Chapter 2: Installing VMWare Player and getting 'UbuntuHost' running
Chapter 3: Preparing the FTF for NOOB use
Chapter 4: Preparing and Extracting the ROM
Chapter 5: Building the (unsigned) flashable ZIP
Chapter 6: Installing your DIY ROM
Addendum: How to replace the recoveries to suit your device
Addendum: How to update your VM
Frequently Asked Questions
Installing VMWare Player and getting 'UbuntuHost' running
I'm assuming you have downloaded the VMWare Player application suitable for your system. Installing it is a basic knowledge to most Windows users, so I'm not going to elaborate on the actual installation.
I'm also assuming you have downloaded the VM. You can now unpack it to your Documents folder.
Now, fire up VMware player and when you see the following...
{
"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"
}
Then click on 'Open a Virtual Machine' and navigate to the folder you just extracted:
Click on the UbuntuHost.vmx and confirm the choice. You'll end up with this view:
Now you can either double click on the name in the list on the left or click play on the right to start it.
Remember, the password is xdauser
NOTE: This Ubuntu has the Unity interface which means, among other things, the menus are moved from the application window to the top bar. Move your mouse over it and the menus will appear.
And you are ready for the next chapter!
Preparing the FTF for NOOB use
Why would you do that? Well... to make sure you won't screw up flashing the wrong bits and make it erase your userdata... better safe then sorry!
This step is actually also needed to unpack the system partition from the FTF you created using the guide I put in the OP.
Copy the FTF you created to the VM by dragging the file in to the VM window. You can see Ubuntu recognizes it as a ZIP, which it essentially is.
Open it by double clicking on it.
Now delete userdata.sin, cache.sin and appslog.sin from it. Then drag system.sin to the DIY Guide folder on the desktop. Once it's unpacked, delete system.sin from the FTF as well.
That was easy, wasn't it? Lets move on to the next chapter.
Preparing and Extracting the ROM
Click on the Terminal icon on the left, type 'cd FlashTool' and then './FlashTool'.
NOTE: Use 'sudo' and your password you used to login to run FlashTool as root if you run in to problems.
In the Tools menu, you can select Sin Editor, select the system.sin in your DIY_Guide folder in your home.
Then click 'Extract data' to start the extraction, now go get a cup of coffee, this might take a while
Once it's done you will end up with a file called 'system.ext4' inside your DIY_Guide directory.
Click Close and close FlashTool using the orange X in the top left corner.
You can rename it to something you like but it should end with '.ext4' to allow the scripts to recognize it. Just open up the DIY Guide folder on the desktop and right click on the system.ext4 file and choose 'Rename'. For purpose of demonstration I renamed mine to 'nuts.ext4'
NOTE: The scripts allow for more then one flashable system to be created, so you can repeat the above multiple times, just remember to rename the system.ext4 to something else, otherwise you'll just end up overwriting the same file over and over again
Because of size considerations, the virtual disk is not really big (10Gb) so you'll run out of space fairly quickly, do not forget to empty the trash after this step!
That's it for this chapter, lets move on!
Building the (unsigned) flashable ZIP
Now we can open the Terminal by clicking on the icon on the left with the '>_' sign in the 'monitor'. Change directory to DIY_Guide and type 'ls -la' to show the following
You can start the build process using the rombuilder script by typing './rombuilder' and it will ask you for your password before it starts.
Once it successfully mounts the system partition it will open it for you. The script will pause for you to complete whatever modifications you want to do to it. Remember the XDA Mantra? Well... a backup would be good to make right now.
If you have more then one system.sin extracted, the above process will repeat itself until it passes all the various .ext4 files it has found.
NOTE: The mounted ext4 image has been mounted as root and as the contents are owned by root, you will need to sudo your actions when modifying the contents!
Tip: To make it easy on yourself you can use the terminal to open a file manager running as root. Type ctrl+shift+t, this will open a new terminal tab. In there type 'sudo nautilus' which starts the file manager again, but with an appropriate warning at the top of the explorer window, that one will be running as root. Be careful, you might wreck your entire VM if you mess things up big!
Once you are finished with the modifications or just enter through to the next bit, it will pack up the system partition and repeat or when done it will continue to create a flashable ZIP for each of the different .ext4 files you created.
You're almost done! Lets move to the next chapter...
Installing your DIY ROM
FOR 4.1.2 ROM's:
Before doing these steps, remember to have any recovery installed on your phone if you are doing this with a locked bootloader, otherwise you won't be able to flash the zip you've built!
Put your '$NAME.flashable.zip' on (the external) SDcard;
Put the 'FTF' inside the FlashTool/firmwares folder;
Create a backup of your phone in CWM or TWRP and don't forget to backup the contents of 'SDCard0';
Flash everything in the 'FTF' to your phone and boot the phone straight to recovery after that;
NOTE: If you have an unlocked bootloader, you CAN flash the kernel, but you do not need to, to keep your custom kernel.
Flash '$NAME.flashable.zip' in recovery (Works in both CWM and TWRP!)
Reboot to system without clearing (dalvik-/)cache.
And you're done! :victory:
FOR 4.2.2 AND 4.3 ROM's:
Before doing these steps, remember to have any recovery installed on your phone if you are doing this with a locked bootloader, otherwise you won't be able to flash the zip you've built! You will need XZDualRecovery 2.5 BETA or newer to make this work.
NOTE: This guide assumes you are coming from a 4.1.2 ROM. If you have a 4.2.2 ROM already installed, you can skip this one and use the above guide.
Put your '$NAME.flashable.zip' on (the external) SDcard;
Put the 'FTF' inside the FlashTool/firmwares folder;
Create a backup of your phone in CWM or TWRP and don't forget to backup the contents of 'SDCard0';
Flash '$NAME.flashable.zip' in TWRP, then TURN YOUR PHONE OFF AFTERWARDS - DO NOT BOOT IT YET!
Flash everything in the 'FTF' to your phone;
Now boot to system without clearing (dalvik-/)cache.
And you're done! :victory:
Addendum: How to replace the recoveries to suit your device
Download XZDualRecovery specific for your device, the flashable package to be precise.
Drag the file to the VM window and open the zip. You will see 2 folders in there, traverse in to system/bin where you will see the files you need most.
Open the DIY_Guide on the VM's desktop, traverse to updater/system/bin and drag all the files from the zip in to this directory, replacing all the files already in your VM and you are set to go
On the Xperia Z Ultra, Z1 Compact, Z1 and (Tablet) Z2, don't forget to copy the disableric file from the tmp folder inside the recovery zip to the updater/system/xbin folder. Forgetting to do so will cause your system partition to be not fully accessible from the fully booted ROM.
For completeness, you could copy the dr.prop file inside the zip to the updater directory too: this will ensure people downloading your package will know what XZDR version was included.
Addendum: How to update your VM
The update package 1 contains the following:
FlashTool 0.9.11.0
XZDualRecovery 2.5 BETA
The Remount-Reboot fix
Superuser has been replaced by SuperSU
IMPORTANT NOTE: This update makes your flashable ZIP assume you are updating from a 4.1.2 ROM to a 4.2.2 ROM. So the resulting flashable ZIP will move the contents of your internal storage to the new 4.2.2 location. If you are creating a package to go from a 4.2.2 ROM to a 4.2.2 ROM, you will need to edit the updater-script to stop it from doing that
Code:
ui_print(" Moving contents of the internal storage to it's new location...");
ui_print("");
ui_print(" NOTE: This may take a while!");
ui_print("");
run_program("/sbin/busybox", "mv", "/data/media", "/data/temporary");
run_program("/sbin/busybox", "mkdir", "/data/media");
run_program("/sbin/busybox", "mv", "/data/temporary", "/data/media/0");
set_progress(0.850000);
Remove the above portion from updater/META-INF/com/google/android/updater-script using gedit and you're set! :fingers-crossed:
The update package 2 contains the following:
Flashtool 0.9.13.0
SuperSU 1.86
XZDualRecovery 2.7.62.
How to update:
Download the update package from the link in the OP;
Open the Home directory in the VM on the bar on the left;
Drag the file in to the home directory straight from your host PC's location where you stored the downloaded package;
Remove the FlashTool and DYI_Guide folders or rename them (to rename, right click on them to get the menu with the rename option);
Now open the diyvm-update.tar.gz, drag the 2 folders in to the Home directory.
All done! :good:
Frequently Asked Questions
Q: Could I use this for any other Xperia device?
A: Sure you can! The proof is starting to pop up now and then
Just make sure you put in the right recovery pieces to support your specific device
Q: Am I allowed to release my ROM to the public?
A: Of course! I only require a simple mention or a humble thank you in your topic, where ever that may be. I like to know where my work travels to, so post or PM me the links to it
Q: Am I allowed to change the updater script to suit my needs?
A: You are allowed to change whatever you wish, I have NO copyright or license stuck to my work, simply because I consider anything with a license or copyright not to be 100% pure open source.
Q: I would like to make a ROM for my device, but there is no XZDualRecovery for it?
A: Try to integrate a recovery package available for your device. You can of course also request XZDR support, but it can take some time before that happens.
Q: I want to expand the storage capacity of the VM, is there any guide for that?
A: Yes, @gregbradley posted one here.
Q: My VM disk is slowly filling up, while I am keeping the trash empty, how come?
A: @GavTheStoner found out why, read his post on the subject and the solution he found.
Would be very useful! Thank you for the nice and clear guide!
Could you please also provide the script and other files needed such recovery etc. ? The whole VM image is large...
Fishmanzero said:
Would be very useful! Thank you for the nice and clear guide!
Could you please also provide the script and other files needed such recovery etc. ? The whole VM image is large...
Click to expand...
Click to collapse
No
It's not hard to find parts in my releases...
Sent from my C6603 using xda app-developers app
Great guide! Thanks a lot for this!
Gesendet von meinem Xperia Z via Tapatalk
Don't suppose anyone's come up with a way to rebuild to FTF?
Would love to be able to do that and just load with FlashTool.
Johbremat said:
Don't suppose anyone's come up with a way to rebuild to FTF?
Would love to be able to do that and just load with FlashTool.
Click to expand...
Click to collapse
Me too, but unfortunately that's just impossible... Sorry
Sent from my C6603 using xda app-developers app
Great Guide
Thanks for sharing - I was able to create my own deodexed and zipaligned 10.1.1.A.1.307 firmware. I tweaked it a bit so it doesn't reboot when changing system to R/W.
Next I'll try creating one for the Japanese 10.1.D.0.343 build
I was able to create a working 10.1.D.0.343 build for the SO-02E variant using your guide. Is it cool with you if I upload it and share it for our Japanese friends? I'll give you credit of course. :good:
lancebukkake said:
I was able to create a working 10.1.D.0.343 build for the SO-02E variant using your guide. Is it cool with you if I upload it and share it for our Japanese friends? I'll give you credit of course. :good:
Click to expand...
Click to collapse
Of course you can
If I didn't want you to release it to the public I'd have that explicitly stated in the OP ... which I haven't, so go right ahead! :good:
--- ON A DIFFERENT NOTE ---
I'll be updating the VM soon to reflect the changes in the updater script, the remount-reboot fix and the latest XZDualRecovery.
I'll also make a tar archive with a little guide in one of the reserved posts to help you update your VM so you won't have to download it all over again
Thanks!
But its possible to create a ROM out of a CWM Backup on Windows.. I.E. thats more simple
Thanks for the VM though
jader13254 said:
Thanks!
But its possible to create a ROM out of a CWM Backup on Windows.. I.E. thats more simple
Thanks for the VM though
Click to expand...
Click to collapse
I know it is, but that is basically a TAR backup and requires a few extra steps: flashing the FTF to your phone, then booting to recovery to make that backup, dragging that to your PC and stripping the META info from the nandroid backup process adds to the TAR (which makes it a non-standard tar archive!) and you still risk losing all permissions and ownership information on the files inside the archive when extracting that to integrate it in your flashable zip... which is a ZIP and does not know about the extended file permissions and ownership from a Linux system... so you will have to make your updater-script reset permissions or instruct your users to do so using recovery... :silly:
Using this VM and my method of using the SIN file to extract a ROM prevents a huge heap of possible issues and keeps the updater-script nice and small and the installation a breeze
[NUT] said:
I know it is, but that is basically a TAR backup and requires a few extra steps: flashing the FTF to your phone, then booting to recovery to make that backup, dragging that to your PC and stripping the META info from the nandroid backup process adds to the TAR (which makes it a non-standard tar archive!) and you still risk losing all permissions and ownership information on the files inside the archive when extracting that to integrate it in your flashable zip... which is a ZIP and does not know about the extended file permissions and ownership from a Linux system... so you will have to make your updater-script reset permissions or instruct your users to do so using recovery... :silly:
Using this VM and my method of using the SIN file to extract a ROM prevents a huge heap of possible issues and keeps the updater-script nice and small and the installation a breeze
Click to expand...
Click to collapse
I just used a nice tool called "yaffey" which keeps the file structure and I set permissions via updater-script.
Works really fine but may be more difficult
Reall great way though and big thanks for this guide
Q&A for [MOD]Stock SystemUI and Stock Firmware DXMD1[DEODEXED] for GT-S6102
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [MOD]Stock SystemUI and Stock Firmware DXMD1[DEODEXED] for GT-S6102. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
De-odexed!!!
Well, here again, hmm, it looks like the main problem with my swipe to remove is that I don't have a fully deodexed ROM(Xduos V3) which is why it's not working. sigh, and I was preparing myself to go for the hard way.
Guess my questions are answered here as for now.
marcussmith2626
Click to expand...
Click to collapse
will meet again.
New question
Can I save the little space I have in internal storage with a deodexed rom? deodexed rom is going to solve my issues with the rom's UI but I am concerned as to what effect it will have on my sgy performance?
billysam said:
Well, here again, hmm, it looks like the main problem with my swipe to remove is that I don't have a fully deodexed ROM(Xduos V3) which is why it's not working. sigh, and I was preparing myself to go for the hard way.
Guess my questions are answered here as for now. will meet again.
New question
Can I save the little space I have in internal storage with a deodexed rom? deodexed rom is going to solve my issues with the rom's UI but I am concerned as to what effect it will have on my sgy performance?
Click to expand...
Click to collapse
If the rom is odex you will see .odex files in system/app and framework
To deodex follow these steps
Requirements
Pc
Android kitchen
Cygwin
Rooted phone with Busybox & terminal emulator
Winrar
Notepad++ (different from the windows notepad)
Alot of patience & a little knowledge
Please note I'm writing this from memory - some steps may vary
First root your phone & install Busybox (open app & click install) from the playstore
Also install terminal emulator
https://play.google.com/store/apps/details?id=stericson.busybox
https://play.google.com/store/apps/details?id=jackpal.androidterm
Set your screen timeout to 30mins
Open terminal emulator
Type the following (a new line represent push enter after the line before)
Su
tar -c system/* >> sdcard/system.tar
Note it may take around 5mins to complete - You will know it's done when the prompt cursor returns
This will copy your phones system folder to the root of your site
card and call it system.tar
Copy this tar file to your pc
Next head to this thread
http://forum.xda-developers.com/showthread.php?t=2195858
Download and install Cygwin and Android kitchen
There is a YouTube video which explains how on the thread so watch it
This is the part I can't remember exactly from memory
You need to setup a working folder - I can't
remember if you place the tar file in the rom folder in the kitchen directory or you unzip it & copy it to a working folder - that thread will say
Start Cygwin as administrator (right click on icon & run as administrator) if you get a load of errors turn off your antivirus
Navigate to your kitchen folder (you can bring up a list of folders by typing ls and type cd to change directory
Type ./menu
Kitchen will start
You have the option to create a working folder which will look in the rom folder - if a tar file is acceptable it will extract your tar into a working folder - can't remember if that's how you do it
Next goto advance (or extra options can't remember what it says)
Goto deodex
You need to change the api level so it matches your Android version
Now you are finally ready to deodex
Deodex both folders
Once done build the rom (lazy mode options should be fine Think it signs rom create scripts & so on)
Once it's built collect your rom zip
Now download any custom stock rom - maybe hyperion 9 for 5360
Open your rom zip with winrar
Delete boot.img if present
Goto meta-inf folder and I think it's in com/google/andoid
Delete the update binary and replace with the one from hyperion9
Next open extract the updater script from both roms from the same folder the binary way in
Open them both in notepade++
Replace everything in your script above where the symlinks start with what is written in the hyperion9 one
Save & copy this script back to your rom zip meta in folder replacing the one that is there
Copy zip to sd card
Go into Cwm
Create a nandroid backup
Format system data cache
Mount system data cache
Flash your rom zip
Error codes
Status 0 wrong update binary
Status 6 error with updater script
Hopefully there will be no errors and it will flash and when you restart you will have a fresh deodexed rom
You can go into Cwm and advance restore data only
This should restore your contacts sms and app data
For extra storage create a 2nd ext partition on your site card in Cwm (note that this will format your ad card so copy it's contents to a pc then copy back once done)
Once you have a 2nd ext partition you can download link2sd from the playstore and link apps to sd card - you can also use the app to uninstall bloatware from the system
Note you will need to use a kernel that supports ext and try ext4 first from the link2sd menu that will pop up & work your way back up if that fails
I don't normally post such a long explanation but I'm feeling generous - anything else please research yourself
Very Much Appreciated
marcussmith2626 said:
If the rom is odex you will see .odex files in system/app and framework
To deodex follow these steps
Requirements
Pc
Android kitchen
Cygwin
Rooted phone with Busybox & terminal emulator
Winrar
Notepad++ (different from the windows notepad)
Alot of patience & a little knowledge
Please note I'm writing this from memory - some steps may vary
First root your phone & install Busybox (open app & click install) from the playstore
Also install terminal emulator
https://play.google.com/store/apps/details?id=stericson.busybox
https://play.google.com/store/apps/details?id=jackpal.androidterm
Set your screen timeout to 30mins
Open terminal emulator
Type the following (a new line represent push enter after the line before)
Su
tar -c system/* >> sdcard/system.tar
Note it may take around 5mins to complete - You will know it's done when the prompt cursor returns
This will copy your phones system folder to the root of your site
card and call it system.tar
Copy this tar file to your pc
Next head to this thread
http://forum.xda-developers.com/showthread.php?t=2195858
Download and install Cygwin and Android kitchen
There is a YouTube video which explains how on the thread so watch it
This is the part I can't remember exactly from memory
You need to setup a working folder - I can't
remember if you place the tar file in the rom folder in the kitchen directory or you unzip it & copy it to a working folder - that thread will say
Start Cygwin as administrator (right click on icon & run as administrator) if you get a load of errors turn off your antivirus
Navigate to your kitchen folder (you can bring up a list of folders by typing ls and type cd to change directory
Type ./menu
Kitchen will start
You have the option to create a working folder which will look in the rom folder - if a tar file is acceptable it will extract your tar into a working folder - can't remember if that's how you do it
Next goto advance (or extra options can't remember what it says)
Goto deodex
You need to change the api level so it matches your Android version
Now you are finally ready to deodex
Deodex both folders
Once done build the rom (lazy mode options should be fine Think it signs rom create scripts & so on)
Once it's built collect your rom zip
Now download any custom stock rom - maybe hyperion 9 for 5360
Open your rom zip with winrar
Delete boot.img if present
Goto meta-inf folder and I think it's in com/google/andoid
Delete the update binary and replace with the one from hyperion9
Next open extract the updater script from both roms from the same folder the binary way in
Open them both in notepade++
Replace everything in your script above where the symlinks start with what is written in the hyperion9 one
Save & copy this script back to your rom zip meta in folder replacing the one that is there
Copy zip to sd card
Go into Cwm
Create a nandroid backup
Format system data cache
Mount system data cache
Flash your rom zip
Error codes
Status 0 wrong update binary
Status 6 error with updater script
Hopefully there will be no errors and it will flash and when you restart you will have a fresh deodexed rom
You can go into Cwm and advance restore data only
This should restore your contacts sms and app data
For extra storage create a 2nd ext partition on your site card in Cwm (note that this will format your ad card so copy it's contents to a pc then copy back once done)
Once you have a 2nd ext partition you can download link2sd from the playstore and link apps to sd card - you can also use the app to uninstall bloatware from the system
Note you will need to use a kernel that supports ext and try ext4 first from the link2sd menu that will pop up & work your way back up if that fails
I don't normally post such a long explanation but I'm feeling generous - anything else please research yourself
Click to expand...
Click to collapse
Well, thank you for your valuable time and efforts in getting me involved to the basics. your generosity is very much appreciated, I am on my path to research it all myself.
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.