Related
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.
If I want to customize a ROM that I have in update.zip format, do I just manually modify the contects of the update.zip and change the update-script and build.prop files or should I be doing this another way through an IDE or something?
If so, can someone please link me to where I might get some relevent info?
Thanks.
dsixda's kitchen will let you pretty much cook and modify any ROM.
I wouldn't use the root function on there, but if you look at the No Idea Blog link on the first page of that thread it tells you how to add root permissions if your ROM doesn't already have them (it's really easy).
Also, if you're on Windows and don't like the fact that you can't use the kitchen to its full potential, you can download a copy of Ubuntu Linux and VirtualBox (both free) and run Ubuntu as a virtual machine within Windows. Alternatively you can try WUBI as pointed out by kendong2 here
Using the kitchen will ensure that your customised ROM is signed - Amon RA requires signed update.zips, I think there was something called Clockwork Recovery which doesn't need the package to be signed.
TheAshMan said:
dsixda's kitchen will let you pretty much cook and modify any ROM.
I wouldn't use the root function on there, but if you look at the No Idea Blog link on the first page of that thread it tells you how to add root permissions if your ROM doesn't already have them (it's really easy).
Also, if you're on Windows and don't like the fact that you can't use the kitchen to its full potential, you can download a copy of Ubuntu Linux and VirtualBox (both free) and run Ubuntu as a virtual machine within Windows. Alternatively you can try WUBI as pointed out by kendong2 here
Using the kitchen will ensure that your customised ROM is signed - Amon RA requires signed update.zips, I think there was something called Clockwork Recovery which doesn't need the package to be signed.
Click to expand...
Click to collapse
Thanks, I'v already managed to add root myself a few times to various ROMs so i don't think that'll be an issue.
Does the ROM need to be re-signed on each modification? Which is why I wouldnt be able to edit it manually?
Thanks again.
EDIT: I have no problem running linux, infact I have Ubuntu on my laptop and will install Fedora 12 on my desktop now.
alias_neo said:
Thanks, I'v already managed to add root myself a few times to various ROMs so i don't think that'll be an issue.
Does the ROM need to be re-signed on each modification? Which is why I wouldnt be able to edit it manually?
Thanks again.
EDIT: It would seem I need to be running a linux OS to do this properly, is that correct? If so, I better start setting up something on a spare harddrive in my PC or get my laptop out.
Click to expand...
Click to collapse
yes resign after every update. just unpack, modify, repack and resign. not that complicated if you get yourself some handy scripts (write them or use dsixdas kitchen).
kendong2 said:
yes resign after every update. just unpack, modify, repack and resign. not that complicated if you get yourself some handy scripts (write them or use dsixdas kitchen).
Click to expand...
Click to collapse
So for my working folder I extract (for example) lox's clean ROM update.zip?
alias_neo said:
Thanks, I'v already managed to add root myself a few times to various ROMs so i don't think that'll be an issue.
Does the ROM need to be re-signed on each modification? Which is why I wouldnt be able to edit it manually?
Thanks again.
EDIT: It would seem I need to be running a linux OS to do this properly, is that correct? If so, I better start setting up something on a spare harddrive in my PC or get my laptop out.
Click to expand...
Click to collapse
As far as I know yeah (unless you're using that other recovery image I mentioned). It's pretty easy with the kitchen - press 9 and it cooks the ROM. Takes about 2-3 minutes for each bake - its flashing the ROM that takes ages.
You could sign manually, I'm sure I found a tutorial on how to do that when I was modifying some apps.
It works fine on OSX too. If you read the first post, he does say some things won't work on Windows. Like I said, you could use VirtualBox or WUBU which will save you the hassle of extra hardrives, partitions, dual-booting and all that.
Q
Ok, got the kitchen open under linux now, first question is this, the ROM i'm using doesn't have a system.img, it has a folder "system" so it naturally won't let me continue in the kitchen without it, how do I solve this problem?
Thanks.
To customise an existing ROM, extracts all its contents.
In the kitchen make a folder starting with "WORKING_" the underscore can be followed by any name of your choice e.g. WORKING_ALIASNEOROM
Inside that folder paste the boot.img, system, META-INF and data (if its there) folders from the ROM you extracted.
Inside the META-INF folder delete the 3 files - just leave the com folder.
After that you should be good to go with the ROM.
TheAshMan said:
To customise an existing ROM, extracts all its contents.
In the kitchen make a folder starting with "WORKING_" the underscore can be followed by any name of your choice e.g. WORKING_ALIASNEOROM
Inside that folder paste the boot.img, system, META-INF and data (if its there) folders from the ROM you extracted.
Inside the META-INF folder delete the 3 files - just leave the com folder.
After that you should be good to go with the ROM.
Click to expand...
Click to collapse
Thanks a lot, really appreciate the help.
One more question, hopefully the final one, when i remove apps or add them to the relevent folder, are permissions and linking taken care of automatically where necessary?
alias_neo said:
Thanks a lot, really appreciate the help.
One more question, hopefully the final one, when i remove apps or add them to the relevent folder, are permissions and linking taken care of automatically where necessary?
Click to expand...
Click to collapse
No problem, I was in your shoes a couple of weeks ago! Yeah, you just copy the apks - worked for me so far.
Most ROMs come with a data/app folder, but incase yours doesn't just create it next to the system, boot.img etc and then in the update-script add:
Code:
delete DATA:app
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
before the format CACHE command.
TheAshMan said:
No problem, I was in your shoes a couple of weeks ago! Yeah, you just copy the apks - worked for me so far.
Most ROMs come with a data/app folder, but incase yours doesn't just create it next to the system, boot.img etc and then in the update-script add:
Code:
delete DATA:app
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
before the format CACHE command.
Click to expand...
Click to collapse
and make that
Code:
set_perm 1000 1000 0771 0771 DATA:app
for eclair roms...
TheAshMan said:
No problem, I was in your shoes a couple of weeks ago! Yeah, you just copy the apks - worked for me so far.
Most ROMs come with a data/app folder, but incase yours doesn't just create it next to the system, boot.img etc and then in the update-script add:
Code:
delete DATA:app
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
before the format CACHE command.
Click to expand...
Click to collapse
Where can I find the syntax for this file? I like to understand the commands so I can use them properly, i get that set_perm is setting permissions and 0771 are the permissions being set, but what are the "1000 1000"?
Google wasn't my friend this time and I couldn't find a syntax.
Have a look in here, I've not got enough Linux experience to tell you how those permissions work. I update that file by comparing ones from other ROMs and slowly got the hang of it.
Cool
TheAshMan said:
Have a look in here, I've not got enough Linux experience to tell you how those permissions work. I update that file by comparing ones from other ROMs and slowly got the hang of it.
Click to expand...
Click to collapse
Exactly what I was looking for, thanks.
Just failed two flashes because of:
1) because i conned the kitchen into setting up the working folder (by putting a fake system.img) it didn't delete the symlinks so i had to do it manualy (after trying to flash then figuring out why it failed) and
2) it couldnt chmod "su" because it didn't exist, strange since i was working based on an existing ROM and didn't delete the "su" binary.
Question: How and where do I change the build name that shows up on the device to my own name?
EDIT: 3rd flash was successful but on boot it hangs at the HERO screen, logcat just says "waiting for device". Ideas?
TheAshMan said:
No problem, I was in your shoes a couple of weeks ago! Yeah, you just copy the apks - worked for me so far.
Most ROMs come with a data/app folder, but incase yours doesn't just create it next to the system, boot.img etc and then in the update-script add:
Code:
delete DATA:app
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
before the format CACHE command.
Click to expand...
Click to collapse
This is useful info, thanks. I might add this as an option to the kitchen in the future.
alias_neo said:
Exactly what I was looking for, thanks.
Just failed two flashes because of:
1) because i conned the kitchen into setting up the working folder (by putting a fake system.img) it didn't delete the symlinks so i had to do it manualy (after trying to flash then figuring out why it failed) and
2) it couldnt chmod "su" because it didn't exist, strange since i was working based on an existing ROM and didn't delete the "su" binary.
Click to expand...
Click to collapse
Someone's custom ROM may have it someplace else. My kitchen was mainly designed for new cooks making their own ROMs from the stock ROMs.
Question: How and where do I change the build name that shows up on the device to my own name?
Click to expand...
Click to collapse
I think it's in the build.prop. Just compare the field values with what you see on your phone right now for the build name.
dsixda said:
Someone's custom ROM may have it someplace else. My kitchen was mainly designed for new cooks making their own ROMs from the stock ROMs.
Click to expand...
Click to collapse
That's what I don't get, the update-script isn't edited by the kitchen right? But the chmod command in the update-script was from the same ROM, so surely it's "su" binary should be in the same place the update-script looks for it, or am i missing something?
I think it's in the build.prop. Just compare the field values with what you see on your phone right now for the build name.
Click to expand...
Click to collapse
Thanks, I'v given it a go, will see what happens if/when i get a successful flash.
As for your adding that info from Ash to your kitch, I think it would be useful because I forgot the last line (setting permissions) and it just caused my ROM to hang on boot, reflashing now and hoping adding it was the fix. Will update this post once complete.
UPDATE: Still hangs on boot even with that line added. Where do I go from here in debugging since I can't get logcat?
alias_neo said:
Exactly what I was looking for, thanks.
Just failed two flashes because of:
1) because i conned the kitchen into setting up the working folder (by putting a fake system.img) it didn't delete the symlinks so i had to do it manualy (after trying to flash then figuring out why it failed) and
2) it couldnt chmod "su" because it didn't exist, strange since i was working based on an existing ROM and didn't delete the "su" binary.
Question: How and where do I change the build name that shows up on the device to my own name?
EDIT: 3rd flash was successful but on boot it hangs at the HERO screen, logcat just says "waiting for device". Ideas?
Click to expand...
Click to collapse
If you used my instructions about the WORKING folder earlier, then you don't need to use option #1 in the kitchen to setup working folder - that's only if you're working with stock images. The result of that command is a WORKING folder - which you already have by extracting the files and making that folder manually.
dsixda said:
This is useful info, thanks. I might add this as an option to the kitchen in the future.
Click to expand...
Click to collapse
Happy to help! You know you've done a great job with that kitchen, and got me started with ROMs,
dsixda said:
Someone's custom ROM may have it someplace else. My kitchen was mainly designed for new cooks making their own ROMs from the stock ROMs.
Click to expand...
Click to collapse
Yup, I built my 1.5 ROM using a stock ROM, but a 2.1 based on BeHero.
kendong2 said:
and make that
Code:
set_perm 1000 1000 0771 0771 DATA:app
for eclair roms...
Click to expand...
Click to collapse
sorry i was misled about that. it is
Code:
set_perm 1000 1000 0771 DATA:app
for eclair aswell. i am confused about this myself somewhat, have you checked the android documentation?
kendong2 said:
sorry i was misled about that. it is
Code:
set_perm 1000 1000 0771 DATA:app
for eclair aswell. i am confused about this myself somewhat, have you checked the android documentation?
Click to expand...
Click to collapse
You only need the permission twice if its for the recursive set, because the first is the directory and the second is it's contents.... or so I believe.
Hey guys, I've been reading for a while now, finally decided to sign up.
I'm making some modifications to the Galaxy Tab, just playing around and seeing what all is possible. Before I go start deleting potentially important system files, I wanted to get myself a little 'brick insurance'. I'm looking to get a copy of the stock firmware for the US Verizon Wireless version of the Tab (SCH-I800). It is currently running DJ11.
I don't think it is available from either Samsung or Verizon currently, although Samsung HAS provided all of the source code. If I wanted to make a backup of the firmware, something that I could load from the SDCard (ideally, just give it one of those update.zip files) how would I go about doing that?
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
I want to be able to quickly revert back to like-new set up, so I would prefer to not have to use one of the modified European/International versions if possible. Is there any other trick to getting an unmodified firmware to revert to? Any suggestions?
Thank You
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
DavidThompson256 said:
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
Click to expand...
Click to collapse
Not even close i'm afraid!
Samsung are only required to release the Linux kernel source. The actual OS is not licensed under a "copy left" license, so Samsung are under no obligation to release their customized Android code.
So, you could create your own AOSP build, but this would be absolute stock Froyo - no Samsung launcher, or any of their custom apps.
Regards,
Dave
Yaotl said:
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
Click to expand...
Click to collapse
You can use odin or redbend_ua to flash firmwares, you don't necessarily need clockwork - although it would be nice!
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
ninja4hire said:
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
Click to expand...
Click to collapse
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
infamousjax said:
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
Click to expand...
Click to collapse
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
ninja4hire said:
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
Click to expand...
Click to collapse
Can you boot up regularly?
yeah, it's just that I can't open programs or the settings menu.
edit: I have been trying to do an update.zip, but I keep getting "E: signature verification failed". I have tried to different signers already...
This one
http://www.robmcghee.com/android/creating-an-android-update-zip-package/
and this one
http://www.londatiga.net/it/how-to-create-android-update-zip-package/
Your not going to able to sign it without Samsung's signatures... and good luck finding those
yeah I pretty much gave up. I called last night and got the verizon insurance. So now I'm just gonna wait a few days then tell them I dropped it and pay $80 for a new one.
just tell them it started bootlooping for no reason... they should replace it for free if its within 30 days
So it sounds as though I'm not really on the right track here, perhaps I don't need to recompile this thing myself. From some of the replies, I've gathered that there IS at least some way to create a backup of the firmware, in case I screw it up.
Can anyone point me to specific steps on how to do a backup for the Tab? I've seen several guides for other phones before, but I believe that each device is slightly different, and may take different steps. Any suggestions?
Thanks again.
For your stock recovery
Code:
cat /dev/block/bml8 > /sdcard/recovery.bin
For your kernel
Code:
cat /dev/block/bml7 > /sdcard/zImage
Thanks a lot, that info was really helpful!
So, unrelated now, but just kind of curious... is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
I have about 60 different files in that directory, and was just curious to know what each of them was for.
Thanks again for all the info.
DavidThompson256 said:
is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
Click to expand...
Click to collapse
What they represent is different devices, not different sections of filesystems. At best (without RAID or LVM) each device holds one filesystem. In unix, filesystems can be mounted at various points into the root filesystem to appear as a single namespace, but they will still be separate filesystems.
Under the block dir you will see anything that is a block device, anything that can be written to randomly, as opposed to a serial type of device. So, all the random access hardware on your device (SDCARD, NAND...) will be represented there except for your RAM. Each physical device will likely have partitions on them so, if a device is named xxx, xxx01 will likely mean partition one on device xxx. Sometimes the same device will appear with several names, one may be buffered access, the other may be raw.
Your internal NAND is likely on the same device, just different partitions of that device. Some of these partitions may not hold filesystems, they may hold other blobs such as a boot loader, or the kernel. To see which ones hold filesystems, you can type df in a terminal and you will likely see which devices are mounted where in the filesystem namespace.
As for the rest of the devices and partitions, they are very hardware device specific. And I don't own a Galaxy tab, so I can't help with that, sorry. But, I hope I didn't give you info you already knew and I hope it might have been at least somewhat helpful...
Not sure if I have anything worth while, but ASUS left a "Tools" folder on my desktop...attached a screenshot of what it included.
phxtravis said:
Not sure if I have anything worth while, but ASUS left a "Tools" folder on my desktop...attached a screenshot of what it included.
Click to expand...
Click to collapse
Can you please zip that and upload them?
Yeah please zip it up and upload them so we can see what it's doing.
Yes, ZIP them please - the auditmode files are for sysprep audit mode, securebootdebug - are probably from microsoft HCK and add debug key to key storage (so you can run testsigned apps), FWVar - probably allows editing UEFI firmware variables (I've already made the same tool myself), everything is interesting of cause.
Here you go
Thank you for the tools.
SetAuditMode/ClearAuditMode - clears the sysprep audit mode (useless)
setup.cmd, SecureBootDebug* - installs "secure boot debug" policy. I.e. allows running of testsigned (or unsigned) apps. More info: http://msdn.microsoft.com/en-us/library/windows/hardware/hh998740.aspx
Securebootdebug needs the signed policy file. It is probably left on your device too, as "tools" directory is not erased. To obtain it - run CMD or powershell as administrator, then type there: "mountvol S: /s" without quotes. This would assign S: to your BCD partition. There should be SecureBootDebugPolicy.p7b file. Please share it too
To dismount disk S: after copying that file - type "mountvol s: /d"
reset.cmd - this file would delete the tools directory and all other files reverting things back.
hsc.vbs, pdq.vbs - tiny support scripts for reset.cmd
FWVar.exe - writes firmware variables. Not UEFI vars that are documented, but it plays with some other asus-specific vars like sensors calibration and platform IDs. Would be interesting to decompile it
mamaich said:
Thank you for the tools.
SetAuditMode/ClearAuditMode - clears the sysprep audit mode (useless)
setup.cmd, SecureBootDebug* - installs "secure boot debug" policy. I.e. allows running of testsigned (or unsigned) apps. More info: http://msdn.microsoft.com/en-us/library/windows/hardware/hh998740.aspx
Securebootdebug needs the signed policy file. It is probably left on your device too, as "tools" directory is not erased. To obtain it - run CMD or powershell as administrator, then type there: "mountvol S: /s" without quotes. This would assign S: to your BCD partition. There should be SecureBootDebugPolicy.p7b file. Please share it too
To dismount disk S: after copying that file - type "mountvol s: /d"
reset.cmd - this file would delete the tools directory and all other files reverting things back.
hsc.vbs, pdq.vbs - tiny support scripts for reset.cmd
FWVar.exe - writes firmware variables. Not UEFI vars that are documented, but it plays with some other asus-specific vars like sensors calibration and platform IDs. Would be interesting to decompile it
Click to expand...
Click to collapse
I was unsuccessful at finding the file, I wiped the tablet yesterday as it was running like crap(freezing, and wouldn't download updates), not sure if that wiped what you are looking for.
OK, I see what that setup.cmd file is doing. It generates an unsigned SecureBootDebug.p7b file authorizing full debug unlocking for the particular serial number of your device - the -u switch to createsecurebootpolicy.exe locks it to your device. It then sends that file to a server aptly named "\\secureboot" on ASUS's internal network and waits for a reply. Sometime later, a signed version of that file appears on that server's share, and the Vivo RT copies it to the EFI system partition to use with SecureBootDebug.efi.
After the service center does what it needs to do, they run reset.cmd, which deletes the Secure Boot policy from EFI NVRAM at next reboot and deletes SecureBootDebugPolicy.p7b from the EFI system partition.
phxtravis said:
I was unsuccessful at finding the file, I wiped the tablet yesterday as it was running like crap(freezing, and wouldn't download updates), not sure if that wiped what you are looking for.
Click to expand...
Click to collapse
If you had not done that, we could have made an image of your EFI system partition and recovered the deleted SecureBootDebugPolicy.p7b file, which would have permanently jailbroken your Vivo RT forever. Sadly, it was locked to your device. What method did you use to wipe it? Did you ask it to repartition your system?
Myriachan said:
OK, I see what that setup.cmd file is doing. It generates an unsigned SecureBootDebug.p7b file authorizing full debug unlocking for the particular serial number of your device - the -u switch to createsecurebootpolicy.exe locks it to your device. It then sends that file to a server aptly named "\\secureboot" on ASUS's internal network and waits for a reply. Sometime later, a signed version of that file appears on that server's share, and the Vivo RT copies it to the EFI system partition to use with SecureBootDebug.efi.
After the service center does what it needs to do, they run reset.cmd, which deletes the Secure Boot policy from EFI NVRAM at next reboot and deletes SecureBootDebugPolicy.p7b from the EFI system partition.
If you had not done that, we could have made an image of your EFI system partition and recovered the deleted SecureBootDebugPolicy.p7b file, which would have permanently jailbroken your Vivo RT forever. Sadly, it was locked to your device. What method did you use to wipe it? Did you ask it to repartition your system?
Click to expand...
Click to collapse
I did the "remove everything and reinstall windows" option in settings.
phxtravis said:
I did the "remove everything and reinstall windows" option in settings.
Click to expand...
Click to collapse
It *might* still be there then if we take an image of your EFI System Partition and search it manually with a hex editor. There are definitely no guarantees, though. Also, this would likely reveal your device's serial number to whoever you give the image to. It probably would *not* have any other information, though, like personal documents or your Windows RT CD key--those're on the main partition.
If this file were found, I think it would permanently jailbreak your device - Windows RT would let you run whatever unsigned code.
The SecureBootDebug.efi tool needed to use this .p7b file is also part of the publicly-available final 8.1 Windows Driver Kit. The one in your .zip file looks like the 8.0 version.
Myriachan said:
It *might* still be there then if we take an image of your EFI System Partition and search it manually with a hex editor. There are definitely no guarantees, though. Also, this would likely reveal your device's serial number to whoever you give the image to. It probably would *not* have any other information, though, like personal documents or your Windows RT CD key--those're on the main partition.
If this file were found, I think it would permanently jailbreak your device - Windows RT would let you run whatever unsigned code.
The SecureBootDebug.efi tool needed to use this .p7b file is also part of the publicly-available final 8.1 Windows Driver Kit. The one in your .zip file looks like the 8.0 version.
Click to expand...
Click to collapse
Not sure if I am sold on jailbreaking, what's the advantages other than being able to run "hacked" exe's? Aslo, what would you need me to do?
The EXEs are not "hacked" in any proper sense of the word, just recompiled. Sometimes some changes are needed, but they're usually basic. It lets you run (normal) Windows programs. .NET programs run as-is, native ones need to be ported (usually a pretty simple recompile, if they built under Visual Studio in the first place, but we need the source code), and it unlocks full Powershell scripting power. Programs written in other languages, like Python and Java, can be run using ported runtimes. In fact, it's even possible to run some x86 programs (unmodified Win32 native EXEs) via a dynamic recompilation layer written by @mamaich here on XDA; I can play some old games and run some nice old programs that I like that way.
phxtravis said:
Not sure if I am sold on jailbreaking, what's the advantages other than being able to run "hacked" exe's? Aslo, what would you need me to do?
Click to expand...
Click to collapse
Hacked EXEs?
No hacking. We legally take the source code for a program and compile it for win32 in THUMB_2 instead of win32 on x86. You can then run these desktop applications on your lovely ARM tablet as you could on a normal windows PC. That is an absolutely huge advantage which should have been a default option.
Quake alone makes it worth it.
I didn't mean to use "hacked" in a negative context, merely meant it as a general term of modifying original EXEs to run on ARM, I haven't been following the RT jailbreaking at all.
Can't modify an existing EXE. Totally incompatible (unless its a .NET application in which case no mods needed). Need to rebuild the EXE and any supporting libraries from source.
phxtravis said:
Here you go:
https://docs.google.com/file/d/0BzebTu1H3-aIbXlTV09BMjZsLVk/edit?usp=sharing
Click to expand...
Click to collapse
This requires approval. Does anyone still have a copy?
jordanmills said:
This requires approval. Does anyone still have a copy?
Click to expand...
Click to collapse
It doesn't require approval
Curiously, there is a Secure Boot debug policy creator ,signed by Microsoft for ARM but sadly not generating signed policies...
It may be used for jailbreak as the other tools are unsigned(most of them) if there is a bug allowing to load a unsigned policy somewhere(there should be one)
Will try downloading the HCK to see if there is something useful there
black_blob said:
It doesn't require approval
Click to expand...
Click to collapse
Hmm, it doesn't now. But there doesn't seem to be any way to download the whole thing. It only shows individual files.
jordanmills said:
Hmm, it doesn't now. But there doesn't seem to be any way to download the whole thing. It only shows individual files.
Click to expand...
Click to collapse
There is the download button at the top
My device was fine before Rooting importantly the Bluetooth stack was was also fine. However, after rooting all BT Pairings are lost across reboots etc. Just turning BT off then on again causes the issue making it necessary to delete and re-pair every time the device starts. over the last week i've ran various tests, and concluded the issue lies with either the hardware or the stock image i got from Sammobile.com. Being a noob, during my experimentation i have had to flashback to the stock image on several occasions. Only discovering the Bluetooth issue when putting my work to good use and using the device.
Yesterday i tested the theory. Flashed it to stock, booted to OS and skipped all the config disabled WI-FI and DATA so it couldn't pull updates. Tested Bluetooth and the issue is present. The Bluetooth did work correctly before i started rooting it. This is unlikely a hardware issue so can only assume its an issue in the build i have from Sammobile. If any of you have access to a stock pre-installed rom that works that they could give me access to, so i can do some testing or indeed any advice it would be very much appreciated.
Device = Samsung Galaxy Tab S4 (SM-T835 on EE)
PDA = T835XXU2ARJ3
CSC = T835OXM2ARJ3
Many thanks
Colin
This is known issue once rooted, however it has already been fixed. There is a module that you need to load via Magisk. Search for: libsecure_storage companion for rooted Samsung devices. Load that up and you'll be good to go.
cbb77 said:
This is known issue once rooted, however it has already been fixed. There is a module that you need to load via Magisk. Search for: libsecure_storage companion for rooted Samsung devices. Load that up and you'll be good to go.
Click to expand...
Click to collapse
thanks for the info, i saw a few threads a few days ago about secure storage and did it manually which didn't help with the issue. similarly neither does the module for Majisk . a case of keep looking i guess. any other suggestions will be very much appreciated
Hmm, I would try uninstalling and reinstalling again via Magisk to confirm. I have rebooted multiple times and the bluetooth pairings stick for me. I do have T830 vs. the T835 that you have but I wouldn't think that it should matter. Worth another shot anyway.
cbb77 said:
Hmm, I would try uninstalling and reinstalling again via Magisk to confirm. I have rebooted multiple times and the bluetooth pairings stick for me. I do have T830 vs. the T835 that you have but I wouldn't think that it should matter. Worth another shot anyway.
Click to expand...
Click to collapse
Cheers will give it a go - at this point i have nothing to lose, just taken a fresh backup so nothing ventured nothing gained
its stuck no boot while removing secure_storrage module from majisk
Oddly having tried the suggestion above of removing the majisk module the device no longer boots it gets stuck on the Samsung logo. For some reason the vendor partition is no longer able to mount.. Completed a restore eventually to get it to boot. Disabling the module yields the same result. no vendor partition and no boot. Going back to an earlier backup prior to the module being installed
The plot thickens
Today i'm still trying to find a fix for disappearing Bluetooth devices. Using the Magisc module cases my Tab to stall during boot on the Samsung logo similarly trying to replace the /vendor/lib and /vendor/lib64 binaries manually also causes the system to freeze on the Samsung logo. looking at the binaries and some path file references there in. It would appear as though my tablet is missing some key files or folder so far the following are missing
/data/system/secure_storage/ls_data.db
/dev/.ashem.secure_storage_ashem
/dev/.secure_storage/sd_socket.ro
any of you have any thoughts
c6pea said:
Today i'm still trying to find a fix for disappearing Bluetooth devices. Using the Magisc module cases my Tab to stall during boot on the Samsung logo similarly trying to replace the /vendor/lib and /vendor/lib64 binaries manually also causes the system to freeze on the Samsung logo. looking at the binaries and some path file references there in. It would appear as though my tablet is missing some key files or folder so far the following are missing
/data/system/secure_storage/ls_data.db
/dev/.ashem.secure_storage_ashem
/dev/.secure_storage/sd_socket.ro
any of you have any thoughts
Click to expand...
Click to collapse
You actually only need to replace the libsecure_storage.so libs and set the correct permissions.
Add the following to the build.prop:
ro.securestorage.support=false
Boot failure when LIbs replaced
ashyx said:
You actually only need to replace the libsecure_storage.so libs and set the correct permissions.
Add the following to the build.prop:
ro.securestorage.support=false
Click to expand...
Click to collapse
No matter how i do this, the device failes to boot and gets stuck on the samsung logo.
Install the majsik module through majisk reoot when prompted = device brick
making all the changes manually including the changes to the build.prop in the /vendor partition = device brick on reboot.
Tried Using instructions and librarys from the following post
https://forum.xda-developers.com/sa.../guide-fix-bluetooth-losing-pairings-t3798262
Although, the above post says to replaces the libs in the system folder which serves no purpose but replacing them in the vendor partition causes the device to brick at next boot.
Thanks far the suggestions, Still looking
c6pea said:
No matter how i do this, the device failes to boot and gets stuck on the samsung logo.
Install the majsik module through majisk reoot when prompted = device brick
making all the changes manually including the changes to the build.prop in the /vendor partition = device brick on reboot.
Tried Using instructions and librarys from the following post
https://forum.xda-developers.com/sa.../guide-fix-bluetooth-losing-pairings-t3798262
Although, the above post says to replaces the libs in the system folder which serves no purpose but replacing them in the vendor partition causes the device to brick at next boot.
Thanks far the suggestions, Still looking
Click to expand...
Click to collapse
Is this happening with only the storage libs or does it happen if you make any other changes to vendor?
ashyx said:
Is this happening with only the storage libs or does it happen if you make any other changes to vendor?
Click to expand...
Click to collapse
Thanks for the assist
It occurs only when the Libs are changed.
Originally using the majsic module to install the libs it couldn't overwrite the files as they are in use. modifying the build.prop seemed to resolve that but as soon as those libs are change either manually through terminal or via the installer i end up with a soft brick LOL
its Bugging me!!!
Interestingly
Once the device hangs.
Simply restoring the vendor partition doesn't fix the boot issue.
In order to get the device to boot I have to restore /data (you don't need to restore /vendor just /data)
oddly restoring the /data partition restores the 2 library files in /vendor to their respective originals
Majisk zip extraction issue
so I have resolved the Bluetooth issue, Rather having majisk install the module i just downloaded it and extracted the contents and discovered that upon zip extraction the contents of each file were appended to themselves. see screenshot "confused.jpg" of the readme.md - so in relation to the library files, the files being installed were double in size hence corrupt.
ie /vendor/lib/secure_storage.so should =308kb the file being insatalled in my /vendor/lib partition was 616kb the 64 bit library was also double the size it should have been.
infarct all the files within the Zip had the same issue.
so i extracted the Zip contents on my pc and transferred the library files via usb. made the relevant changes to build.prop and stopped the secure_storage deamon. Machine now boots and Bluetooth pairings are retained across reboots.
Small Wins
Any one have a clue why the files would double up on content??????
built in zip extractor
the issue i have is with the stock zip extraction tool.
extracting the zip file content on the tablet with winzip. the files are as they should be
c6pea said:
the issue i have is with the stock zip extraction tool.
extracting the zip file content on the tablet with winzip. the files are as they should be
Click to expand...
Click to collapse
7zip is the extraction utility you want. Winzip is pants.
ashyx said:
7zip is the extraction utility you want. Winzip is pants.
Click to expand...
Click to collapse
Use winrar on the PC used it for a 15 year haha
only installed winzip to test another extraction tool on the tablet, low and behold the extracted content of the file is as it should be. Unlike the tablets stock zip extractor utility
c6pea said:
Use winrar on the PC used it for a 15 year haha
only installed winzip to test another extraction tool on the tablet, low and behold the extracted content of the file is as it should be. Unlike the tablets stock zip extractor utility
Click to expand...
Click to collapse
Same for winrar, closed source bloated rubbish.
7zip supports practically every format and totally ad free.