Related
Hi All,
Here is my second contribution to the Android community, android2sd!
I tried to make the installation a bit more straight forward and the readme very verbose.
There is NO going into recovery and wiping of the Android to install this construct. (Of course you can if you want to have a clean slate to build from but it is by your choice only!)
Remove .zip from filename, then unrar (sorry to zip users, zip was too big) the package and copy the android2sd.sh install script to the Android say /data/local and make executable with something like chmod 0750 and copy the android2sd.img install image to the sdcard. (Detailed instructions are in the readme file.) Once the install is complete, you can delete both install files.
Execute the script {where ever you installed it}ie:
/data/local/android2sd.sh and follow the instructions.
Included are several of my scripts (updated from the ones in data2sd) and the rules still apply, adjust or remove as you see fit. The readme explains them all.
I have noticed an improvement in speed based on the install, but you can judge for yourself and tweak as you see fit!
The construct uses Overlay Profiles to overlay the Android system and thus any changes to the Android once loaded, are actually done to the overlay profile thus you have like a safe mode which is the untouched Android under the overlay.
Hope you find it useful!
Darkstrumn
Darkstrumn said:
Hi All,
Here is my second contribution to the Android community, android2sd!
I tried to make the installation a bit more straight forward and the readme very verbose.
There is NO going into recovery and wiping of the Android to install this construct. (Of course you can if you want to have a clean slate to build from but it is by your choice only!)
Remove .zip from filename, then unrar (sorry to zip users, zip was too big) the package and copy the android2sd.sh install script to the Android say /data/local and make executable with something like chmod 0750 and copy the android2sd.img install image to the sdcard. (Detailed instructions are in the readme file.) Once the install is complete, you can delete both install files.
Execute the script {where ever you installed it}ie:
/data/local/android2sd.sh and follow the instructions.
Included are several of my scripts (updated from the ones in data2sd) and the rules still apply, adjust or remove as you see fit. The readme explains them all.
I have noticed an improvement in speed based on the install, but you can judge for yourself and tweak as you see fit!
The construct uses Overlay Profiles to overlay the Android system and thus any changes to the Android once loaded, are actually done to the overlay profile thus you have like a safe mode which is the untouched Android under the overlay.
Hope you find it useful!
Darkstrumn
Click to expand...
Click to collapse
Damn man. Good work.
sounds interesting, what is this all about?
brilliant?!? I think.
So basically, this is a non-destructive method that enables us to run new roms on the G1 without flashing? Am I reading this right? If so... wow.
edit: or, erm... maybe not... i think i've been up too long. Gonna have to watch this thread to get a better grasp on this. interesting nonetheless.
Rename To RAR
Darkstrumn said:
Remove .zip from filename, then unrar (sorry to zip users, zip was too big) the package and copy the android2sd.sh install script to the Android say /data/local and make executable with something like chmod 0750 and copy the android2sd.img install image to the sdcard. (Detailed instructions are in the readme file.) Once the install is complete, you can delete both install files.
Click to expand...
Click to collapse
very interesting .. at first i failed to see this part as i'm sure many pay skip over the whole "rename to rar" thing - LOL - so this loads profiles from the SD to the phone
for anyone having trouble with the whole "rename" process try this:
http://files.lucidrem.us/jf/android2sd.rar
as i know windows with hidden file extensions does not allow a rename easily
So what exactly does this do? I see install instructions, but no description.
Overlay Profiles...
tr.slate said:
So what exactly does this do? I see install instructions, but no description.
Click to expand...
Click to collapse
Well,
I've worked up the natural progression to this XXX2SD business, and have made an Android2SD construct which can expand the Android similarly to the the previous constructs, but puts /system, /data and /cache on sd.
So let me explain the overlay thing:
An overlay profile is a snapshot of the Android file system, namely /system, /data, and /cache.
The initial profile is called 'android2sd' and is a snapshot of your android at the time of install, plus the file system structure as explained in the readme adding the mnt/ dir structure and additional scripts in bin/ (which you can remove or adjust as you need).
Typically I reckon folks would only have the one profile and under it your original Android. But you can create additional profiles and set them up however you like. The overlay is overlayed on top of the Android file system with any changes or edits to the system affecting the profile and not the Android under.
The effective change is that the /system /data/, cache are moved to the sdcard thus expanding them to however large your sdcp2 is; on a class 6 card also improving access time.
A second benefit is that the underlying Android is safe from alteration and can be booted into like a 'safe mode'. (It can also serve as the base for new profiles, or you can make new profiles from active overlays. These snapshots can serve as a form of backup, but that is a fringe benefit.
It cannot protect the Android from update.zip installs exactly, as those will modify the Android directly, but say you try a theme and it gafs your 'droid...you can reapply the firmware update to clean out the theme, then copy the desired profile back to the Android and restore the Android to the state of the profile. (I would recommend having a 'base' profile of the Android but not using that as an active profile which will thus serve as a backup) Note: To restore the Android as described above, you cannot restore using a profile with 250+ apps in /data as the Android doesn't have the space for it!
Originally I used unionfs for the overlays but it was too slow.
Hope that explains things here; the readme has far more detail.
I've gotta go, but if I see that I've been as clear as mud, I'll try to explain better when I have more time.
Hmm just out of curiosity: What are you using now? Bind mounts?
I got a little bit lost in setup, I am not sure if I had problems because I was using Cyanogens latest or something else but either way Im going back to JF to try this.
I installed it using the "-COMMIT" addition
But when I made it to installing/linking apps things wouldnt link
Maybe I will let a few other people try it first.
More info...
[email protected] said:
Hmm just out of curiosity: What are you using now? Bind mounts?
Click to expand...
Click to collapse
Yes. Originally it was to have a multi profile layered system using unionfs: union0 the ro base snapshot and union1 the rw profile containing the copy-on-write data. But as the tests went on, the unionfs was too slow to use for /data; Android is unforgiving of unresponsiveness and was ANR'ing the apps that didn't respond fast enough.
The faster bind mount means that union1 is now not used and union0 is rw.
The reason I wanted the union0,union1 path was that the union0 could serve as base and various profiles could be layered over any part of the file system granting "Lego" like flexibility in how the user could adjust their a2sdLoader.sh script (the android2sd loader which controls the overlay process).
You could have a pristine base and several "change" profiles that you layered to your liking and could change any sub layer to different effect.
While you still can under this paradigm, it is not as compact.
But the unionfs option is not completely done away with. It can still be used for the above layering but shouldn't be used for that apps and package system.
An example of the layering I'm on about:
The Android 0-layer which the base layer is a snapshot of.
The base layer is pristine (fully configured settings, but minimal apps loaded, maybe a particular base launcher layout and wallpaper).
A change profile containing my apps and package system
A change profile containing a version of etc with reconfigured bluetooth settings.
A change profile with a theme (manually installed, or snapshot to profile and restored to pristine)
Now I could take these 4 profiles and arrange several different setups:
'base' with all apps loaded, themed with custom bluetooth
'base' with all apps loaded, themed with normal bluetooth
'base' with all apps loaded with custom bluetooth
'base' with all apps loaded with normal bluetooth
'base' with all apps loaded
'base' themed with with custom bluetooth
'base' themed with normal bluetooth
'base' with custom bluetooth
'base' with normal bluetooth
...
Those would be set to serve as the ro union0 and the rw union1 which will hold the copy-on-write changes to the overlay (which preserves the sub layers)
You could have several more theme profiles and have a script that randomly chooses one at boot...
You could simply use the overlay to protect a favored configuration. Should anything untoward happen such as accidentally damaging the packages.xml file while experimenting with the system, you could simply delete the change profile, make a new blank change profile and the damaged files are undone.
The things one can do with the overlay concept are limited only by your imagination and need (and if they slow down app processing too much causing ANR's)
It vary well could if done correctly allow one to have multiple roms as profiles and switch them based on the selected profile, but I have yet to experiment on that...I reckon that is my next move! (Note that this path would have a high space cost as the roms are about 40MB zipped!)
brandenk said:
I got a little bit lost in setup, I am not sure if I had problems because I was using Cyanogens latest or something else but either way Im going back to JF to try this.
I installed it using the "-COMMIT" addition
But when I made it to installing/linking apps things wouldnt link
Maybe I will let a few other people try it first.
Click to expand...
Click to collapse
Taken from [Rom] CyanogenMod:http://forum.xda-developers.com/showthread.php?t=518851
"DO NOT RUN ANY OTHER APPS2SD APPLICATIONS ON THIS BUILD. YOU WILL BREAK YOUR SYSTEM. THEY ARE NOT NECESSARY BECAUSE THIS ROM WILL DO A2SD AUTOMATICALLY AND BETTER!"
The android2sd construct pretty much falls into the A2SD category and thus is likely the reason you had issues with the install.
My Android is based on JF 1.51... and thus your mileage will vary based on the rom you are using. I reckon with a rom derived from theh JF roms, the install may work as intended.
As I go into the next construct build process, I will see if I can't make it multi-rom compatible (to support multi-rom profiles) I'm sure it will take some time to do as I would have to use my actual Android to test with, but no worries!
Hope that helps a little. Sorry it's not better news though.
An excellent "misuse" of this concept would be to run ion (picking it for its speed and almost stock nature) with a hero overlay (picked due to known instability as we are still developing it) so that ion would serve as a "safe mode" for when you crash hero.
I have a spare phone if i crash this and a secondary sd for if that gets corrupted. Let me know if you need help testing.
twistedumbrella said:
An excellent "misuse" of this concept would be to run ion (picking it for its speed and almost stock nature) with a hero overlay (picked due to known instability as we are still developing it) so that ion would serve as a "safe mode" for when you crash hero.
Click to expand...
Click to collapse
Interesting thought, and if this could be done, I suppose it would be possible to have bluetooth working in ION while using a Hero overlay?
Request for feedback...
Hi All,
Those who've installed android2sd, how is it going?
Can you give some pros and cons of your experience so I may improve things going forward? (Hopefully no cons exists!)
I know that roms that already make use apps2sd will encounter issues as the apps2sd and android2sd function similarly and thus step on each other. I may be able to detect this condition and adjust for it going forward...we'll see.
Thanks in advance for your input!
Darkstrumn
LucidREM said:
very interesting .. at first i failed to see this part as i'm sure many pay skip over the whole "rename to rar" thing - LOL - so this loads profiles from the SD to the phone
for anyone having trouble with the whole "rename" process try this:
http://files.lucidrem.us/jf/android2sd.rar
as i know windows with hidden file extensions does not allow a rename easily
Click to expand...
Click to collapse
Thanks for putting the rar up, XDA wouldn't take the .rar and I didn't want to signup to a file-share site just yet.
And it being seemingly natural to make windows show file extensions, it didn't cross my mind to make a note about that.
Thanks again!
Darkstrumn said:
Thanks for putting the rar up, XDA wouldn't take the .rar and I didn't want to signup to a file-share site just yet.
And it being seemingly natural to make windows show file extensions, it didn't cross my mind to make a note about that.
Thanks again!
Click to expand...
Click to collapse
How come no one is trying this? It seems to me an excellent idea and would be really cool to boot mutipe roms if someone figures that out. I'm not testing this because I'm using appstosd and didn't want conflicts...but no one else with jf1.51 Rom is testing this idea?
Just curious
so wait a second. let me get this straight ... if I have a class 6 8gb card i might be able to install a hero build without rosie or widgets with the original launcher on the sd card that might actually come sorta, kinda, a little close to a speed that might be bearable? at least for like 5 minutes?
Can this be adapted to install bigger roms such as hero without the dangerspl .
XD
Ill try this with ion later tonight
wow this is beautiful work! now to test it!
Im trying so hard to understand this lol.. Correct me on my errors but from what i read this is my hypothesis on what i think this does..
This is like a apps2sd but with data and that type thing from the build we are using? And you Said this takes snapshots So we can create several profiles of the phone? Like for example have a profile with some apps loaded and another profile with all removed and be able to switch between them at will?
The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
I wish google or HTC would contact me, I would say huh, what, me no speak spanish.... lol
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
TheArtiszan said:
Only if that would actually stop lawyers.
Click to expand...
Click to collapse
It would, atleast in this case.
TheArtiszan said:
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
Click to expand...
Click to collapse
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
afflaq said:
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
Click to expand...
Click to collapse
One man's detriment is another man's free market. It's a tough question.
Disclaimer: I hated MMOGlider and the people who use it, and wish they would've died in car crashes.
jashsu said:
The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
Click to expand...
Click to collapse
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
stellarman said:
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
Click to expand...
Click to collapse
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Man all this is too much.... I might get rid of my G1. Google is always trying to ruin the good things for us. -__-"
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk)
Click to expand...
Click to collapse
The framework.apk is APL and part of the Android source. To see what you get without the Googlebits, just run the emulator.
I think the easiest is to have the updater copy the proprietary bits from the phone to your SD card, perform update, then copy back. then reboot.
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
Click to expand...
Click to collapse
Read my post again. I am not suggesting that you try to boot without the parts. I am saying to use the terminal WITHIN Recovery. Do the step of re-adding the proprietary bits BEFORE you leave Recovery and reboot.
Actually people, let's not forget that perhaps Cyanogen had to modify some closed-source apps like Market and Camera on several occasions, right? To avoid crashes due to resource-id changes?
So just downloading older binaries might not always work?
--Tim
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
rewrite those applications if they haven't already been rewritten in one way or another many dialers, a couple marketplaces, youtube, all the apps could be developed just like messenger and browser come on lets just get around google and create the missing apps
kanstin said:
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
Click to expand...
Click to collapse
Anything that requires a user to press more keys is dumb. The problem Google has is that their apps are being redistributed by rom makers.
Lets take a look at how Google circumvents the same restrictions for HTC binaries: http://source.android.com/documentation/building-for-dream
Remember they are advocating circumventing HTC's proprietary licenses by running a script to copy these files. We need to do the same thing, and as long as we are coping the files, using the phone as the SOURCE, the process can be transparent to the user.
Edit:
Also has anyone thought about the fact that HTC proprietary files are being redistributed also? The phones are UNUSABLE without these files.
fauxhawk said:
Anything that requires a user to press more keys is dumb.
Click to expand...
Click to collapse
Yeah, it is dumb. Option #2 runs the script automatically and and Option #3 requires pressing ALT+G. Option #3 is in case the lawyers get really nasty; there is no way they can say that option is in violation because it requires user intervention (pressing ALT+G).
would this approach at distribution impact the optimization and tight fit of the ROM?
This is pretty much the same idea I had last night.
http://forum.xda-developers.com/showthread.php?t=564303
camalot said:
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Click to expand...
Click to collapse
But you are not distributing these files. The update.zip you supply has absolutely no intellectual property which you are not entitled to distribute. Even the script, the IPR for it would be with the dev who write it. Now it might well be illegal - and personally I'd debate whether it is, but let's leave that for now - to *RUN* that script. But that's not the dev's concern and everything he supplied would be his own IPR.
Say you had a friend who worked for Google. It's the same as the difference between this friend emailing you a copyrighted MP3, versus you using Google to search for the same MP3 and then clicking on a link that appears. In the latter case Google hasn't distributed anything - they've merely provided the means for you to find the file on-line. YOU are then the one who breaks the law by downloading it. In the former case, it's your friend - and possibly Google as the people who provide the email system - who break the law.
Any dev who provided a script to download what is needed from a place on the internet and extract them from a zip would be very difficult to C&D.
Hi,
just one short noob question.
If a got a mod that changes some files and another one changing different files but in the same *.apk - i.e framework-res.apk - existing one is completly overwritten by installing second *.apk?
And the only way is to pull existing one from phone and replacing new files inside manually?
Thanks + Greets
idephili
Hi,
i thought answer were quite easier...
I come from windows 6.5 and there it is possible to change single manila files per cab-installation.
On android it looks for me that only the whole apk is substitued, so differents mods replace each other.
Some hints please.
Greets
idephili
Yes, the whole apk is substituted. The only way to "merge" apk's is to flash in recovery instead of installing or pushing. Editing apk's are simple tho. I guess the hardest part would be figuring out what part changes what you are looking for.
Thanks.
Does this mean: creating two update.zip´s with 2 different i.e. systemUI.apk will merge? And is it the point "apply update from sd-card" or just "install zip from sd-card"?
I made some mods for my own but are still not skilled in creating these update.zip-files, using the push method.
For me it´s equal, i know the changements but for publishing them it´s difficult. People want to keep their just made changes. But when it works in this "merging-way" i´ll start skilling..;-)
Greets
idephili
Upon further thinking, I don't believe that merging apk's is possible. Especially for system app simply from the way android views apk's. They are actually zips so they wouldn't be able to transfer info from one over to another without unzipping, merging, zipping, signing, and installing. Didn't mean to get your hopes up but if you would like to try, you would install zip from sd card. Apply zip from sd card assumes you have an update.zip in the root of ur sd. Most mods are pretty easy to spot and manually merge into what you want. I know its a lil frustrating but hey, it'll be worth it right? I'm not an android expert by any means but id like to help u if u need it.
Thank you.
The point ís that i can´t believe that android seems to be in this point more impractical than WindowsMobile 6.5 where can change every single by cab-install.
On android it looks like that u have to merge different mods - referring to the same apk - for your own cause only complete replacement is possible.
Greets
idephili
Yeah, makes me kind of miss Windows Mobile. I can always fire up my HD2 I guess. It kinda sucks that you can't merge, but who knows? Maybe someone will come up with an app to do so in some fashion. Until then, you may use ninjamorph on your phone and edit apks like that. I know it doesn't really solve the problem entirely but if you are away from a computer and need to edit still, that will be your best bet. You can even sign the zip if you have to with signapktic. This was a really good question by the way. I'm surprised no one has come up with a solution as far as I know.
I hope you haven't abandoned this thread and check back. I have a solution to your problem. I had it on my phone the whole time too. Its name is Metamorph. It will allow you to have your apk. And then replace only select files within it without overwriting other changes. I'm so sorry for making you think it wasn't possible. It came to me at lunch that that's the reason metamorph was created in the first place. Hope this helps you.
Hi,
i put a bit of metamorph to pc.
http://forum.xda-developers.com/showthread.php?t=1232479
Greets
idephili
I am a NOOB, but I like myself just fine. The video for NOOBs is funny, but IMHO, should be a bit more serious.
I'm one of those people experiencing issues with GPS and TTFF being excessively long on the MT. Cry.
If I run MyPhoneExplorer, I can see the system file structure, and I believe I can move files to the phone. I believe I can do the same with SwiFTP.
Can one drop replacement GPS libraries for example into the SYSTEM and SYSTEM/HW sub-directories using a program like MPE, or an FTP program like SwiFTP without rooting, and would they be honored on the next reboot?
Would I be mangling some check-sum or other that determines the integrity of the system loaded?
I'm one of those users that doesn't really want to root if not necessary, but I wonder if doing some mod like the above - would doing so lay subsequent update pushes from VMUSA to waste?
Also, I'd really like if possible to flag some programs not to load, unless I explicitly ask them to load via the U.I. with intent. I suppose I'd have to root to do something like that. Perhaps with Ginger-Break? Would doing this make subsequent updates problematic?
Any information regarding my constraints and options to effect both of the above would be very appreciated. Thanks.
There are ways to mount the various partitions from a host machine (e.g. Linux) while it is in the "emergency" flash mode, which would permit what you want to do. Doing this is quite dangerous - at least as much as rooting the device and perhaps more-so.
I appreciate the response.
OK, if I were to root via Gingerbreak and install the files that way, then un-root, would my system then appear to be (to an update provided by Motorola or VMUSA) as something which couldn't be updated?
In other-words would rooting put me on a path to having to use specially modified updates?
Thanks.
Depends on what you change.
In GENERAL no, the update will come through. The major risk is that it crashes on install as some part of what you changed is a dependency but is not reloaded. This is rare, but can happen.
So.... root, install Clockwork, and make an immediate Nandroid backup BEFORE you screw with anything. That SHOULD allow you to un-hose yourself if you get in trouble.
Is there anyone out there who has the knowledge on how to tweak/make ROM's willing to do a quick (I don't know if that is realistic) tutorial on just how to compare to different ROM's? For instance a video or a step-by-step process on how to take one ROM (let's say the Stock ROM of the Droid Charge Gingerbread version) and compare this to a heavily modded ROM (let's say Infinity ROM or Humble)... I'm curious just how the devs do this; many have advised to start here to see how ROM's work, what's different and where the location of different parts are.... Please help thanks..
My initial thread
Hmm good question. Sure most will point you to several links to read different threads. Each Rom depending on what they change are usually an effort by several people. Thats were credit to certain people are given. Some start with a stock ROM and do some tweaks but alot of theme work. Guess thats why you are asking. Think there is so much going on in the back round with what we dont see it would be hard to compare, such as lines of code etc... Dont know if that is the correct answer but figured I would try.
I know, the reason I'm asking is because I've been given advice to start here and the names of programs needed, but I'm not learned enough to use the programs the correct way yet... Figured I'd ask-whats the harm?
Sent from my SCH-I510 using XDA App
Programs:
Linux if you want to extract files from factoryfs.rfs files
7zip or File-roller (or other archive utility)
apktool (or smali/baksmali)
diff (win-diff or kdiff3 also works, can also use git)
Notepad++ or gEdit
andriod-sdk with platform-tools (for adb)
Any dependencies of the above
After that, it's as "simple" as de-compiling various files (with apktool/baksmali) and comparing them. Then use a text editor to add/remove things that you want/don't want from the de-compiled files, or swap out images. After the changes are made, recompile and test. It is a very time consuming process, especially if you run into issues, as problems aren't always easy to track. Logcat will definitely become your friend.
andrewjt19 said:
I know, the reason I'm asking is because I've been given advice to start here and the names of programs needed, but I'm not learned enough to use the programs the correct way yet... Figured I'd ask-whats the harm?
Sent from my SCH-I510 using XDA App
Click to expand...
Click to collapse
You came to the game kind of late. There're so many roms/kernels etc..and the history of them. It will take you months to catch up. I suggest that we would provide you the most current one and it's new/just release you can read up on it. When you look at a rom, alway start on the first page, this is where developer will provide details/description about what has changed for the rom. I would recommend the most current, stable, fast and it's a new release. The TweakStock Rom. This rom when you're using with Go Launcher (Go launcher set to smooth and with some animation, will give you the fluid of Iphone 4S. Start from thread one and see what dev has taken a stock rom and upgraded/tweaked up until today. Good luck. If any question you can post here and we will try our best to help out.
Thanks fellas, I appreciate the advice and I will let you know how I do. One problem I kept running into was in this procedure:
1. Opened kdiff
2.file browse rom a (stock gb in this case) both files still in .tar.md5 format
3. File browse rom b (humble or infinity)
4. Open/compare
5.force close
Second attempt removed .md5, left
.tar, same problem.
Third attempt unpacked and zipped, repeated steps 1-5. Force close.
Fourth attempt, tried to open just the .rfs files and repeated steps 1-5. this time I got a bunch of symbols... laid it to rest...........
So based upon the replies so far, I can see that I was trying to oversimplify a whole; each file must be extracted and browsed individually.
Sent from my SCH-I510 using XDA App