any solution to fix the fingerprint on GSI? - Moto G7 Play Questions & Answers

Does anyone know if they already have a solution to fix the fingerprint on any GSI on the moto g7 play?

I don't think there will be a fix for it. GSIs are basically developed for testing purposes and are not functionally ROMs.
---------- Post added at 07:01 AM ---------- Previous post was at 06:58 AM ----------
https://source.android.com/setup/build/gsi

Guhl0rd64 said:
Does anyone know if they already have a solution to fix the fingerprint on any GSI on the moto g7 play?
Click to expand...
Click to collapse
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.

Spaceminer said:
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.
Click to expand...
Click to collapse
man, you are the g7 play hero ngl, can you post an explanation of what needed to be done when youve done it, you know like the technical side, so people like me can learn?

00p513 said:
man, you are the g7 play hero ngl, can you post an explanation of what needed to be done when youve done it, you know like the technical side, so people like me can learn?
Click to expand...
Click to collapse
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.

Spaceminer said:
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.
Click to expand...
Click to collapse
Wow, thank you very much my friend, I will test now

Spaceminer said:
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.
Click to expand...
Click to collapse
Thank you.
---------- Post added at 06:41 PM ---------- Previous post was at 06:40 PM ----------
Guhl0rd64 said:
Wow, thank you very much my friend, I will test now
Click to expand...
Click to collapse
So...?

Marcondes BR said:
Thank you.
---------- Post added at 06:41 PM ---------- Previous post was at 06:40 PM ----------
So...?
Click to expand...
Click to collapse
I installed by TWRP, I have Lineage OS 17.1, still with the same problem

Descendent Modified GSI, doesnt work. It sees the reader, but doesnt recognise me touching it

Spaceminer said:
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.
Click to expand...
Click to collapse
I have tested on several GSI, and I have had no success

Guhl0rd64 said:
I have tested on several GSI, and I have had no success
Click to expand...
Click to collapse
You might need to add ro.fpsensor.position=1 & persist.qfp=false to the build prop.

Spaceminer said:
You might need to add ro.fpsensor.position=1 & persist.qfp=false to the build prop.
Click to expand...
Click to collapse
it still didn't work

Guhl0rd64 said:
it still didn't work
Click to expand...
Click to collapse
I'm unfortunately out ideas at this point.

Spaceminer said:
I'm unfortunately out ideas at this point.
Click to expand...
Click to collapse
I guess this means no fingerprint on Ubuntu Touch when i get it to work

Related

[Updated] - How-to Theme Development

