Why/how is the Google ION ROM so fast and lag free? - G1 General

I started using Google ION ROM rev1 last week and I have been very happy. Question is, why is it so much faster and lag free than the standard G1 ROM? I was on JF 1.51 before this and it was very laggy. Also, I first tried Google ION ROM rev2 and I didn’t see any speed improvement.
Is Google ION ROM missing anything? If not, why wouldn’t Google optimize the G1 ROM to be this fast?

The first person to say something about a different version of DalvikVM is getting punched in the face
It's because it's a nice, clean build of AOSP 1.5r2 with no extra bull**** installed, thats all.

whats a DalvikVM?
j/k! "Ducks as cyanogen swings:
P.S. Luvin your work cyanogen, thank you sincerely.

and its not because it has pre-generated odex files either.
Its all kernel optimization I believe.

dwang said:
and its not because it has pre-generated odex files either.
Its all kernel optimization I believe.
Click to expand...
Click to collapse
Nope, the kernel is msm_defconfig (you can pull /proc/config.gz and compare for yourself), right from AOSP with zero changes.

cyanogen said:
Nope, the kernel is msm_defconfig, right from AOSP with zero changes.
Click to expand...
Click to collapse
Ok, it must be "magic" then.

dwang said:
Ok, it must be "magic" then.
Click to expand...
Click to collapse
I installed ion, I dont think its any faster than any of cyanogen's roms

defconoi said:
I installed ion, I dont think its any faster than any of cyanogen's roms
Click to expand...
Click to collapse
same here

salamandar said:
whats a DalvikVM?
j/k! "Ducks as cyanogen swings:
P.S. Luvin your work cyanogen, thank you sincerely.
Click to expand...
Click to collapse
DalikVM is a virtual machine created by some guy at Google.
http://en.wikipedia.org/wiki/Dalvik_virtual_machine
defconoi said:
I installed ion, I dont think its any faster than any of cyanogen's roms
Click to expand...
Click to collapse
I havent tried any cyanogens ROMs yet. I may have to give one a try, its based on JF 1.51, right?

defconoi said:
I installed ion, I dont think its any faster than any of cyanogen's roms
Click to expand...
Click to collapse
alapapa said:
same here
Click to expand...
Click to collapse
Did you install rev1 or rev2?

It's the dalvikvm combined with the .odex optimizations.

afflaq said:
It's the dalvikvm combined with the .odex optimizations.
Click to expand...
Click to collapse
did u even read the entire thread. Not its not.
dalvikvm in ion is exactly the same as j1.5.
android already does dexopt automatically on the dex files in the dalvik-cache. You can see it in the logcat whenever you change kernels.
All the stuff that people are doing to their ROMs are basically all placebo effect. The additional speeds that people are getting is from using cyan's boot.img.

I used ION for a few weeks, actually just started using Cyanogen's newest. I don't really notice much, if any, speed difference between the two. Same with Dude's latest ROM.
I do believe ION is all about the optimization (default CPU is 384mhz, not 528 on G1 port). ION was just optimized as much as possible to run the same speed on a slower processor. At least that's my take on it.

androidmonkey said:
Did you install rev1 or rev2?
Click to expand...
Click to collapse
both
(10 char minimum)

afflaq said:
It's the dalvikvm combined with the .odex optimizations.
Click to expand...
Click to collapse
See here about DalvikVM: http://forum.xda-developers.com/showpost.php?p=4021692&postcount=3791
It's snake oil. I don't know how or why people (and ROM developers) are spreading this idea. It's just plain wrong.
Then read this about dexopt (particularly the "preparation" section): http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
Those .odex files are the exact same thing that is generated by the runtime in dalvik-cache. Now, it *is* possible that accessing resources inside of an apk where the original classes.dex has been removed could be slightly faster due to smaller size, but the zip format is designed to be seeked on so I don't really buy this either.

cyanogen said:
See here about DalvikVM: http://forum.xda-developers.com/showpost.php?p=4021692&postcount=3791
It's snake oil. I don't know how or why people (and ROM developers) are spreading this idea. It's just plain wrong.
Then read this about dexopt (particularly the "preparation" section): http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
Those .odex files are the exact same thing that is generated by the runtime in dalvik-cache. Now, it *is* possible that accessing resources inside of an apk where the original classes.dex has been removed could be slightly faster due to smaller size, but the zip format is designed to be seeked on so I don't really buy this either.
Click to expand...
Click to collapse
Had the forums let me enter that in all caps to show my sarcasm I would have... /bonk

afflaq said:
Had the forums let me enter that in all caps to show my sarcasm I would have... /bonk
Click to expand...
Click to collapse
I realized that after I posted, but the points made are still true.

aFLACK!!!!