To create themes, or to edit themes to your liking, you will need a working knowledge of android, adb, how to resign apk's, knowledge of your own O/S.
Before you start be aware that you will may end up wiping your phone once, if not more. So lets go over the things that you will need.
You will need JF's RC30, RC8, or ADP1 V1.3, depending on what version you intend to create for.
Here is the link to these: http://forum.xda-developers.com/showthread.php?t=466174
You will also want to get the dev bootloader installed on your phone and to HIGHLY suggest everyone trying your theme to install it as well.
Link to dev bootloader: http://forum.xda-developers.com/showthread.php?t=455860
You will also need to resign all the apks located in /system/app and framework-res.apk located in /system/framework. When you push all of these to your phone.
JesusFreke was kind enough to build a custom signing tool for me that would allow me to right click on an apk and resign it from there. I am posting it here for others to use as well. Note that this is a courtesy of JF, so thank him for it. I cannot stress how much time this has saved me and will save you.
Here is the link: Http://www.FightForthePits.com/testsign(2).zip
Before using this you need to know how to set this up:
I will assume that you have the sdk downloaded and extracted somewhere(if not, do that now), extract both files to the tools directory of your sdk.
Now you will need to add the tools dir of your sdk to the environment variable CLASSPATH.(This is for XP, Vista coming soon)
To do this, right click on My Computer click properties, then choose the tab that says advanced. Click the button that says environmental variables. Go to system variables find the one that says CLASSPATH, double click it, go to the end of variable value. There should be a semicolon ; at the end. type in the path to the testsign.jar located in the tools directory of your SDK, for example the path to my testsign.jar was c:\sdk\android-sdk-windows-1.0_r1\tools\testsign.jar If CLASSPATH is not in your system variables then create it. Secondly, Find the system variable called PATH and add to the end of it, the full path to your sdk directory. For example, mine was c:\sdk\android-sdk-windows-1.0_r2\tools
Now right click the reg file that you extracted and choose to install it, or merge.
Now, right click an apk, do you see an option that says ResignApk? That's how you will resign your .apks and .zips.
If you find the right click menu not working for some reason you can type the following in cmd to sign your files: java testsign whateverfiletosign
Now through doing this you have done two things, first off you have made the resigning process extremely easy, secondly you will not have to cd to the tools dir of the sdk to use adb or any other tool in the sdk.
You will also need a version of linux installed or running vmware with linux, if you want to create, or edit, an update script, which will install the theme onto the users phone.
You will need to be specific in addressing what version your theme is for, RC8, RC30, or ADP1. Make sure every file gets signed. Make sure you test the update.zip before you release it.
Every .apk contains the images relating to itself. However, every apk has the ability to use the images in framework-res.apk. The images for every apk is located inside of itself. To find these images open up the apk, you can rename it to .zip or open it with an archiver of your choice, winrar, winace, etc. Then after opening the apk open the folder called res and inside of that there are folders that are named Drawable, drawable-land, drawable-port, etc. This is where the images are stored.
Ther are some things you cannot edit unless you rebuild the entire apk from source, which we will not go into here.(another tutorial, another time) Just know that at this time you SHOULD NOT edit, or even open images with the extension .9.png. If you do you will have problems...Trust me. These are special images called ninepatch images and android resizes these images to fit wherever android, or any other apk, needs it to. if you do open them or edit them they will no longer render correctly when resized. I believe that in order to edit these you must do so and then put them into the source and rebuild the entire apk.
Before getting started you must also realize that you cannot simply resign one or two apk's and stick them in your phone and expect them to work. You must resign every apk inside of /system/app and framework-res.apk and put them on your phone at the same time.
To simplify this process for you though, I have provided an empty update.zip which you can place all of your resigned apps into and use to update your phone to your custom theme. You can also download someonelses theme and use there files, since they are resigned already. It may also be easier to see what files do what and go where since they have already been edited and are easy to point out.
Now, your ready to start changing things up.
You will now need to open the apk, which you can do by adding .zip after .apk, effectively changing it to a zip. Note that if you are using windows you will need to unhide known file extension types. you can also use your favorite archiver such as winrar, winzip, etc.
See here to unhide known file extension types for Xp: http://www.mediacollege.com/microsoft/windows/extension-change.html
See here to unhide file extension types for Vista: http://maximumpcguides.com/windows-vista/how-to-change-a-file-extension/
After opening the apk go to res and copy the folders that have drawable in their name. Go to your desktop, or wherever, create a new folder called Images, or whatever. Open the folder, paste the drawable folders in there. Now you can see what the files look like without opening them. Btw, you may also want to add -frame, or -launcher, to the end of the folders you cope over to keep them separated from others.
Finally, you've edited the images put them all in the apk renamed it back to an apk and resigned it. Now it's time to push it to your phone and see the changes you've made.
Important! : Whenever pushing files to the phone NEVER do it while the phone is running. Do this in recovery mode! If you do this while the phone is running normally you will begin to lose space in /system.
So, boot into recovery plug your phone in and open a cmd prompt. From the cmd prompt type adb shell mount /system then type the following: adb push c:\whereveryourfileis\whateveryourpushing.apk /system/app (system/framework if your pushing framework-res.apk)
Now reboot your phone. If it doesn't boot, try doing a wipe, if that doesn't work reinstall an update and try again. There are alot of things people can do wrong, I can't explain them all here. If you get real stuck, you can ask for help here or contact me on Gtalk [email protected].
So now your theme is done and your ready to make an update.zip for others to install your theme.
I have created a template for you to make your own update.zip. Just download, add the system apps to app, and framework to framework. Zip it up, SIGN IT, TEST IT YOURSELF, and then distribute it!
Empty update.zip template: Http://www.FightForthePits.com/Androidstuff/update_empty.zip
If anyone has any questions please try asking for help in this thread before emailing me for help Usually I will respond to questions in this forum.
I hope this Tutorial has been helpful. I will add on to it as needed.
Stericson
Links of interest:
Downloading SDK: http://code.google.com/android/intro/installing.html
Using ADB: http://code.google.com/android/reference/adb.html
Working with ninepatch should be straightforward if you use the draw9patch tool included in the SDK. Documentation on usage here:
http://code.google.com/android/reference/draw9patch.html
JF could also save theme users a wipe by resigning /system/app/* and /system/framework/framework-res.apk in his builds with the test keys. Nice tutorial, btw.
However it doesn't. I have used that to no avail. I believe you need to edit the images, put them in the source then rebuild the apks from the source.
As for JF's update, it does not currently wipe your phone after install. So, for him to do this he would have to have his update do a wipe. So technically, they would still have to do this initial wipe.
Stericson
Stericson said:
However it doesn't. I have used that to no avail. I believe you need to edit the images, put them in the source then rebuild the apks from the source.
Click to expand...
Click to collapse
Good point. I thought you could simply drop a similarly dimensioned PNG in but apparently there is some metadata that only the android tool can create.
As for JF's update, it does not currently wipe your phone after install. So, for him to do this he would have to have his update do a wipe. So technically, they would still have to do this initial wipe.
Click to expand...
Click to collapse
True, but a user who is upgrading to a JF update after having put in customized (and test-key signed) system apps will have to wipe again anyway =) Anyone using custom themes will have to wipe every time a JF update (or any update) comes out. However if JF resigns, custom theme users would not have to wipe and stock theme users only have to wipe once. (Nevermind the fact I think everyone should wipe when updating...)
thx stericson this will help big time how long before I can get resigned rc30 last night when you said all the apk. need to be resigned I was like this is going to be a long night but I see jf hooked you up save some big time with his resigning tool
jashsu said:
Good point. I thought you could simply drop a similarly dimensioned PNG in but apparently there is some metadata that only the android tool can create.
True, but a user who is upgrading to a JF update after having put in customized (and test-key signed) system apps will have to wipe again anyway =) Anyone using custom themes will have to wipe every time a JF update (or any update) comes out. However if JF resigns, custom theme users would not have to wipe and stock theme users only have to wipe once. (Nevermind the fact I think everyone should wipe when updating...)
Click to expand...
Click to collapse
Ah, good point
The resigned apps will be released maybye sometime tonight...I had them done but ran into a script problem on adp1 and I have yet to try the rc30 and rc8 ones yet. so I won't release those until I've tested them. If you want to be a Guinea pig however, just let me know
Stericson
Stericson said:
Ah, good point
The resigned apps will be released maybye sometime tonight...I had them done but ran into a script problem on adp1 and I have yet to try the rc30 and rc8 ones yet. so I won't release those until I've tested them. If you want to be a Guinea pig however, just let me know
Stericson
Click to expand...
Click to collapse
The resigned apps have been released, each update file will resign all of apps in /system/app and framework-res.apk. However, these updates make no changes to them whatsoever...Meaning your phone will look just like a brand new phone without any modifications.
rc30 works thx Stericson made it easy for use
Issues with using the update.zip above
Hi all,
I just wanted to point out that after I applied the update.zip above and rebooted applications kept force closing randomly and constantly even through the initial setup (where you have to click the green android to start).
Prior to this, I had JF's RC30 1.3, and the engineering bootloader V2 no sigcheck.
First I did just a alt+s then a alt-w and alt+s. And still nothing.
I'm new to all this so I'm not even sure where to begin troubleshooting. Should I be using the HardSPL?
Thanks in advance and I appologize if this isn't the right place for this post.
Update:
After reflashing with JF's 1.3 RC30 and the problem persisted I noticed that there was a new release 1.31 and this has fixed the problem. I hope this helps anyone else who runs into the same problem.
I still don't know what went wrong though, can anyone shed some light on this? thanks.
Truly there's no telling, sounds like J'f's update fixed it. Can I ask what version you tested?
I would also like to announce that now, thanks to JF, again, you do not have to wipe your phone completely to apply the resigned app updates. However, you will have to re-enter your google info and your call history and other minor things will be gone, but all of your apps will be retained.
Stericson
Alright, I am a little confused........
So I downloaded testsign.zip and extracted it to the tools folder. Then I went into environmental variables and added CLASSPATH with the value D:\Android\tools\testsign.jar and now I am not sure what to do next. Can someone give me some clarification. And btw I am on XP but I can get on linux at home if I need it, but I am a total noob to all this stuff so be gentle.
I'm using http://www.fightforthepits.com/Androidstuff/update_Rc30.zip and have been encountering issues when the phone boots up. As soon as the initial phone setup comes up I get process force close errors, I extracted launcher.apk, edited the files I wanted, repacked it, signed it and then resigned the update.zip. Any ideas what I'm doing wrong? I'm already running JF's RC30 1.31
Did you repack it in linux? Did you resign Launcher.apk? Also, that update file was never meant to be used as a template for an update since it kind of wipes your phone. You should be using update_empy, to push your own theme.
If you want to do only one file at a time, flash that update(update_rc30) then adb push your file into system/app. There are lots of things that you can mess up, most of them are hard to catch too. At any rate, everyone who has made a theme can tell you it's not just a straight forward process, expect errors. I've had more than I count I know....
Trial and error is your best teacher
Stericson
Stericson said:
Did you repack it in linux? Did you resign Launcher.apk? Also, that update file was never meant to be used as a template for an update since it kind of wipes your phone. You should be using update_empy, to push your own theme.
If you want to do only one file at a time, flash that update(update_rc30) then adb push your file into system/app. There are lots of things that you can mess up, most of them are hard to catch too. At any rate, everyone who has made a theme can tell you it's not just a straight forward process, expect errors. I've had more than I count I know....
Trial and error is your best teacher
Stericson
Click to expand...
Click to collapse
Must .apk's be signed if they're pushed over ADB? I'm not running Linux, I'm repacking/signing in windows.
I also had the issue with force close when installing the resigned update from the first post, apps that shouldn't even run on start up were force closing.
Also the IM application was gone, had to do a wipe and go back to jf 1.31 to correct it
I will take another look at the update I provided...
Stericson
did you ever figure out how to change the text on the status bar from black to white?
to do that you have to rebuiuld the entire apk from source and edit an xml document
Stericson
has anyone tried making the icons bigger? I noticed they are 48x48 if we go bigger will that affect anything? Also has anyone been able to remove the text below the icons on the home screen? Oh and where is the tab located that has been made invisible?
*edit
well I tried making the icons bigger and it doesn't really do anything, they don't show up bigger on the screen. Might have something to do with the text underneath, not sure.
Kyeld said:
Must .apk's be signed if they're pushed over ADB? I'm not running Linux, I'm repacking/signing in windows.
Click to expand...
Click to collapse
yes they must be signed.

*OUTDATED* ROM porting for kaiser/vogue [Linux] NOOB friendly!

THIS IS NOW OUTDATED!!
It uses the old sqsh method WITH a rootfs. So if you're using the NoMoRootfs method, this won't work. Please use the already complete builds in the Kaiser/Vogue threads as they are working the best at this moment.
DISCLAIMER:
I take no responsibility for anything that may happen to your phone/computer. Use at your own risk.
PURPOSE:
This is for informational/testing purposes. And for people to stop asking, "can somebody port X rom!!! PLZ!!!"
PREFACE:
I made this as a quick tool to port ROMs from the Dream/Sapphire forums to work with our phones. It's a very quick and dirty script I threw together using bash, so there's probably some problems with it. This tool is simply designed to make a copy of the Dream/Sapphire ROM. Once you get the setup, it's really easy and you'll be porting like crazy.
I did this all on Ubuntu 9.10 so things might not work properly if you're using another distro.
THANKS:
All credit goes to the people that made this possible, in no particular order...
dzo, vilord, mssmison, zen, enatefox, pmos, jamezelle, craig0r, cyanogen, and so many more. If I forgot you, I'm sorry, but you know if you helped in some way.
THE SETUP:
1) Download this file
2) Extract the folder to your desktop. Then copy and paste the following code into the terminal:
Code:
sudo mv -f $HOME/Desktop/Android/genext2fs /bin/genext2fs; sudo chmod 755 /bin/genext2fs; sudo dpkg -P squashfs-tools; sudo dpkg -i $HOME/Desktop/Android/squashfs-tools_3.3-7_i386.deb; sudo rm -r $HOME/Desktop/Android/squashfs-tools_3.3-7_i386.deb; sudo chmod 777 $HOME/Desktop/Android/*.build.script
3) Now go into synaptic package manager, search for squashfs-tools, select it and under Package, check Lock Version so that way it won't try to update.
4) Now cruise over to the Dream android development forum or the Sapphire android development forum and download the ROM you would like to port. Place the zip file in the Android folder. (no need to rename)
5) Place any .apk's you would like built into the system in the Apps folder.
ADVANCED SETUP:
If you would like to tweak the system before building, open the script in a text editor and you'll find a line to uncomment that will halt the script until you are ready.
HOW TO RUN:
Either run the script from a terminal
Code:
./$HOME/Desktop/Android/HERO.build.script
or
./$HOME/Desktop/Android/Donut.Build.script
Or double click and Run in Terminal
You will get a prompt for your password to use the sudo command. THIS IS NOT SAVED ANYWHERE OR MAGICALLY SENT TO ME. It is just to get the system.sqsh setup for you to use.
You will now see a Donut/Hero folder inside the Android folder. Inside that will be a nice little system.sqsh with the date ready to boot!
*Rename to system.sqsh when you put on your SD card*
Grab the latest basefiles from vogue-android and you're good to go.
~~~~~~ To get an output of what's happening run in a terminal as described above but add " > build.txt" and you'll see a txt file in the Android folder. ~~~~~~~
CHANGING SYSTEMS:
If you want to port a new rom, replace the .zip.
UPDATES:
1) Download the updates from HERE
2) Extract to the Android folder overwriting if necessary.
3) Copy and paste the following code into a terminal:
Code:
sudo chmod 777 $HOME/Desktop/Android/*.script
CLEANUP:
If you follow the advanced setup and/or accidentally closed the terminal before the build finishes, run the cleanup script. This will unmount everything that might be mounted and delete all folders that are made during the process.
DOWNLOADS:
If you're too lazy or just want a quick link:
Main "Android porting" folder
Updates
Input, testers, bugs, and tweaks to the scripts are appreciated!
FAQ:
Why does my system.sqsh not work?
Most likely cause is that you're not using the correct version of squashfs-tools. You'll have to find version 3.X for the distro you're using. Version 4.X will NOT work!!!
When I try to boot a system.sqsh I just made I keep getting something about android power wake locks. WTF?
You're probably trying to port an eclair or cyan ROM. These don't work at the current state. Hopefully soon I'll get these working.
Will update more when they arise.
CHANGELOG:
11-27-09:
-Created a cleanup script in case the terminal is closed during the build process.
-Bug fixes in Donut and Hero scripts
11-24-09:
-Added an Apps folder for apk's you want built into the system.
-Bug fixes in scripts
11-22-09:
-Combined everything needed into a zip file
-WAY easier to setup
11-20-09:
-Added feedback to make more user friendly
-Append time to system.sqsh
loserskater said:
Input, testers, bugs, and tweaks to the scripts are appreciated!
Click to expand...
Click to collapse
Will try today... Downloading
Tried and working. Had to change the script for it work with ubuntu version that i use. Thanks this is really great
garynsa said:
Will try today... Downloading
Tried and working. Had to change the script for it work with ubuntu version that i use. Thanks this is really great
Click to expand...
Click to collapse
What did you change?
Glad to see it's working.
loserskater said:
What did you change?
Glad to see it's working.
Click to expand...
Click to collapse
hI
For some reason I cannot use -a in the genext2fs command. Had to remove that..
One of the Donut is working. Couldnt get the Cyanogen build working . Struggling with hero build also.
Will try again in the next couple of days and post results.
Thanks
garynsa said:
hI
For some reason I cannot use -a in the genext2fs command. Had to remove that..
One of the Donut is working. Couldnt get the Cyanogen build working . Struggling with hero build also.
Will try again in the next couple of days and post results.
Thanks
Click to expand...
Click to collapse
Make sure you use the genext2fs that I referenced.
That one works with -a and might take care of some issues. try that and see if it works.
Updated script to now move system to a Hero or Donut folder.
Working on the cyanogen build now...
EDIT: Here's a cyanogen script that gets it to boot, but sits at a black screen. I haven't had much time to test it so it might boot further than that if you leave it. If somebody wants to test this out or tweak it in some way go for it.
It uses the donut.sqsh in the Android folder so you shouldn't have to do anything with it except make it executable.
EDIT 2: Still working on cyan builds... that script didn't work.
great job i like to see stuff like this to motivate people!!! also note this will work with any donut or hero build from the sapphire forum
jamezelle said:
great job i like to see stuff like this to motivate people!!! also note this will work with any donut or hero build from the sapphire forum
Click to expand...
Click to collapse
Good point, forgot to mention that. Updated first post.
I'm hoping it will help people start to learn to tweak system's. But I have a slight feeling wer're going to start seeing a lot of "MLIGN/DWANG/etc's Android Rom" threads from random people.
Hi
Was able to port the DWANGs build using your script. Thanks a lot for making life this simple. Howev3er, hero build is still not working. Tried your genesxt2fs. Is it possible to get the links to correct base hero version to use? I tried magic and normal version. It keeps giving me black screen and doesnt completely boot. I think the base hero version is not the right one i am using
Thanks
OK, I think I figured out the problem. The apps folders weren't copying over from the data folder to the system folder correctly. Testing now, and will update first post with new scripts.
EDIT: Finally got the Hero builds working correctly. You should still be able to use any hero.sqsh.
loserskater said:
OK, I think I figured out the problem. The apps folders weren't copying over from the data folder to the system folder correctly. Testing now, and will update first post with new scripts.
EDIT: Finally got the Hero builds working correctly. You should still be able to use any hero.sqsh.
Click to expand...
Click to collapse
Hi
The new script is great.. I was able to get the hero to boot I still have 2 check a few thing willl post later in the night with more
Thanks a lot
garynsa said:
Hi
The new script is great.. I was able to get the hero to boot I still have 2 check a few thing willl post later in the night with more
Thanks a lot
Click to expand...
Click to collapse
Glad to see its working. Thanks for the feedback!
Most things working
Hi
was able to get the hero ported and a few things worked
1. Calls
2. SMS
3. Wifi (getting ips)
4. Working with partition rootfs (speed quite great with this)
Not working
1. Camera
2. GPS
I am using he ION build to build the hero roms (based on the inputs of Zen). May be I need to use another hero rom for the camera to work? I recommend that the links to the recommended build to be used as template (donut, hero...) be updated on the first thread to make it easy for others to have a single starting platform
garynsa said:
Hi
was able to get the hero ported and a few things worked
1. Calls
2. SMS
3. Wifi (getting ips)
4. Working with partition rootfs (speed quite great with this)
using u
Not working
1. Camera
2. GPS
I am using he ION build to build the hero roms (based on the inputs of Zen). May be I need to use another hero rom for the camera to work? I recommend that the links to the recommended build to be used as template (donut, hero...) be updated on the first thread to make it easy for others to have a single starting platform
Click to expand...
Click to collapse
If using a hero.sqsh doesnt fix the problem it sounds like it might be the rootfs (probably not copying over correctly). Ill take a look at it when I get home and update the first post with hero/donut.sqsh's.
Im also thinking about combing the 2 into just one script and youll be able to just type which build you want when you run it. What do you think? Or is the 2 seperate scripts more convenient?
loserskater said:
If using a hero.sqsh doesnt fix the problem it sounds like it might be the rootfs (probably not copying over correctly). Ill take a look at it when I get home and update the first post with hero/donut.sqsh's.
Im also thinking about combing the 2 into just one script and youll be able to just type which build you want when you run it. What do you think? Or is the 2 seperate scripts more convenient?
Click to expand...
Click to collapse
Personally i prefer the separate scripts mainly because each requires a different base templates. However if you prefer to combine them may be have sub-folders within the main so that the work happen for each port within the sub-folder.
Few suggestions if you like (please ignore if not correct.. being a non-programmer of linux I can be a bit off )
1. Let the folder names be requested at start and use them
2. If possible to put in a log of the run to check if there were issue or not (because i use double-click to run the script sometimes there is a problem that i face if i dont watch the window. for now i have put some waits to check the errors. Had this issue while testing to port one)
If I can help (except on coding as I dont know it.. generally change the script just enough to work... )
Queries/questions
1. Is there a way to test the build on the comp itslef rather than to keep booting on the phone (takes a lot of time and the phone is not usable all that time...)
Thanks for all the work
garynsa said:
Personally i prefer the separate scripts mainly because each requires a different base templates. However if you prefer to combine them may be have sub-folders within the main so that the work happen for each port within the sub-folder.
Few suggestions if you like (please ignore if not correct.. being a non-programmer of linux I can be a bit off )
1. Let the folder names be requested at start and use them
2. If possible to put in a log of the run to check if there were issue or not (because i use double-click to run the script sometimes there is a problem that i face if i dont watch the window. for now i have put some waits to check the errors. Had this issue while testing to port one)
If I can help (except on coding as I dont know it.. generally change the script just enough to work... )
Queries/questions
1. Is there a way to test the build on the comp itslef rather than to keep booting on the phone (takes a lot of time and the phone is not usable all that time...)
Thanks for all the work
Click to expand...
Click to collapse
I'll try to make the script more user friendly with prompts if something doesn't happen correctly. And also work on naming folders.
But first I want to figure out the camera/gps issues...
There isn't a way to boot it on the comp that I know of. I'll upload blank data.img's for each build so that they'll boot faster but other than that I think moving to SD Card and booting is the only way. But once all these bugs get sorted out, you won't have to do it as often!
EDIT: Which folders would you like to name? Just where the system.sqsh gets stored?
loserskater said:
I'll try to make the script more user friendly with prompts if something doesn't happen correctly. And also work on naming folders.
But first I want to figure out the camera/gps issues...
There isn't a way to boot it on the comp that I know of. I'll upload blank data.img's for each build so that they'll boot faster but other than that I think moving to SD Card and booting is the only way. But once all these bugs get sorted out, you won't have to do it as often!
EDIT: Which folders would you like to name? Just where the system.sqsh gets stored?
Click to expand...
Click to collapse
Hi
Thanks for the answers. For me it should be both (but the starting folder is main. Other can be a sub-folder like u have now to be renamed as choice)
garynsa said:
Hi
Thanks for the answers. For me it should be both (but the starting folder is main. Other can be a sub-folder like u have now to be renamed as choice)
Click to expand...
Click to collapse
Are you referring to the Android folder? Or just a folder where everything is kept when it runs?
loserskater said:
Are you referring to the Android folder? Or just a folder where everything is kept when it runs?
Click to expand...
Click to collapse
Android folder... but its not a big deal as one can easily change it while startign the script

Howto make a permanent change to $PATH?

Is there a way to make a permanent change to the $PATH variable to place /system/xbin ahead of /system/bin? I found /init.rc when the phone is booted, but obviously I can't make changes to that yet. When booted into recovery, I can't find the same file to edit it. The /init.rc file is specific to the recovery image at that point.
Basically, I have busybox installed in /system/xbin and want it to override the /system/bin apps. I do not want to install busybox in /system/bin.
Any help would be appreciated. Thanks!
are you trying to export a path? if so it would go something like
export PATH=$PATH /system/bin
or you can
PATH=$PATH /system/bin
export PATH
B-dub25 said:
are you trying to export a path? if so it would go something like
export PATH=$PATH /system/bin
or you can
PATH=$PATH /system/bin
export PATH
Click to expand...
Click to collapse
He's trying to make it so he doesn't have to reset the $PATH variable every time. I'm assuming you are currently just using something like.
export PATH=/system/xbin:/sbin:/system/sbin:/system/bin
every time you enter shell. The way I would do it is by editing the init.rc as you stated, however it doesn't stick on the incredible, also as you stated.
The only thing I can recommend is making it a shorter PATH to type. You could just enter
export PATH=/system/xbin:$PATH
for example, and that would accomplish the same thing with less typing.
The only other way that I know of would be to make a start-up script, not sure how to accomplish this outside of init.rc however. In linux I would add it to the bash_profile or something similar. Not sure how to do it in android...
Not only for shell, but I'd like to be able to do it for installed apps as well, such as OpenVPN. Ah well, just have to wait for full root unlock.
This is done in the ramdisk. You can actually do this yourself. You need to extract the boot image, break it apart into the ramdisk and kernel, alter the init.rc file, package it back up and then flash it back to your phone in recovery.
Even if we get the nand unlocked, you will still need to do this since the init.rc recreates itself from the ramdisk during each boot.
If you are using a custom ROM, just request the dev to do this.
ihtfp69 said:
This is done in the ramdisk. You can actually do this yourself. You need to extract the boot image, break it apart into the ramdisk and kernel, alter the init.rc file, package it back up and then flash it back to your phone in recovery.
Even if we get the nand unlocked, you will still need to do this since the init.rc recreates itself from the ramdisk during each boot.
If you are using a custom ROM, just request the dev to do this.
Click to expand...
Click to collapse
Thank you kindly, didn't know where those files were kept. Interesting how that works, so basically the phone works like a hardware chip, where the main parts of the OS recreate themselves from ROM, similar to firmware... I like it... prevents corruption I suppose.
Out of curiosity (I've never made a ROM, and therefor never packaged the boot image), is it packaged as a tarball? Or do you require ADB to extract? If you don't want to answer, I can probably track it down somewhere.
It's a bit more complicated than that. Take a look at this link. I'm sure there are other ways, but I would recommend only doing this in some flavor of Linux like Ubuntu.
HOWTO: Unpack, Edit, and Re-Pack Boot Images
ihtfp69 said:
It's a bit more complicated than that. Take a look at this link. I'm sure there are other ways, but I would recommend only doing this in some flavor of Linux like Ubuntu.
HOWTO: Unpack, Edit, and Re-Pack Boot Images
Click to expand...
Click to collapse
Cool link. Thanks.
But yea, pretty much seems to be that simple, Just a gzip (zip) and tarball (cpio). The only thing I wasn't expecting was stripping out the 2k header with a hex editor, but I think I'll try using the scripts found through that link to do that, not that I couldn't do it by hand... but I'm lazy...
Thanks again.

[Guide] Android Cooking Guide for HD2 [Guide]

heartsurfer008 said:
Well I am desparetly trying to cook a NAND build for my HD2 but there is pretty much less info available for me [a big NOOB in cooking] to try out my luck at cooking..!!!
So I'll appreciate if someone would put some light on it..!!!
PS: - I would appreciate if somebody can provide a detailed info..!!!
Click to expand...
Click to collapse
Finally the tutorial
Make your own Android Build for the HD2 by domineus ​I have always lived by these words- if you give a man a fish, he can eat for a day; but if you teach a man to fish you can eat for a lifetime. Android on the HD2 has always been an interesting thing for me and I know a lot of people that want to create their own builds, but have no idea how. If you ask a build creator or maybe someone in the htc-linux-chat how to get started, there may not be an answer. In fact, some of the perplexing behavior has left me puzzled in several ways - as if how to get an android build is a vaulted secret of knowledge like the holy grail. To be honest, it's not. It's a bit of hard work, a few nods in the right direction, and ultimately it's a community involved project. Just like miui development is a community project spanning actual continents to get this thing on our device every single week! It has led to a lot of questions, in my inbox, of how to begin. For a long time, the answer to the question was not answered until Cass helped me out. I want to do the same and contribute how to get a build of miui (or any android build) to the HTC HD2.
Things you will need
In order to properly start android development, it would be a good idea to make sure you have the following (a lot of it is no duh when you think about it)
A computer running linux
I can't stress that enough. While there is a lot of things you can do in windows, you will need some sort of linux distro in order to get android properly running on your HD2. There are a lot of linux distros you can use; with many using ubuntu as it is the most user friendly. I use Fedora and I am quite happy with the results. It's simple and effective. It gets the job done. Get a distro that you feel can get the job done.
Android SDK - either windows or linux
Android SDK is something that can be freely accessed and downloaded from the following location:
http://developer.android.com/sdk/index.html
It is a developer environment, but probably the most important thing you can use here (for the time being) is logcat. Logcat provides you to visually see the libraries and files working together to get android to work as well as if you run into an issue, it is the first thing you should resort to. For instance, boot reloop? Take a look at your logcat and try again.
A kernel
There are quite a few kernels available for android previously and they are divided into evo kernel or nexus one kernel. Many builders have transitioned to an evo kernel for PPP and a few other nice details but it is totally up to you. I highly recommend hastarin's kernel. For most of the time, it works well. But as you have noted, on MIUI, it hasn't been working as fantastic on other builds.
Donor Files
This is a bit difficult to find because it appears that the files that work best are nexus one builds without CM6.1 modification. So far, only one chef has that and it is tytung's nexus one build. Regardless of whose files you're using (e.g. tytung or darkstone's system which is the preferred choice) you will need a well working android build. You will be pulling several files in order to port.
MIUI itself (well any build honestly just miui is a good example)
This is a given. However, if you download from miui.com you will probably have an untranslated rom with odex files. That's bad. And in Chinese! It would be a good idea to browse the English forum for a deodexed rom with appropriate english translation (apps and frameworks)
-If pulling files from windows, you will need this
system extractor
http://uranus.chrysocome.net/linux/explore2fs-old.htm
I use that if I download in windows. It's relatively straight forward and it allows you to pull the files you need from the system.ext2 you're using and copying them to folders necessary.
build.prop
This you will need. You can find one here:
http://www.multiupload.com/B59IU3S6XY
Patience
Probably the most important thing. One thing I have noticed is you need patience to make it through. Sometimes, your build works, sometimes it doesn't. And it is difficult to still keep going. But gotta pull it all in and keep trying...it does pay off.
Okay so you have your files, a nice linux distribution, your build you want to port (MIUI preferrably) and you're ready to go. Now it's time to begin the process!
Step One - The Setup
I usually grab my files in windows before transitioning to my linux distro to finish the process. If you using windows 7 and you are using explore2fs, you will definitely have to right click on the exe and make it compatible by selecting compatible with windows vista. The file should also need to be run by administrator. If you don't know how to do that you can google compatibility in windows 7.
First thing is first. Create a new folder, you can call it donor_files if you want because name is arbitrary. The most important thing is to just name it. Within that folder, create a new folder called system. Enter the system directory and create a new folder called etc. Within etc, select Once that is done, create a new folder within etc called firmware. Once completed, return back to the system folder, create the folder called lib. In the lib folder, create a new folder called hw. So your folder should look like this:
Folder Name
-system
--etc
---firmware
--lib
---hw
So far so good? Excellent. Now, if you're in windows you will need to do a few things. Extract the system.ext2 of your donor build and place it somewhere you will remember (like your desktop). Now open up explore2fs, select file, and open image file. Under files of type (drop down), select all files and navigate to your system.ext2 file. You should now see the ext loaded on the left side of the program's workspace. Located is a very small + that allows you to view all directories in your ext2 file. Click that.
You will see several system folders on the left and files on the root. Since you haven't selected a specific folder, in the right hand view, you should see the file build.prop. If you did select a folder (like app) you will see some files. And that's okay too. Get a feel of the program.
Now you will do a test file pull. On the left hand side, select the folder etc. On the right window, you will see several files. We want AudioBTID.csv. Once you see the file, right click on AudioBTID.csv and select export file. Navigate to the donor file folder (or whatever you named it) and place the file in system/etc of that folder. Congratulations you just pulled your first file! But you will need a lot more files. Within the same directory, pull gps.conf, hosts, media_profiles.xml and the ppp folder. Now, navigate to firmware and pull the following files:
BCM4329B1_002.002.023.0360.0362.hcd default_france.acdb htcleo.acdb
BCM4329B1_002.002.023.0436.0439.hcd default_nel.acdb yamato_pfp.fw
bcm4329.hcd fw_bcm4329_apsta.bin yamato_pm4.fw
default.acdb fw_bcm4329.bin
Ideally you should not be able to find htcleo.acdb. You can find it here
http://gitorious.org/xdandroid_leo/q...eo/htcleo.acdb
Now in explore2fs, go to the lib directory and pull these files and place them in your lib directory:
libcamera.so
libcamera_client.so
libcameraservice.so
libhtc_ril_wrapper.so
libmm-omxcore.so
liboemcamera.so
libomx_aacdec_sharedlibrary.so
libomx_amrdec_sharedlibrary.so
libomx_amrenc_sharedlibrary.so
libomx_avcdec_sharedlibrary.so
libomx_m4vdec_sharedlibrary.so
libomx_mp3dec_sharedlibrary.so
libomx_sharedlibrary.so
libomx_wmadec_sharedlibrary.so
libomx_wmvdec_sharedlibrary.so
libOmxCore.so
libOmxVdec.so
libOmxVidEnc.so
libqcomm_omx.so
libstagefright_omx.so
Once those files are pulled, navigate to the hw folder of the system and pull the following files:
sensors.htcleo.so
lights.htcleo.so
Once those files are pulled, you can save your donor files to a flash drive and then boot into your linux distro. Login to superuser in terminal. For fedora, the proper method involves typing in su --login and entering your password you set up. Minimize your terminal window.
Extract the miui (or any other build) to your desktop (the focus is the system folder). Ensure the rom is deodexed and in your own language (if its miui, you will have to apply the proper language translations). Now copy the files you pulled from your donor build and apply it to the appropriate folders (usually a copy and a paste-literally). In this instance there will be duplicate files, overwrite them. That's the point! Do not forget the build.prop file I linked to earlier. You should add that to system folder.
So the files are copied, the next step is to restore the minimized terminal window (the one that is logged in as root). cd to where your system is located (not to the system folder itself). Now you will have to enter the following commands in terminal
chmod -R 777 system/etc
chmod 755 system/bin/*
chmod 755 system/xbin/*
rm system/etc/firmware/default*acdb (if you have sound in call issues)
touch system/etc/ppp/active (If you have latest wrapper and need ppp)
chown root:2000 system/bin/pppd
chmod 4755 system/bin/pppd
chown root:root system/xbin/su
chmod 4755 system/xbin/su
chown root:root system/xbin/hci*
chmod 4755 system/xbin/hci*
dd if=/dev/zero of=system.ext2 bs=1048576 count=256
mke2fs -F system.ext2
sudo mount -o loop system.ext2 /mnt2
cp -rp system/* /mnt2
sudo umount /mnt2
A few words on this that I must bold. the /mnt2 directory may not exist. If not, try mnt, that usually works
Once this is done, you will have a nice system.ext2. The only thing you'd need now is a rootfs, a kernel, clrcad.exe and a startup.txt file. Once that is done, you can test your build out.
Any questions
Special thanks to Cass and the htc-linux-chat for the few pointers they gave me.
The guide is by "domineus - http://www.miui-dev.com/" & I take no credit what so ever​
Thanks to "white-energy" for giving us the link..!!!
Hope to have many more Chief's for our HD2, so that we [especially me] can satisfy our hunger to try different builds/ROM's..!!!
Happy Cooking..!!!​
PLEASE PRESS THANKS IF YOU FOUND THIS THREAD USEFUL..!!!​​
+ 1... nobody wants to share information?
I don't know if this help but you can try
http://forum.xda-developers.com/showthread.php?t=897940
These kind of thread pop up once in awhile, but it's going no where, I've never seen well known chef show up in this kind of thread.
knowledge is power, maybe they dont want to share the power
Can anybody out there give us a step by step guide for cooking a NAND ROM for HD2..???
http://www.miui-dev.com/forums/showthread.php?481-Howto-Make-your-own-Android-Build-for-the-HD2
Instead of making a ext image, you should make a yaffs image.. so it can work on Nand
white-energy said:
http://www.miui-dev.com/forums/showthread.php?481-Howto-Make-your-own-Android-Build-for-the-HD2
Instead of making a ext image, you should make a yaffs image.. so it can work on Nand
Click to expand...
Click to collapse
Thank you, please check post 1..!!!
I've been looking for something like this. I want to create my own build for the recovery flasher. I guess the only thing needed would be how to convert from regular nand to recovery.
Thanks bro.
velayo said:
I've been looking for something like this. I want to create my own build for the recovery flasher. I guess the only thing needed would be how to convert from regular nand to recovery.
Thanks bro.
Click to expand...
Click to collapse
I was lookin for the same & credit goes to domineus & white-energy
& "white-energy" comes up with a NAND ROM..!!!
Congrats..!!!
white-energy said:
http://www.miui-dev.com/forums/showthread.php?481-Howto-Make-your-own-Android-Build-for-the-HD2
Instead of making a ext image, you should make a yaffs image.. so it can work on Nand
Click to expand...
Click to collapse
Are you sure its the only difference? Are the nand drivers stored only in the bootimg/initrd and not somewhere in the system.img?
yes or no will do for me thx
Is there a way to edit system.bin files, that comes with the NAND builds. I suppose that is where the ROM is. I want to unpack, edit the included apps and repack. How it is done? How the bin file is done. Google does not give any satisfiable links, did a quick search, though...
i am confused
Which explore 2fs do I download? There are 3 different ones one for binary one for code and optional update source code. I am a noob and tired of not having roms I am happy with. I have windows 7 and xp. I realize this will take time and I am good with it everything thats worth anything takes time.
deckoff said:
Is there a way to edit system.bin files, that comes with the NAND builds. I suppose that is where the ROM is. I want to unpack, edit the included apps and repack. How it is done? How the bin file is done. Google does not give any satisfiable links, did a quick search, though...
Click to expand...
Click to collapse
I think you mean system.img not system.bin
You can extract them with the unyaffs.exe or with the unyaffs command under linux. I have written a guide with attatched utilities here
Additionally birksoffsjunk (seasoned WM guru & chef of ChuckyDroid, ChuckyROM, & Dexter) has made a batch program to make this process easier. It's a work in progress & somethings are still buggy so follow the thread
Between the utility birkoffsjunk made & the tutorial I wrote you should be able to successfully edit & run your own build. Hope this helps.
deckoff said:
Is there a way to edit system.bin files, that comes with the NAND builds. I suppose that is where the ROM is. I want to unpack, edit the included apps and repack. How it is done? How the bin file is done. Google does not give any satisfiable links, did a quick search, though...
Click to expand...
Click to collapse
I think you mean system.img not system.bin
You can extract them with the unyaffs.exe or with the unyaffs command under linux. I have written a guide with attatched utilities here
Additionally birksoffsjunk (seasoned WM guru & chef of ChuckyDroid, ChuckyROM, & Dexter) has made a batch program to make this process easier. It's a work in progress & somethings are still buggy so follow the thread
Between the utility birkoffsjunk made & the tutorial I wrote you should be able to successfully edit & run your own build. Hope this helps.
anyone know how to edit or anything about initrd.gz?
hnamanh said:
anyone know how to edit or anything about initrd.gz?
Click to expand...
Click to collapse
It's an archive that can be decompressed and edited thru linux.
White-Energy use system.bin in his rom
Regarding initr and zimage, there is a guide that you can point me on ?
Thank you
KillaHurtz said:
I think you mean system.img not system.bin
You can extract them with the unyaffs.exe or with the unyaffs command under linux. I have written a guide with attatched utilities here
Additionally birksoffsjunk (seasoned WM guru & chef of ChuckyDroid, ChuckyROM, & Dexter) has made a batch program to make this process easier. It's a work in progress & somethings are still buggy so follow the thread
Between the utility birkoffsjunk made & the tutorial I wrote you should be able to successfully edit & run your own build. Hope this helps.
Click to expand...
Click to collapse
I have only green HTC
Hello
I would like to use Android on my HD2. I was searching and testing many ROMS but I didn´t find any rom which is usable for me. I would like to have a ROM that is without Sense, has Multilanguage support and is on Android 2.2 version.
So I decided that I would make my own.
0) I was reading
HTML:
http://forum.xda-developers.com/showpost.php?p=10291851&postcount=1
and made this procedure.
1)downloaded some ROM from here
2)unpacked this rom in linux with :
Code:
unyaffs system.img
then I got this directories:
Code:
app bin build.prop etc fonts framework lib media usr xbin
3)I downloaded update-cm-6.1.1-N1-signed.zip from CyanogenMod Forum > Downloads > Stable Mod > Nexus One and unpacked. I got : META-INF system boot.img.
4)I copied everything what was described step 0 from directories from step 2 to directory system from step 3
5)I downloaded and copied build.prop from step 0 to system
6) I updated permition like it is described in step 0
7) I created system.img with command : mkyaffs2image . ../system.img
Then I copied this system.img from linux to my windows and put this file in directory in which was different NAND rom. (replaced system.img). After that I flashed my phone and it did not work. Screen was frozen after booting and only green HTC was on display.
Can somebody please help me and give me some advice or some small howto. Does anybody know what can be wrong?
Thank you
Michal Fichtner
I appreciate the guide but damn that is hard to read. It really needs some sort of structure to it, titling proper paragraphs etc.
Hi,
it is possible to combi the dropdown energy widget froom miui and the gingerbread lockscreen into Desire HD Build?
Thats was awesome !
Sorry for my bad english

[OBSOLETE THREAD] Rooting LG G4S (H735)

[OBSOLETE THREAD]
This thread is obsolete. A solution was found, which is posted here:
http://forum.xda-developers.com/g4/help/method-to-root-lg-g4s-model-h735-lg-g4-t3248030
Please use the new thread for discussions.
------------------------
Original thread:
------------------------
Hi,
I have been trying to root the LG G4S (H735), also known as "LG G4 Beat".
I tried two things:
Approach 1
I tried the method posted by konsolen in this thread:
http://forum.xda-developers.com/g4/general/lg-g4s-world-root-lg-devices-t3231759
but it didn't work for me. I tried several times with varying approaches, but the boot process always gets stuck on the LG logo.
Approach 2
I also tried to inject the root as suggested in this thread for the G4:
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491
I've used the Inject_Root_G4.zip from this link, which I believe is the same shared elsewhere:
https://mega.nz/#!BIxUzbqI!nt2YnGnGQlSiBQ-Ar-c-q7oDMIEsg6xd0Kmek-q0clg
And I get the same problem - stuck on the LG logo when booting.
For anyone who wants to reproduce Approach 2 to maybe find a solution:
1. Start up LGFlashTool2014. You can follow instructions in thread by konsolen (see Approach 1 above). You can use his .kdz file as well. Important: Pull out your USB cable as soon as the green letters COMX (with a number instead of X) appear on the phone. My flashtool actually didn't display the progress percentage, but apparently this at 9%. It doesn't matter if you don't see the percentage though, I've verified with this KDZ image that if you pull the cable at the very moment the green letters appear, nothing is corrupted. The phone will still display 0%. Leave it as it is after you unplugged the cable.
2. Kill your flash tool with the windows task manager. After it closed, you can plug the phone back in and open a windows command line in the folder where your Send_Command.exe is (you can download the package in konsolen's instructions which contains Send_Command.exe as well).
3. Open the console to your phone with
Code:
Send_Command.exe \\.\COMX.
(with your number instead of X)
You will have to do steps 1-3 every time you want to get this console, for example to run all the dd commands below.
4. Calculate the dd parameters and backup your system partition into a .img file. There is an excellent guide by dominik-p for how to determine your individual dd parameters:
http://forum.xda-developers.com/g4/help/how-to-determine-dd-parameters-lg-g4-t3184867
5. Keep a copy of your system.img somewhere safe, you can use it to restore your system if something goes wrong. So don't use this original in the next steps!
6. Copy the .img file to a linux system and mount it. I'm guessing who is trying this knows how to do this. Anything you change in the folder you mounted the image on, will be saved in the image. You can then use this updated image to overwrite your original system partition, again with dd (as described in the thread by dominik-p) using your parameters. So here's the crucial bit: You get root access to your system files via linux. When you know the right things to mess with, you can root your phone with the updated image. Injecting the root as done in step 8 is one way to change the system on the G4 in order to root it.
7. [Optional] If you are new to this, you may want to do a simple test before you continue.
Create a testfile (test.txt) on the mounted system partition. Then copy the .img file back to your phone and try to "dd" it back over your system partition.
Then, check if you see the test file on your system partition -- you may have to reboot the phone after the dd command (and log back in with Send_Command.exe) in order to see the updates.
8. Inject root with the Inject_Root_G4.zip on the mounted folder of the image on your linux system. You can follow instructions (Step 2) here:
http://forum.xda-developers.com/g4/general/lg-g4-100-root-success-directives-root-t3180586
9. Copy the new img file to your phone and "dd" it over your system partition, using your own dd parameters.
10. Reboot the phone (you can also just type LEAVE in the Send_Command.exe console).
Now, it should be rooted - if it worked for you!
If it worked for you, that's great. It didn't for me, it got stuck on the LG logo in the boot process again. So I had to write my original system.img back onto my system partition to get the phone back.
I did get the following errors in Step 8 above, though I did try anyway to use the resulting image. The errors may have something to do with my problem, but it may also be because the inject root is for the G4, not the G4s.
Code:
sudo ./autoroot.sh
cp: cannot create regular file ‘operatingtable/lib64/libsupol.so’: No such file or directory
chmod: cannot access ‘operatingtable/lib64/libsupol.so’: No such file or directory
chcon: cannot access ‘operatingtable/lib64/libsupol.so’: No such file or directory
chmod: cannot access ‘operatingtable/bin/app_process64_original’: No such file or directory
chcon: cannot access ‘operatingtable/bin/app_process64_original’: No such file or directory
chmod: cannot access ‘operatingtable/bin/app_process_init’: No such file or directory
chcon: cannot access ‘operatingtable/bin/app_process_init’: No such file or directory
If anyone finds a solution to this, or has any ideas what could be tried, I would be very interested to hear it. I'm new to rooting phones and don't have much experience beyond what I did in the last days.
Cheers
Jennifer
jen.magnolis said:
4. Calculate the dd parameters and backup your system partition into a .img file. There is an excellent guide by @dominik-p for how to determine your individual dd parameters:
http://forum.xda-developers.com/g4/help/how-to-determine-dd-parameters-lg-g4-t3184867
Click to expand...
Click to collapse
Happy that my guide has helped you
As I said here:
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491/page5
Everyone who is interested to inject root must edit the autoroot.sh from the inject.zip and use the correct files from SuperSU
More information about the files:
https://su.chainfire.eu
Maybe you have to use other files. Not the files from the inject.zip
Download the Update-SuperSU zip from http://download.chainfire.eu/supersu
Copy the files you need to the "su" folder of the extracted inject.zip
For information which files are needed read the "update-binary" file from the SuperSU zip.
(located here META-INF/com/google/android/update-binary)
Good luck everyone :good:
Thanks again for the links! I'll try again soon, when I get time for it, and report the results here
By the way, here's the ls -lR of my system.
Ok, no problem, take your time.
I've got also lot of other work to do...
I just read your system.txt (thanks)
According to these lines:
Code:
lrwxr-xr-x. 1 root 2000 13 Aug 24 02:05 app_process -> app_process32
-rwxr-xr-x. 1 root 2000 13588 Aug 24 02:05 app_process32
It seems that the firmware is 32 bit.
More info about your firmware is in /system/build.prop
So you have to take the right lines from update-binary and copy them and edit the autoroot.sh
Please don't ask me which lines. It's a bit difficult... (you have to understand the logic in update-binary)
Then copy the files from the right folder (arm?) to the "su" folder.
Sorry. I'm out now here for the next time. I have a H815 and happy with it.
I think you will find the solution. :good:
Custom Recoverys
Hi All
Are there any custom recovery's for the G4 beat/G4s
Thanks
Thanks dominik-p for your help. Good luck with your other work, don't worry I won't distract you with asking questions You already helped a lot.
benji5688, you can check for official firmware (.kdz file) on this link, pasting your IMEI instead of YOUR-IMEI in the link below.
http://csmg.lgmobile.com:9002/csmg/b2c/client/auth_model_check2.jsp?esn=YOUR-IMEI
I did not find any for mine there, but I did find it on
http://devtester.ro/projects/lg-firmwares/
Which brought me to this link where I could find mine:
http://pkg02.azure.gdms.lge.com/dn/downloader.dev?fileKey=FW703UV132GQAUP7A0ED99N/H73510c_00.kdz
but you should look for your specific model.
jen.magnolis said:
Hi,
I have been trying to root the LG G4S (H735), also known as "LG G4 Beat".
I tried two things:
Click to expand...
Click to collapse
LOL
I did the exact same thing as you, and really the EXACT, I also contacted dominik-p for the same problem you got with the bs. LOL
Was about to do the same thing you did here too just told that to dominik-p lol.
You post is great, well detailled. Hope someone found something
But got something different. my phone is the LGH731 LG G4 Vigor from Videotron in Canada.
If someone need files or system.img LINK
That's not the exact same thing as the post owner but i'm pretty sure the root method will be. (DON'T use this system.img to inject in you H735) it's from a H731 and they don't have the same partition size.
Ha, that's funny, and you got the same problem of course (frozen logo boot).
We will find a solution. It's just a matter of time. I'm a bit pressed for work in the next days but I'll get back into it around mid week. I think the main problem was, as I suspected and also as dominik-p pointed out, we've been using the wrong inject files. And the G4s is 32 bit so obviously it won't work with 64 bit libs.
First thing I'll try is using the other files from the link dominik-p shared. I'll also read the guide and try to understand which files need to be changed to gain root access in general, i.e. learn the basics of how to root. Then I think/hope I'll be able to fix this. And finally get to move all my stuff onto SD and get my storage back
Meanwhile, if you get any new results, let me know.
Cheers
jen.magnolis said:
Ha, that's funny, and you got the same problem of course (frozen logo boot).
We will find a solution. It's just a matter of time. I'm a bit pressed for work in the next days but I'll get back into it around mid week. I think the main problem was, as I suspected and also as dominik-p pointed out, we've been using the wrong inject files. And the G4s is 32 bit so obviously it won't work with 64 bit libs.
First thing I'll try is using the other files from the link dominik-p shared. I'll also read the guide and try to understand which files need to be changed to gain root access in general, i.e. learn the basics of how to root. Then I think/hope I'll be able to fix this. And finally get to move all my stuff onto SD and get my storage back
Meanwhile, if you get any new results, let me know.
Cheers
Click to expand...
Click to collapse
Yes i'm trying this today (the 32-64 bits thing)
Custom recovery
What does this file do though?
Is it a custom recovery or is it the stock rom?
Thanks Benji
benji5688 said:
What does this file do though?
Is it a custom recovery or is it the stock rom?
Thanks Benji
Click to expand...
Click to collapse
It's the stock ROM. It can be used for recovery, depending what your problem is. If you destroyed your ROM by trying to root, you can recover with this.
If you mess with something in your system partition (where the Android OS is installed), you'd need a copy of your individual system partition (like a "backup") to restore. This highly depends on your phone/version, so you have to do this backup yourself. You can follow the instructions with the dd parameters, linked to from the main thread.
Are there any custom recoverys
Hi
Are there any custom recovery available, I want to get Xposed.
Can anyone make one?
Thanks for all the help
benji5688 said:
Hi
Are there any custom recovery available, I want to get Xposed.
Can anyone make one?
Thanks for all the help
Click to expand...
Click to collapse
I far as I know to get Xposed you need to be rooted... Well there is no root method availaible, well you can try the methods that Jen explained here but I doubt they will work... if yes, you lucky ****
Is the g4s running marshmallow? Is so you would need to use a compatible su install.
Sent from my VS986 using XDA Free mobile app
larsdennert said:
Is the g4s running marshmallow? Is so you would need to use a compatible su install.
Sent from my VS986 using XDA Free mobile app
Click to expand...
Click to collapse
No the problem is really just changing the 64 bits command to make then use the 32 bits ones
I manage everything except this one
Code:
chcon --reference=operatingtable/bin/app_process32 operatingtable/bin/app_process64_original
I agree with xsteacy, this will most likely not work, that's why we opened this discussion
We just have to find the right files to use (instead of the 64 bit ones).
I will get back onto the subject by Wednesday when I have time.
I solved it! My phone is rooted
I asked someone to test my script before I post the results. Hang on there, tomorrow I'll post the solution.
Good times!
jen.magnolis said:
I solved it! My phone is rooted
I asked someone to test my script before I post the results. Hang on there, tomorrow I'll post the solution.
Good times!
Click to expand...
Click to collapse
0.0 OH!?
Ok I'm putting it out there for others to test as well.
Please report if it worked so I can take this into account before updating the main thread instructions.
In the attached .zip file there is a README with instructions.
Note: Thanks goes to @konsolen who shared instructions on how to open the COM port on the H735.
The script in konsolens post is essentially the upater-binary script of the SuperSU package, but with a few modifications.
That may have been necessary on konsolens phone, but it didn't work on mine. For me, using the original script worked.
However, the zip file has to be extracted manually with busybox before the updater-binary script is started. I am not
sure if busybox absolutely needs to be in the /sbin folder, but that's where I saw elsewhere that it belonged, so
I moved it over there in my script. I haven't tested this with busybox being elsewhere.
Thanks goes also to @dominik-p for sharing the link to excellent documentation and for his instructions on how
to make a backup (with dd) of your system, in case anything goes wrong.
UPDATE: I did all commands in root_lgh375.sh manually when I found it already worked, so please report if all is good with the script, but I think it should be, it only does what I did manually.
Congratulations @jen.magnolis
Well done

Categories

Resources