Again, it's not the dalkvik vm, or the odex files, or the smaller rom (not much actually, only a few files smaller than an adp google rom), it's the combination of the three plus a few other factors.
Dwang, you keep waving that flag that the dalvik vm does dexopt at the dalvik-chache, yet you're still failing to realize that IT IS DOING DEXOPT AT THE DALVIK CACHE... if the files are pre-odexed, the VM doesn't even do that. The dex at dalvik cache are not optimized, they're still dalvik bytecode, dalvik does this to prevent parsing the whole apk at app runtime and wasting time with both storing the dex to phone memory (which is already limited), and then running dexop at the extracted bytecode (because, as you correctly pointed out the other day, dalvik doesn't do jit, so .dex is quite useless to it),
with odexed files, you're saving both of those steps, the device just executes the .odex as needed without having to load to phone memory (thus linux's memory management doesn't kick in and dump, for example, home screen memory, explaining why you can return to home so quick). On T-Mobile's and google's roms, it goes an extra step by removing the .dex file from the apk, that way, when the machine still has to decompress the .apk file, it doesn't have to load such a big file to memory or check it all.
I don't think there's any sort of device specific modifications, since those would have been meant for the Ion and would break once running in Dream, unless it was haykuro that put them there, in that case, we're barking up the wrong tree and have to ask him what he did, but as I remember, it was actually him who broke ion with r2, so i guess that's not it either.
Nobody really knows why it works the way it does (and in some cases, doesn't work), but the combination of those three things i mentioned DO have an effect on how much work the phone has to do and how fast it can do it. Come on guys, it's all basic stuff...

What? Can people please read the entire thread before posting. Geez.
Its been established that the dalvik vm in ION is EXACTLY the same as in JF 1.5.
And, the dex files in dalvik-cache are optimized. Every time I load a new kernel, the dex files in dalvik-cache get re-generated.
Plus, cyan pointed to this link that says that it is:
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
So its neither dalvik vm nor odex files that is contributing to the speed.
jubeh said:
Again, it's not the dalkvik vm, or the odex files, or the smaller rom (not much actually, only a few files smaller than an adp google rom), it's the combination of the three plus a few other factors.
Dwang, you keep waving that flag that the dalvik vm does dexopt at the dalvik-chache, yet you're still failing to realize that IT IS DOING DEXOPT AT THE DALVIK CACHE... if the files are pre-odexed, the VM doesn't even do that. The dex at dalvik cache are not optimized, they're still dalvik bytecode, dalvik does this to prevent parsing the whole apk at app runtime and wasting time with both storing the dex to phone memory (which is already limited), and then running dexop at the extracted bytecode (because, as you correctly pointed out the other day, dalvik doesn't do jit, so .dex is quite useless to it),
with odexed files, you're saving both of those steps, the device just executes the .odex as needed without having to load to phone memory (thus linux's memory management doesn't kick in and dump, for example, home screen memory, explaining why you can return to home so quick). On T-Mobile's and google's roms, it goes an extra step by removing the .dex file from the apk, that way, when the machine still has to decompress the .apk file, it doesn't have to load such a big file to memory or check it all.
I don't think there's any sort of device specific modifications, since those would have been meant for the Ion and would break once running in Dream, unless it was haykuro that put them there, in that case, we're barking up the wrong tree and have to ask him what he did, but as I remember, it was actually him who broke ion with r2, so i guess that's not it either.
Nobody really knows why it works the way it does (and in some cases, doesn't work), but the combination of those three things i mentioned DO have an effect on how much work the phone has to do and how fast it can do it. Come on guys, it's all basic stuff...
Click to expand...
Click to collapse

Related

lucid Rem mod jf adp 1.5 or the dude cupcake 1.1?

I now have jf adp 1.5, but I want an apps2sd firmware, but I can't decide which one is the best! probably both are the best, I know!
which are the difference between Lucid Rem and the Dude?
JF's firmware comes already supporting Apps2SD. In fact you can do it all right from the terminal on your phone. And where did you d/l from again? Because I know for a fact JF not only states this fact on his blog (the page you probably got it from) but also links to a page of concise and easy to follow instructions. Personally I think you should try all 3 (be sure to READ everything TWICE when using any firmware w/ unionfs).
Also it dosen't hurt to search as I know EVERY freaking bit of this info is w/in the first 2 pages of this forum or on JF's site....RTFM
yes I know JF is compatible to app2sd, but the process to have apps2sd is not so concise and easy: lucid Rem and the Dudes seem to be more easy!
I'm sorry if I asked: I actually red the first 3 pages, not only 2, but it is not so easy to summarize tons of information!
i went through about 8 hours worth of wiping upgrading and testing the builds.
first thing i did was wipe the ext2 partition onthe card using gparted on linux. (i actually removed the partition and repartitioned it to do so. for more stability in case of bad partitioning from before] and then i wiped the phone. before upgrading.
- original JF 1.5 stable. but apps2sd was a bit complicated.
rewipe. repartition.
- thedude's rom is stable, but i found that i could not for the life of me install games. at all. it kept coming up as con.[game].whatever and i couldn't run any of them. [tested with jewellust and tangram pro]. also, the apps2sd is in collaboration with marcusmaximus and while i love the way he did the apps2sd, there wasn't much in instructions on how to make upgrading to thedude's build + marcus' app2sd work perfectly. [i got it to work, but it was w/o it's share of problems]
another rewipe. repartition.
- using Lucidrem's modded 1.5 + apps2sd steps laid out by mailman. simple perfect. 73mb free. apps2sd and stable as hell. i would recommend this.
but most of all, just wipe the ext2 partition for stability reasons. the move from rc33 to 1.5 was not a simple upgrade with apps2sd involved.
Exegence said:
i went through about 8 hours worth of wiping upgrading and testing the builds.
first thing i did was wipe the ext2 partition onthe card using gparted on linux. (i actually removed the partition and repartitioned it to do so. for more stability in case of bad partitioning from before] and then i wiped the phone. before upgrading.
- original JF 1.5 stable. but apps2sd was a bit complicated.
rewipe. repartition.
- thedude's rom is stable, but i found that i could not for the life of me install games. at all. it kept coming up as con.[game].whatever and i couldn't run any of them. [tested with jewellust and tangram pro]. also, the apps2sd is in collaboration with marcusmaximus and while i love the way he did the apps2sd, there wasn't much in instructions on how to make upgrading to thedude's build + marcus' app2sd work perfectly. [i got it to work, but it was w/o it's share of problems]
another rewipe. repartition.
- using Lucidrem's modded 1.5 + apps2sd steps laid out by mailman. simple perfect. 73mb free. apps2sd and stable as hell. i would recommend this.
but most of all, just wipe the ext2 partition for stability reasons. the move from rc33 to 1.5 was not a simple upgrade with apps2sd involved.
Click to expand...
Click to collapse
really thanks a lot! it answers to my question!
just a dubt: my G1 is from uk, so originally it had the RC9, and after few change I came up to adp jf 1.5., the sd card (a trascendent 8gb class 6) is brand new, I just partitioned it for making ext2 partition and I didn't write anything on it. Should I wipe it as well? if yes how I should do?
if lucid rem is rteally smooth I'll go for it!
Hey there, I have the same card, if you already partitioned it but havent written anything to EXT2 you should be good. As for Lucidrem I have been using the modded JFRC33 since day one and props to all the other methods and designers of apps to sd but lucid's was the easiest for me since I dont have a home CPU. I was able to use terminal emulator to run the commands and it was extremely quick & simple. If you're unsure or not able to run adb shell on a cpu like me I would definately go with his modded version
Just to add to this mess
I am using Dude's build (mainly because I had it since .05) and once you update the script in 1.1 your games and protected apps should be fine.
MarcusMaximus states that unionfs method is much more stable an powerfull but I am yet to be convinced in that. It has a HUGE potential (move individual apps back and forth, boot up without sd, etc) and I see why everybody seems to jump on that boat but the question is... do we need it? If you're putting your apps on SD you probably don't want them back on your phone, and, honestly, why do you need to boot your phone without SD? I also think (and this only MY opinion as noone else stated this) that unionfs slows down you system slightly, I could be wrong. At this point, I find it more of the hassle to use it so I'm going back to JF firmware and doing sym-links.
Re-inforcing Exegence's statement, I've used sym-links (Lucid's way) since December with absolutely no problems (app, app-private, dalvik-cache, and caches for market, browser, maps and streetview).
I may see where unionfs goes in few months but at this I'll stick with true and tried.
Good luck to everyone
borodin1 said:
Just to add to this mess
I am using Dude's build (mainly because I had it since .05) and once you update the script in 1.1 your games and protected apps should be fine.
MarcusMaximus states that unionfs method is much more stable an powerfull but I am yet to be convinced in that. It has a HUGE potential (move individual apps back and forth, boot up without sd, etc) and I see why everybody seems to jump on that boat but the question is... do we need it? If you're putting your apps on SD you probably don't want them back on your phone, and, honestly, why do you need to boot your phone without SD? I also think (and this only MY opinion as noone else stated this) that unionfs slows down you system slightly, I could be wrong. At this point, I find it more of the hassle to use it so I'm going back to JF firmware and doing sym-links.
Re-inforcing Exegence's statement, I've used sym-links (Lucid's way) since December with absolutely no problems (app, app-private, dalvik-cache, and caches for market, browser, maps and streetview).
I may see where unionfs goes in few months but at this I'll stick with true and tried.
Good luck to everyone
Click to expand...
Click to collapse
I do agree that the dudes build is awsome but is it faster at first it was fast but now that i have almost 100 apps on my class 6 sd card I see the phone almost pausing when I oper certian apps. emample it I go to bettercut and try to change an icon and click on use icon pack if i have one or two icon packs its fine but if I have 6 or 8 it has a hard time opening the pop up window with the different icon packs... I have no tryed JF with apps to sd only without apps to sd and it was fine maybe i need to give it a shot and see which one is faster!!!!
borodin1 said:
Just to add to this mess
I am using Dude's build (mainly because I had it since .05) and once you update the script in 1.1 your games and protected apps should be fine.
MarcusMaximus states that unionfs method is much more stable an powerfull but I am yet to be convinced in that. It has a HUGE potential (move individual apps back and forth, boot up without sd, etc) and I see why everybody seems to jump on that boat but the question is... do we need it? If you're putting your apps on SD you probably don't want them back on your phone, and, honestly, why do you need to boot your phone without SD? I also think (and this only MY opinion as noone else stated this) that unionfs slows down you system slightly, I could be wrong. At this point, I find it more of the hassle to use it so I'm going back to JF firmware and doing sym-links.
Re-inforcing Exegence's statement, I've used sym-links (Lucid's way) since December with absolutely no problems (app, app-private, dalvik-cache, and caches for market, browser, maps and streetview).
I may see where unionfs goes in few months but at this I'll stick with true and tried.
Good luck to everyone
Click to expand...
Click to collapse
A slight oversimplification of my reasoning in using unionfs, so I'll try to explain my motivations here. My primary motivation was to make the process of moving apps to the sd card more stable. Unfortunately, I think many have misunderstood what I mean by that. I don't actually mean that it will have fewer problems, it pretty much has an equal amount from what I've seen.
What I mean by it is that in the case of a problem, the phone will still start. With the symlink method I was seeing constant problems of boot looping for no clear reason. It seemed to work *most* of the time but when it didn't the system crashed... hard. With unionfs it's extremely rare that I get any reports of problems causing the phone to not start, and when I do it's always a corrupted file system on the sd card. By far the most common problems have been certain specific apps not working(at this point togglesettings is the only one I know of that just straight doesn't work with this method... and it actually works, it just force closes on boot) and some apps having to be re-downloaded when the method is applied. There's no more than a handful of more serious problems(such as apps showing up perfectly in their correct locations on the filesystem but not showing up in the launcher... wtf) which I definitely couldn't say for the symlink method. Actually even problems with a corrupted file system are massively down from the symlink method now that mine won't let you move the app caches(responsible for every single freakin' report of stale nfs handles).
Aside from that was the ability to have some apps/storage on the sd card. This is primarily for stability reasons, just in case there's any apps that freak out(or go really slow) from being on the sd card, they can be moved to the internal memory without having to undo the whole process.
At any rate, I'm not mad at anyone(just in case anyone thought I'm upset about anything said about the unionfs method), just explaining my motivations behind making it a reality.
Maybe I'm missing something, but I really don't understand why there's umpteen different threads about moving apps to the SD card, why there are *paid* apps to do this, etc.
Is it really that hard to type:
cp -a /data/app /system/sd
cp -a /data/app-private /system/sd
rm -r /data/app
rm -r /data/app-private
ln -s /system/sd/app /data/app
ln -s /system/sd/app-private /data/app-private
Why do people make this complicated?
As for instability with the symlink method, I haven't experienced any, and I think it's specifically because I did NOT move the dalvik cache, and there are a number of good reasons for leaving it in place regardless of the method used.
ok, now everything is more... clear but complicate
another question (remember I'm a noob): what is the dalvik cache? why I shouldn't move it? is it huge?
anbd the last (for now ) which is the difference between unionsf and symlink methods?
iso67 said:
ok, now everything is more... clear but complicate
another question (remember I'm a noob): what is the dalvik cache? why I shouldn't move it? is it huge?
anbd the last (for now ) which is the difference between unionsf and symlink methods?
Click to expand...
Click to collapse
Dalvik is the name of the Java VM on Android. It's what's used to run all of the Java programs.
Dalvik-cache is a directory on the filesystem that stores optimized versions of the dex files that are contained within an application's apk archive (think of the dex file as the executable and the apk as a zip file that contains the dex file and other files).
The reason moving it can cause problems is that if dalvik-cache is not accessible, no Java programs (including system programs) can run.
I have tried every combo of build and SD card mods and must say.........they all work, and I think 90% of problems are user error, I know 9 out of 10 of my mistakes were.
My biggest advice, if you dont understand what is happening you will always make dumb mistakes and be "that guy". Try to understand what you are doing before you do it and it you may be able to understand how to fix your own problem.
brandenk said:
I have tried every combo of build and SD card mods and must say.........they all work, and I think 90% of problems are user error, I know 9 out of 10 of my mistakes were.
My biggest advice, if you dont understand what is happening you will always make dumb mistakes and be "that guy". Try to understand what you are doing before you do it and it you may be able to understand how to fix your own problem.
Click to expand...
Click to collapse
While I completely agree with you, I still think that this community needs to agree on whichever way is better and stick with it. This would make it better for developers and users.
I thinks that a pro (hint: MarcusMaximuss) needs to do some bench testing and see if both ways are equal in speed and reliability. If we prove that unionfs method is as fast as symlink onem and stays that way after few weeks of use we can conclude that it is ready for prime time and gear all efforts towards using only that method.
I am in the process of doing a so called "user test". Dude's 1.1a with unionfs apps2sd felt slow to me. At this point I switched to JF1.50 and did symlinks and it's blazing fast!!! Give me couple of days and I'll convert JFs build to unionfs and see if that stays that fast or slows down. I'll do the same thing on Dude's build once 1.2 comes out. But these will be just my impressions, no solid data to back them up.
As always, thank god for Nandroid and good luck to everyone.
I think MarcusMaximus does enough. He doesn't need more work, especially since he's not being paid (only donations).
I think another group interested in advancing these methods should come together and do a test that is more "third-party", so we can have clear and unbiased results.
Having said that, I feel that this method (unionfs) will continue to stabilize as he works on it. Especially since he has commissioned the guidance of the 3 top ROM devs. Very promising in its infancy and just needs to be refined.
cal3thousand said:
I think MarcusMaximus does enough. He doesn't need more work, especially since he's not being paid (only donations).
.
Click to expand...
Click to collapse
Agreed !!!
cal3thousand said:
I think MarcusMaximus does enough. He doesn't need more work, especially since he's not being paid (only donations).
I think another group interested in advancing these methods should come together and do a test that is more "third-party", so we can have clear and unbiased results.
Having said that, I feel that this method (unionfs) will continue to stabilize as he works on it. Especially since he has commissioned the guidance of the 3 top ROM devs. Very promising in its infancy and just needs to be refined.
Click to expand...
Click to collapse
Well... I haven't quite gotten Haykuro on board yet.

Creating Custom ROM for nexus one

To save me "re-inventing the wheel" can any one advise me on the propriety files needed from the N1 to build a custom ROM for it? e.g. libhtc_acustic.so and libhtc_ril.so
I am trying build a ROM from the open source project, so if anyone has advice for me please let me know.
Before you ask, the only reason i am doing this is because i have system apps i want to try on it and they need to be signed with the same key as the shared system uid. If you no a way i can build a ROM from the Nexus to do this please let me know.
Ne0
I don't believe the 2.1 source has hit the AOSP repos yet. So you won't be able to build a complete framework/kernel until that is released.
You could dump your N1 and then just unarchive and resign everything, but it would be a hell of a job I think
I realise 2.1 is not a public resource yet, but i am attempting to roll back to Eclair, just for the purpose of testing my system apps.
I want to resign everything and i dont mind if its a hell of a job!! What do you mean by unarchive? and whats the best way to get a complete dump?
Thanks for your help.
Ne0
Roll back to eclair won't work. The binary blob drivers are tied to a kernel and the kernels are (kinda) tied to the platform releases. So the N1 can only house 2.1 right now (IIRC)
What I was alluding to is that each APK/JAR contains a signature that you want to replace with a sig made by the test keys right?
So if you pulled /system from you're N1 and re-signed each apk and the framework with test keys and pushed that back or made and update.zip holding the re-signed apks (like the theme-makers) you should then be able to test your platform app that is also signed with test keys and a shared UID.
I too would like to know the answer to this.
SilentMobius said:
Roll back to eclair won't work. The binary blob drivers are tied to a kernel and the kernels are (kinda) tied to the platform releases. So the N1 can only house 2.1 right now (IIRC)
What I was alluding to is that each APK/JAR contains a signature that you want to replace with a sig made by the test keys right?
So if you pulled /system from you're N1 and re-signed each apk and the framework with test keys and pushed that back or made and update.zip holding the re-signed apks (like the theme-makers) you should then be able to test your platform app that is also signed with test keys and a shared UID.
Click to expand...
Click to collapse
SilentMobius said:
I don't believe the 2.1 source has hit the AOSP repos yet. So you won't be able to build a complete framework/kernel until that is released.
You could dump your N1 and then just unarchive and resign everything, but it would be a hell of a job I think
Click to expand...
Click to collapse
Correct ... resigning everything with test keys would enable some1 to test out said system apps (also signed with testkeys) ... but only as a test, as it would not be suitable for everyday ROM use.
Resigning with test keys is trivial (search for it) ... but I'd recommend you use the de-odex'd system (see the nexus1 theme templates in my sig).
The reason this is not a everyday solution is b/c resigning everything with testkeys will break the google checkin process, meaning signing into google and using the market will largely break.
But if this is truly just for some sorta system app test, that shouldn't matter.
Other than that, the OP's question is fairly broad in scope. A question like "how to create a custom ROM for nexus1" ... implies many things and many answers.
~enom~
enomther said:
Resigning with test keys is trivial (search for it) ... but I'd recommend you use the de-odex'd system (see the nexus1 theme templates in my sig).
The reason this is not a everyday solution is b/c resigning everything with testkeys will break the google checkin process, meaning signing into google and using the market will largely break.
~enom~
Click to expand...
Click to collapse
Thanks enom, great work. My system apps are just for testing, though it would be handy to make it into a complete ROM so i dont have to keep reflashing when i need to use them. Are you saying that it is not possible to get google checkin working this way? or just that no one has done it yet?
Ne0
Just resigned, sync'd with google, market works and i can install my system apps. All thanks to ~enom~, thanks for posting the deodexed system, saved me a bit of time!

[Q] A call out to the Galaxy S ROM delevopers, help needed!

Well hello everyone.
I am an application development student from Belgium.
I am proficient in Java, VB.NET, some c/c++ and also PHP/JS/HTML/CSS
Anyways, my recent interest has been going out to creating custom roms for the galaxy S!
The problem now is though, I was able to find some guides and such, but most were incomplete, and for HTC(and other) devices.
I have no idea what is different between making a ROM for galaxy S or a ROM for an HTC device.
If anyone would like to link me to some good resources that can help me on my way, or would like to collaborate (and in the meanwhile teach me a bit) I would be more than happy! (I am open for collaboration as I am pretty proficient in Java and I'm always happy to code and learn more about coding!)
I think the question is really want you want to do!
Custom ROMs for Android are as simple as using recovery console to replace files on the system with your own versions.
ie. Replace the framework.apk which contains all theme images with your own modified one, which you can use to skin the device. Same for replacing other system apps.
Unfortunately, most of these apps are closed source, so modifying them is difficult. The stock android system has open source versions of most of them though, and you can modify those and build them, and then replace the ones on the device. I'm not entirely sure how to build them up though, but it probably isn't too hard.
Then there are custom kernels, which let you actually change the underlying linux system underneath android - Samsung has an open source version of the kernel available that you can compile, and then flash to your phone using Odin or other tools. Compiling the kernel is pretty tricky though.
Well i'm really talking about stuff like SamSet, MoDaCo, Doc's ROM and others.
I'm not saying I want to create a pro ROM in a day or anything, but i'd really love to learn more to get better (always looking for more stuff to put on the resume, I guess?!)
Thanks a lot,
Kenny
Bump for some help
(sorry for the double post but i'm really eager to learn)
I don't have time to give a detailed response right now. However you will want to read up on yaffs (file system) and odexing/deodexing ROMs.
Thank you I will definately do that,
I am following a guide now to start out creating custom ROMs for android, however it was written for Motorola Droid and I have no idea what you have to do different for a samsung galaxy s.
I am a good coder, even though I say so myself, with a lot of experience. I also have a lot of linux experience, you name it
Only the problem is the old, and much known "where do I get started?"
So if anyone can point me out in the right direction on that, tell me how/where you started out, I would appreciate it greatly!
Thanks!
Very sorry to bump again
I set up my environment in ubuntu today to get started (just gotta fix a few errors, didn't know android wouldn't compile on java 1.6, only on 1.5)
Anyways, still need some help here! thanks!
Again I am awefully sorry for the bump here but i'd really like some help.
Note that i'm not a newbie at coding whatsoever and i'm not unfamiliar with some hardcore java, c/c++ and other languages, I'm just having trouble getting started when it comes to modding an existing android release (there are tutorials on HTC and other devices but some methods do not apply to the galaxy S)
If you're trying to create a ROM from scratch then unfortunately you're out of luck at the moment. No one has really managed to do so yet. By "from scratch" I mean the Android Open Source Project (i.e. official Android git repository).
What you can do is grab an existing firmware. Extract the contents, de-odex the apks, modify them or add new apks, optionally you can also compile a custom SGS kernel using Samsung's kernel source. Then you can re-odex the ROM, pack it back up and distribute it.
There's no real "starting place" as such and you won't yet find any tutorials about how to create SGS ROMs. Just give it a go and see where you get.
Yes, I do mean creating a ROM from stock samsung firmware, of course.
So my next logical question would be now:
How do I go over extracting contents from the existing samsung firmware, de-odexing and so on?
Any links/guides/tips are greatly appreciated, as long as they are applicable to this cell phone and not totally crap, thanks!
Samsung uses rfs, I think you should know. There is a thread somewhere in this forum regarding extracting .rfs file. Understood you need Debian though.
For some readup, go search for a famous guy named JesusFreke. Tons of materials...
Hope that from here onwards, this can lead you on, and to find out more. Google is your friend too...
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Raykoid666 said:
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Click to expand...
Click to collapse
Agreed completely! Getting a full cross-compilation to Samsung's Android going is seriously difficult! There have been some promises for tutorials and guides for setting things up though, but none have appeared yet. Probably because it's hard!
Well thank you for agreeing with me on that.
I am really hoping for anyone that can help me out here, either on here or in private, and give some detailed instructions on how to get started.
Hell there is enough information on creating roms alread, deodexing, adding/removing apps etc etc etc... The real problem lies in setting everything up properly.
I think I have gotten to the point where I'm compiling the android source (without samsung specific files)
note i'm saying "i think i am compiling" because i'm hoping it won't error out on me again after an hour of compiling!
But once that is done... I have no idea where to go next, where to get the samsung specific files, or what to do with them whatsoever once i have them
thanks!
Android generic source won't actually help you much. Samsung has made a huge number of changes to it, and while it is all open source, backporting their changes to get your stock source running on the phone is a major undertaking. I believe cyanogenmod was actually working on this, but it seems without much success so far.
What the other rom makers you see are doing is taking a snapshot of a running rom, copying over all of the APKs and the files on a running device, and then tweaking those. ie. Opening up framework-res.apk and changing the image files inside.
The update.zip roms that are what most people are doing are really just using the Android recovery to replace files on the phone with their own versions. Since the underlying system is linux, and everything is a file, this actually works pretty well.
The kernel development effort is completely separate from the rest of the system though, and Samsung has provided the entire source tree that just has to be compiled. I'm a bit stumped myself on all the details of setting it up, but I have seen some threads on this forum about it, and it didn't seem too bad to set up. Apparently you shouldn't use the codesourcery toolchain though, or something. Not too clued up on it, sorry. Hopefully someone with the details can chime in, or give us a link to the old post on it (I'm failing to find it using the search function! )
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Raykoid666 said:
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Click to expand...
Click to collapse
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
RyanZA said:
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
Click to expand...
Click to collapse
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Tayutama said:
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Click to expand...
Click to collapse
Haha cool, didn't know you could pull whole folders!
Raykoid666 said:
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Click to expand...
Click to collapse
The apk files in Android are odexed - that means they have a special index applied for dalvik that speeds them up somehow! I don't know how, I haven't checked how it actually works.
The important point is though:
odexed is faster, but you can't edit it because of signatures or something technical
deodexed means you can change it however you want
More useful info can be found from google - lots of it!
update.zip is easy - it's a zip file in a special format that can be understood by Android's recovery console. The easiest way to do it is to grab an existing update.zip and modify it as needed. Tayutama has millions of em around, so use his!
Then you need to sign it once you're finished with it so that the SGS will accept it. Samsung made a boo-boo and didn't disable the test keys for the 2.1 SGS firmwares. That makes it easy!
http://www.londatiga.net/it/how-to-sign-apk-zip-files/
Just use the test keys to sign it, and then copy it to /sdcard/update.zip and reboot into recovery and it'll work.

best mod for elocity A7

My tablet was runnin dexter mod 1.4 with all the patches, buy always had problems with the sd card and the usb thumb and I also had problems running some applications. Right now my A7 is running [mod] update04-19 patched market + google apps and my tablet is working almost perfect. I think this mod is better that dexter mode.
I hope everybody use this mode in their tablets.
Thanks Bestialbub for your great job.
i jus got my elocity a7
i tried to mod mine with the dexter mod 1.41 and mines wont work,
1st- i download the file didn't unzip it then i sent it to the SD card and rename it "update.zip".
2nd- i did the factory wipe/reset then i select to wipe all data
3rd- i select update.zip but i notice an message saying( E. can't read from SD card). i dont know if that is apart of the mod or what.
4th- when it is finish then i select reboot option and when it is done rebooting i get nothing new. can you help me out are do you know something that i might be doing wrong. i also did do the 1.42 patch aswell didn't work. are is there another mod that you can tell me how to get it.
hasn't been tested for application on dexter's rom, though i don't know of reason they shouldn't work. gapps can be flakey like that; actually, the files are all stock as they come from cyanogen, minus my patched market, which doesn't have any reason not to work on dexter's rom and has nothing to to with the installation of the rest of google applications, including the calendar and text messaging services; i introduced no signature issues else it wouldn't install on stock firmware.
what i can suggest, is that if you're doing this under wiped conditions; is that you need to do a "factory reset" in recovery AFTER applying my gapps update.
if you don't do the factory reset, there will be settings put in place by the provision.apk in dexter's rom (not sure if this has changed in 1.42) that may conflict with the setup of google-apps. it didn't w/ the gapps in v1 i ported from dexters rom in previous tests, but i was going for a vanilla install w/out mixed signatures/versions/dates. provision.apk is generally suggested to be removed when google-apps is intended to be installed, and it is by my installer, but not the changes done in the data folders, which is why the wipe is suggested. i think its role is replaced by the googlepartnersetup.apk, but i could be wrong.
theres also some build prop differences; some unnecessary (gsm provider info), some improved (fingerprint for added apps in addition to patched market and added permissions), and the same ones necessary for apps like skype to run.
sorry if that was too much info. i do that.
EDIT: i reviewed my original post, its step *2B*. i did update it to underline it, and provide explanation for its probable necessity.
bestialbub said:
provision.apk is generally suggested to be removed when google-apps is intended to be installed, and it is by my installer, but not the changes done in the data folders, which is why the wipe is suggested. i think its role is replaced by the googlepartnersetup.apk, but i could be wrong.
Click to expand...
Click to collapse
SetupWizard.apk replaces "provision.apk".
bestialbub said:
theres also some build prop differences; some unnecessary (gsm provider info), some improved (fingerprint for added apps in addition to patched market and added permissions), and the same ones necessary for apps like skype to run.
Click to expand...
Click to collapse
Audio fix, which enhances EQUlizer and probably a 10% audio increase, and rotation support for games is another one..
the gsm props were actually very much needed, as Google for a period enabled provider checking, so if no gsm provider was there, you could not activate a google account, so instead of ppl getting lost without MarketEnabler on a clean device, i included it for safety reasons so next time, we're prepared for such checks.. so it all serves a purpose, if you like to know more, XDA has excellent information on those topics.
SetupWizard.apk replaces "provision.apk".
Click to expand...
Click to collapse
thanks for the tip. i did concede i could be wrong, and you're right, i could find that small detail that setupwizard is known to replace functions for provision.apk. the same posts i'm finding on xda and cyanogenmod don't say anything about googlepartnersetup, however, yet its provided with gapps packages..
i also learn from demonstrated and practiced examples..
demonstrated examples i learned from, including your 1.2 rom shows your remove provision.apk and provide googlepartnersetup.apk, then reverse the decision in 1.4, i ASSUME based on signiture issues you had stated (i generally don't have those as i know i can re-use existing containers without having signature issues).
i also learned/ported from various sdk's, including google's sdk for gapp imports, and neither is required, but what is provided is sdksetup.apk.. me seeing a relation from sdksetup for an sdk/emu android device kinda indicates one might want googlepartnersetup as a counterpart on a physical device. (your 1.4 example does prove that doesn't have to be true).. but the google sdk shows that i don't need setupwizard.apk for google services either.
thought i'd relate, since most the general posted information i've seen on xda and cyanogenmod seem like vague gueses at best. though i suspect the people posting this information aren't necessarily the devs working closely with the files. just hobbists and modders making educated guesses like me.
Audio fix, which enhances EQUlizer and probably a 10% audio increase, and rotation support for games is another one..
the gsm props were actually very much needed, as Google for a period enabled provider checking, so if no gsm provider was there, you could not activate a google account, so instead of ppl getting lost without MarketEnabler on a clean device, i included it for safety reasons so next time, we're prepared for such checks.. so it all serves a purpose, if you like to know more, XDA has excellent information on those topics.
Click to expand...
Click to collapse
i was refering to MY gsm provided build prop information, i wasn't ragging on your build prop or rom addons. i followed suit to the gtab tnt modrom and added DIFFERENT gsm provider information than yourself (service provider id, not google client information). but it made no difference in gapps present demonstrated performance as this information DOES NOT (the stuff i provided/borrowed from tntlite) get passed into the android system or database files, as no service provider id is listed when opening marketaccess.apk, as it does on a phone device that does genuinely have this information.
i do concede to the thread discussion, tho, DEXTERS ROM IS THE BEST AND ONLY FULL ROM MOD FOR THE A7 TABLET!!!
my gapps mod is only intended to provide google applications ommitted by the manufacture. nothing more.
thanks for the indirect market patching instructions!
thanks am going to retry and see what happends
bestialbub said:
but it made no difference in gapps present demonstrated performance as this information DOES NOT (the stuff i provided/borrowed from tntlite) get passed into the android system or database files, as no service provider id is listed when opening marketaccess.apk, as it does on a phone device that does genuinely have this information.
Click to expand...
Click to collapse
Had the same issues, so i found the trick to be adding it in the boot.img using the default.prop, and it is added during bootup.. but now we're OT! so let's leave it at that.
a7 installation problem
these are the exat message i got (E:can't open/usb/update.zip)
(E:Can't mount USB:update.zip)
then underneath that it say (Finding update package)
then it say (Wait for 5 second)
(Installation time out)
(installation aborted)
(Formatting MISC)
these are all the thing it say during installation
these are the exat message i got was (E:can't open/usb/update.zip)
(E:Can't mount USB:update.zip)
then underneath that it say (Finding update package)
then it say (Wait for 5 second)
(Installation time out)
(installation aborted)
(Formatting MISC)
these are all the thing it say during installation
why post the same thing every 10 minutes?
.............................
demamalu said:
My tablet was runnin dexter mod 1.4 with all the patches, buy always had problems with the sd card and the usb thumb and I also had problems running some applications. Right now my A7 is running [mod] update04-19 patched market + google apps and my tablet is working almost perfect. I think this mod is better that dexter mode.
I hope everybody use this mode in their tablets.
Thanks Bestialbub for your great job.
Click to expand...
Click to collapse
That is not a mod it's the factory firmware with a patch to get market, I don't see in what way it is better than Dexter mod.
kevinppk said:
these are the exat message i got was (E:can't open/usb/update.zip)
(E:Can't mount USB:update.zip)
then underneath that it say (Finding update package)
then it say (Wait for 5 second)
(Installation time out)
(installation aborted)
(Formatting MISC)
these are all the thing it say during installation
Click to expand...
Click to collapse
When this happen I remove the .zip from file name or just rename the file but most time removing. .zip does the job...

[Q] Questions about Dalvik Cache, Cache, Kernel, Rom's

Hi Guys ^^
I'm new to the Forum, so i want to ask a few Questions:
Dalvik Cache
How does it work ?
Are there special benefits from it ?
Is it modify-able ?
Cache
How does it work
What is the difference between Dalvik-Cache and Cache ?
Kernel
What are the functions of a Kernel ?
What can you modify, adjust and implement in it ?
Is there a BIOS-like Thing, like on a Computer ?
Rom
What are the Functions of a Rom ?
What can you modify ?
What can you modify on a flashed Rom
That's pretty much it
I hope someone can answer my Questions.
In brief : dalvik cache its cache of the apks . ( when u first runs it ''' this is used to make the APk load faster) there are odexed and disodexed ones .
Kernel controls hardware (linux its all a kernel cpntrolling everything) surely there is a bios (Lg logo, samsung logo, they are all BIOS SCREENS )
The visual with effects ( because as said Linux its kernel=prompt lines)
So roms have applications and different visuals
Flashed roms u can modify everything as its is ODEXED
I have just helped you out? HIT THANKS!
Sent from LG-E400
andersonlima said:
In brief : dalvik cache its cache of the apks . ( when u first runs it ''' this is used to make the APk load faster) there are odexed and disodexed ones .
Kernel controls hardware (linux its all a kernel cpntrolling everything) surely there is a bios (Lg logo, samsung logo, they are all BIOS SCREENS )
The visual with effects ( because as said Linux its kernel=prompt lines)
So roms have applications and different visuals
Flashed roms u can modify everything as its is ODEXED
I have just helped you out? HIT THANKS!
Sent from LG-E400
Click to expand...
Click to collapse
Thanks for the informative Reply, but i have a few more Questions :
How can i get into the Bootloader on the LG P700 ?
How can i make a META-INF for a Flashable .zip for Recovery (looked into it, but it seem's like a Register of the Files included, somehow ) ?
Where can i get Driver's, for Gpu, Chipset etc. ?
Is it possible to Dualboot (Two roms) on LG P700
Ps: Yes, you helped me out a lot
Best Regard's
Alex1911
you can get into bootloader with your Clockworkmod Recovery(when you have it)
For meta inf folder look here: http://forum.xda-developers.com/showthread.php?t=633246
Drivers etc you can find(when its open for everyone,on the site from the developer i think,im not 100% sure).
About dalvik
What is Dalvik? We hear that word getting thrown around a lot on the Internet when talking about Android and its inner workings. While there's no easy explanation we can give in just a few paragraphs, we can cover the basics and point you in the right direction if you need to feed your nerdly side. In its simplest terms, Dalvik is a virtual machine that runs applications and code written in Java. A standard Java compiler turns source code (written as text files) into Bytecode, then compiled into a .dex file that the Dalvik VM can read and use. In essence, class files are converted into .dex files (much like a jar file if one were using the standard Java VM) and then read and executed by the Dalvik Virtual Machine. Duplicate data used in class files is included only once in the .dex output, which saves space and uses less overhead. The executable files can be modified again when you install an application to make things even more optimized for mobile. Things like byte order swapping and linking data structure and function libraries inline make the files smaller and run better on our devices. The Dalvik VM was written from square one with Android in mind.
Confused yet? Don't feel bad, geeky programming talk usually has that effect. Think of it this way -- when you build a Java application for your computer, a Java Virtual Machine runs the compiled output of the source code. This is why Java runs on just about any operating system. Dalvik is a mobile-optimized version of a Java Virtual Machine, built with code from the Apache Harmony project, which is open-source and runs better than a standard Java VM would on our limited hardware, designed so that you can run more than one instance of the VM at a time -- ie multitasking. Because Dalvik is open-source, it's also been ported to other operating systems, like the one on the BlackBerry PlayBook. It's pretty damn complicated, pretty damn cool, and Oracle (the company that bought Java from Sun) hates it.
Android uses Dalvik because while the license for the standard Java Virtual Machine is GPL2 (free and open-source), when placed in a mobile device and using the Java Micro Edition, it is not. The big dispute between Google and Oracle is all based around Dalvik. Google claims it was written in a "clean-room" environment without using any of Oracle's code, and Oracle disagrees. We claim to have no idea, we're just glad it works as well as it does.
its a copy from: http://www.androidcentral.com/android-z-what-dalvik
Dalvik Cache...
Thanks for the Reply !!! :victory:
So...could it be that, there is a relation between "deodexed and odexed (Rom's)" ?
What's about the TWRP Recovery Tudorsirb provided ? cause with the CWM i can't boot to bootloader, neither with TWRP
Any Conlusion's ?
Thanks to all actual reply's
Best Regard's
Alex1911
for recoverys and why you dont boot into bootloader i cant give answer,better ask the dev of the recovery etc.
Explaining Odexed vs. Deodexed Android ROMs
You’re bound to have come across the term ‘deodexed’ if you’ve ever installed a custom firmware on your device, since almost all ROM developers choose to deodex their offerings. What this means for the average user, however, is a different story. To understand the concept, you’ll first need to grasp what odex files are, and why are the present in the OS in the first place.
Android (being based on Linux) uses application packages, or APKs, as they’re normally called, to tell the operating system what app to load and execute. If you’re at all familiar with Android, you’ll know that the OS works on the basis of partitions, out of which those apps that are contained in the /system partition are system apps (and cannot be changed or modified without having root level access, since they’re a part of the OS itself), while those contained within the /data partition are user apps and can be freely modified. The /system partition is the first one to load when the operating system boots up, hence giving priority to the apps contained within. It is with these apps that odex and deodex deal with.
What Are The Two Possibilities
Coming back to Android applications, there are two possible routes to follow, based on the fact that each app is comprised of an APK and a cache part that tells the Android Dalvik Virtual Machine (VM) what components does the app come with.
The cache for each APK is contained separately in a .odex file, which loads into the virtual machine at the time of boot, thus speeding up boot times. (Odexed)
The cache for each APK is contained within the APK itself as a classes.dex file, making the boot times slower as Dalvik VM is built up. (Deodexed)
Now, ideally, most OEMs choose to opt for the first route, for two major reasons. First, it makes modifying the system apps more difficult (thus making the OS more stable and secure), and two, faster load times for the OS itself, since the cache is built as part of the virtual machine itself. Confused? Allow me to explain.
Clearing Up the Confusion
In normal cases, where an Android firmware is odexed, the .odex files for each /system APK (which are stored outside of the APKs themselves) are written into the Dalvik Virtual Machine when the OS boots up. Since these .odex files contain preliminary load information about each system app, the OS knows what to expect when it’s booting up, and consequently, loads all these apps faster. Ultimately, for the user, it means that boot times are significantly sped up, and you can put your device to use much sooner.
As opposed to the above, in a deodexed (custom) ROM, there is no cache information within the Dalvik Virtual Machine at the time of boot, so when the system status up, it only gets to know which apps to load once the /system partition APKs are actively accessed. This, in effect, will result in a much longer boot time, since each APK will be processed one by one, and you will be able to use your device long after you’ve powered it up.
Deodex is Slower, Then Why Bother?
In real life, that’s not the case. With deodexed ROMs, only the first ever boot after clearing Dalvik cache is slower, and all subsequent ones will be the same as any odexed ROM. This is owing to the fact that during the first boot, all cache information is written to the virtual machine anyway, and hence, it will behave as any other firmware (until you clear the Dalvik cache once again).
Why ROM developers do it is because of the modification possibilities that it entails, especially theming. Since in a deodexed scenario, all the application code is contained within one single APK, the developer can simply modify the APKs values to apply any custom look and feel to the app itself, without breaking any functionality. This also opens up possibilities for changing different parameters of the app without affecting how others will operate. Since a dodexed package has no external dependencies, it gives more freedom to modify what they wish. On the other hand, with an odexed ROM, theming is absolutely impossible, since the .odex part of the application will always be in conflict.
greeetz
Xposed Framework
So what's about Xposed Framework ?
( I already tried it but, it didn't worked on my LG P700)
How does some of the .sh-script's, work like Supercharger, Crossbreeder or Seeder?
(Tried some Script's but, didn't change anything or makes the Phone even Slower )
Best Regard's
Alex1911

Categories

Resources