I've had some "conversations" with others about how the stock VZW roms, at least with the applications I use, are noticeably faster than the dcd roms (I have nothing against the dcd roms - they are great). This includes the original stock rom and the new updated rom.
So last night I decided to stay up late to do some benchmark testing with the updated rom and the dcd 3.2.6 rom - let me just say that it blew trying to do this since I had already updated to the new vzw rom and had to go through that entire "hell" process in getting it all "fixed" in order to get the dcd rom installed.
Anyway, needless to say, I forgot to save the benchmark logs, both times, before flashing (thats what happens when you are tired). Now you are probably wondering "what good then does this thread serve" - I'll tell you.
I used the application SKTools for the testing - in doing so, that was the only application installed on the device and testing proceeded AFTER all the sktools optimization and tweaks were run.
Without hardcore numbers, here are my usage impressions:
SKTools did very little to improve the performance of the updated stock vzw rom. There was an improvement, but not enough to justify spending money on the application (it isnt free, but comes with a trial period).
SKTools, however, SIGNIFICANTLY sped up the performance (and even freed some extra memory) of the DCD rom to the point where the dcd rom is now noticeably faster than the stock rom (again, I've had different experiences than other users, but I know I'm not alone). To be sure, I then installed a bunch of applications I generally use and saw no noticeable decrease in performance with the DCD Rom after running SKTools. I continue to run certain programs within SKTools in order to keep the dcd rom in top shape.
The program is not free (http://s-k-tools.com/index.html?sktools/m_feat.html) but it comes with a time-limited trial version, enough time to optimize and tweak the device to its top performance.
I'm going to continue to test both roms (its going to be a long weekend of flashing and calling tech support) but wanted to offer this up for others to take a look into and post their impressions.
Post benchmarks please Numbers don't lie..
Yes, and also, since I also have SKTools, please post exactly what you did with SKTools to increase performance. There is a lot of tweaks and options in SKTools so users (like me) need to know which ones you picked to increase the performance.
Chimp (Tom)
SimpTheChimp said:
Yes, and also, since I also have SKTools, please post exactly what you did with SKTools to increase performance. There is a lot of tweaks and options in SKTools so users (like me) need to know which ones you picked to increase the performance.
Chimp (Tom)
Click to expand...
Click to collapse
All of them
Honestly, I ran every performance enhancement and tweak that SKTools allowed
I havent played around with it yet as to whether running all of them are necessary but it sure didnt hurt anything.
As for benchmark numbers - I'm going to have to think about it. Getting that would require going through the entire official VZW upgrade and then downgrade process to get back to where I can run dcd roms since I know for a fact that after the performance enhancements, the dcd will run faster.
It almost doesnt pay to even try to get numbers - more like a "trust me", after running sktools performance enhancements and tweaks with a dcd rom, you'll love it
I can, though, get numbers for the current dcd rom - if someone that has the vzw mr1 update installed wants to get those numbers we can post both
I'll see what I can do this weekend
Yes, and also, since I also have SKTools, please post exactly what you did with SKTools to increase performance. There is a lot of tweaks and options in SKTools so users (like me) need to know which ones you picked to increase the performance.
Click to expand...
Click to collapse
yes pleasy, tell us what you did in sktools... i bought the program and i hardly used it... i want to take advantage of all the tweaks it can take...
thanks man!!!
agreed... more detail on what you did in SKtools other then "everything" so the novice user like my self may benifit from the the programs enhancements. other wise this thread is useless
Well let's see...
Under "System Tweaks":
a) Choose "Optimize" and run all the available options. I'm not going to list each one - just run them all. Also, since I only have the trial I could only choose the 6 options they presented but it helped tremendously. I'll probably purchase the program but am holding off for right now
b) Choose "Clean Up" and run "Invalid Registry Entries" and "Invalid Registry Values" Then run "Registry Optimizer"
c) Choose "Maintenance" and run "Windows Startup" - delete all the programs you dont want to run at startup (frees up memory)
Then I ran the FreeUP Ram program (part of sktools but installed seperately) to, well, free up RAM. I run this program occassionally to help with performance.
Thats all I did and saw a huge improvement in the dcd 3.2.6 rom performance. If you have the registered version of SKTools, you will be able to choose more options than what I presented here. Whether it will help further is not known since I couldnt try it.
deeznuts: When you picked the optimize function, which check mark did you have selected? If you click the Action buttion on the lower left, one of the selections (Performance, Memory, Stability, Maximum Memory) should be checked.
Which one did you use?
Chimp (Tom)
SimpTheChimp said:
deeznuts: When you picked the optimize function, which check mark did you have selected? If you click the Action buttion on the lower left, one of the selections (Performance, Memory, Stability, Maximum Memory) should be checked.
Which one did you use?
Chimp (Tom)
Click to expand...
Click to collapse
Performance - I think that is the default
Its possible that using different profiles on a dcd rom than on the vzw official update rom will produce similar performance between the two but I only experimented with the performance profile on both roms. Quite frankly, I'm happy now with the dcd rom and no longer see a reason to go back to the vzw rom. I also dont have the time or patience to experiment with all the different profiles on both roms - if someone wants to give it a go, be my guest.
deeznuts2 said:
Well let's see...
Under "System Tweaks":
b) Choose "Clean Up" and run "Invalid Registry Entries" and "Invalid Registry Values" Then run "Registry Optimizer"
Click to expand...
Click to collapse
I did that with 3.25 and HHC and another program which I can't remember did not function until I reinstalled it.
I use DinarSoft's Memaid and have it optimized for speed and I have not looked back since.
I didn't notice any increase in performance whatsoever, matter of fact seems a little slower to me, I think DCD has spent enough time with this device that he has it very optimized to begin with, I find it hard to beleive that a "generic" program could possibly increase performance any further than the personal attention and knowledge dcd has put into optimizing his rom.
I've found that SKTools slows down the performance and can lead to registry errors and instability. No thanks.
nonegiven said:
I've found that SKTools slows down the performance and can lead to registry errors and instability. No thanks.
Click to expand...
Click to collapse
yes, if you dont know what you are doing and just arbitrarily delete things that the program tells you are "okay" to delete.
Its not for complete noobs - if you dont know what you are doing you can mess up your device. The program is an advance tweak program - not for your average user to just click here and there and then click "go!" with the hope that all will be well.
Its no different than playing around with a kitchen or flashing a custom rom - if you dont know what you are doing, you will run into problems.
jjlwork said:
I didn't notice any increase in performance whatsoever, matter of fact seems a little slower to me, I think DCD has spent enough time with this device that he has it very optimized to begin with, I find it hard to beleive that a "generic" program could possibly increase performance any further than the personal attention and knowledge dcd has put into optimizing his rom.
Click to expand...
Click to collapse
Depending on what you did, your results may be different. I found a significant improvement with dcd's rom after running a few of the system tweaks.
And unless anyone actually did re-coding of files, no rom is going to be "optimized". Optimization is more than just leaving out unnecessary files and/or putting in newer versions. Programs like sktools actually change system settings for the os, which usually are not easily changeable without getting into the root of the system and re-coding system files after installation, deeply modifying the regsitry, or re-coding the install files prior to installation. I doubt anyone is doing most of these with their roms.
But again, depending on what you do with these programs, your results will vary - play around, its easy to fix if something goes wrong (which it shouldnt)
deeznuts2 said:
yes, if you dont know what you are doing and just arbitrarily delete things that the program tells you are "okay" to delete.
Its not for complete noobs - if you dont know what you are doing you can mess up your device. The program is an advance tweak program - not for your average user to just click here and there and then click "go!" with the hope that all will be well.
Its no different than playing around with a kitchen or flashing a custom rom - if you dont know what you are doing, you will run into problems.
Depending on what you did, your results may be different. I found a significant improvement with dcd's rom after running a few of the system tweaks.
And unless anyone actually did re-coding of files, no rom is going to be "optimized". Optimization is more than just leaving out unnecessary files and/or putting in newer versions. Programs like sktools actually change system settings for the os, which usually are not easily changeable without getting into the root of the system and re-coding system files after installation, deeply modifying the regsitry, or re-coding the install files prior to installation. I doubt anyone is doing most of these with their roms.
But again, depending on what you do with these programs, your results will vary - play around, its easy to fix if something goes wrong (which it shouldnt)
Click to expand...
Click to collapse
Quite the opposite. Noobs might need a program like SKTools to guide you around WM6 but more knowledgeable users have the ability to edit the registry correctly on their own.
If SKTools works for you, I'd suggest sticking with it and not attempting any manual registry editing on your own.
nonegiven said:
Quite the opposite. Noobs might need a program like SKTools to guide you around WM6 but more knowledgeable users have the ability to edit the registry correctly on their own.
If SKTools works for you, I'd suggest sticking with it and not attempting any manual registry editing on your own.
Click to expand...
Click to collapse
Please dont assume you know me or what I am capable of doing. I'm well rehearsed in file system modification, thank you very much. That doesnt mean that using programs like SKtools are useless. Nor does it mean that anyone can use it - you still need to understand what the changes mean and what they will end up doing. I would never tell a "noob" to just click on anything in the program. I only suggested that here since folks on this forum are not your typical user.
If you dont like the program, fine. I found it to be a great help hence the reason for posting.
I wonder if dcd uses this program when building his own roms...
In my experience I've found the following:
DCD has tweaked the hell out of these roms for performance. I'm sure he hasn’t performed every tweak possible.. but he's done a lot.
Programs like Tweaks2k2 and SKtools when run across the board may in fact undo many of the tweaks performed by DCD. Because they are designed to work off of the stock settings.
For example DCD may have tweaked some Cache setting entry in the registry from 4K to 16K because he found the performance to be best... A program Like SK tools may change that to 8k, Because 8k would normally improve performance over the default 4k setting.
Also.. those of you who do a full backup (including the Registry) Then install a DCD rom, then restore may have also overwritten DCD default tweaks. So a Tool like this could increase performance for you… more than someone who didn’t perform a restore.
When you install a DCD Rom, you should re-install your software either manually or with an automated tool.. restoring from backup is probably not the best idea because you risk losing the latest performance tweaks. This is the cause of LOTS of the people reporting that "this or that" isn't working on theirs... but it works on everyone elses... They overwrote it.
You are better off finding these tweaks, going into the Reg and seeing what you HAVE vs what the tweak says will perform better… you may already be optimized or MORE optimized than the tool would make you.
In the end it's really about individual user preference and how you use your device. As we see in this thread for some the tools are great, for others.. not so good.
deeznuts2 said:
Depending on what you did, your results may be different. I found a significant improvement with dcd's rom after running a few of the system tweaks.
Click to expand...
Click to collapse
All of them
Honestly, I ran every performance enhancement and tweak that SKTools allowed
Click to expand...
Click to collapse
Okay, so you can't recall or won't post any specifics of what tweaks you did and you said earlier you did ALL the tweaks SKT offers, then you say "a few of the system tweaks." Of course, "depending on what you did" doesn't jive at all with "Honestly, I ran every ..... tweak..." IF you got improved results after SKT, you should surely recall something. What was the original result vs the improved? You can't recall how much improvement, but it was "significant." You can't recall ANY real benchmark results and you "lost the log files both times." How convenient.
Previously we witnessed your unwillingness in another thread to list ANY of your specific software (even when I sent you a private message) which you said runs better on a stock VZW ROM vs DCD. Claims that can't be tested, of course, are very convenient.
Skepticism about someone's motives and truthfulness result from making unverifiable, undocumented claims. Do yourself a favor and post some specifics.
deeznuts2 said:
And unless anyone actually did re-coding of files, no rom is going to be "optimized". Optimization is more than just leaving out unnecessary files and/or putting in newer versions. Programs like sktools actually change system settings for the os, which usually are not easily changeable without getting into the root of the system and re-coding system files after installation, deeply modifying the registry, or re-coding the install files prior to installation. I doubt anyone is doing most of these with their roms.
Click to expand...
Click to collapse
WOW..
First: SKtools is NOT "Recoding files" All SKtools does is make registry changes for performance.. thats it! And those are pretty easy if you know how to use a registry editor.. (the registry is where those "System settings for the OS" are that you are talking about)
Second.. Thats the point of a DCD rom.. when you install a DCD rom The tweaks that he's tested are already there. He's building a rom that has more features and performs better than stock. He's not just some hack who is removing things.. He's recompiling the entire rom. I'm not sure to what extent DCD actually recodes any files... but I DO know that he includes custom files that others may have made / recoded.
The fact that you would even suggest that SKtools has the ABILITY to do more than DCD or GC14 or any other experienced mobile developer takes the gold medal for dumbest thing I've heard this month.
i've tried
honestly i've tried those programs and i believe while they are tweaking some things they undo some of the stuff that dcd has done to make the rom work like it does. All i use its tweaks2k2 for a few options that i really like but no more sktools for me
Topics Covered in this Thread So Far (or "potential areas for investigation/improvement")
USB modes confusion, CD-ROM mounting bug, and how to make it useful
Hunting for buried treasure in system apk's
EFS backups
GPS
Wifi
Stuff About CDROM/USB Device Protocols
More Stuff About CDROM/USB Device Protocols
Stuff On EFS
Stuff On Hidden Options
GPS power toggle from Drop Down Menu
EVRC-B Phone Voice Codec
Background Noise Cancellation during call
Disabling of debugging stuff and additional code checking
PNG/ogg optimization and Zipaligning
libdvm.so Optimization
Battery Service Polling
RAM management
Disk Scheduler
A more complete nandroid solution
A better voodoo implementation
About scripting
Sleep of Death
Phone.apk mods
More EFS partition info
Info about other partition backups (backing up kernel and others)
Wakelocks/Timekeeping issues and fixing it at the kernel level
Partition mounting tweaks (noatime and such), power management, vm writeback time
More VM tweaks
SD card cache tweak
Reclaiming the Preinstall partition
So I'm going to be out of town for a week or so, and I know that with hacking, that means I could come back and nothing will have changed... or I could come back and everything will have changed (source, anyone?)
EDIT: I'm back... and everyone got thunderbolts! I swear, I leave for one week...
Unfortunately, I myself am a jack-of-all-trades (king of none, sadly), so I've got about 50 different little things I've been working on researching, and won't make much progress on if I keep on trying to do them all at once, since every single project requires that I learn an entirely new set of principles that I never knew about before. Because of this, I have decided to do a brain dump. Hopefully this is welcomed. Some of it will be stuff you already know, some will be dead leads that don't apply, but I hope that there are some nuggets of goodness that will inspire someone to investigate further.
Basically, I go hunting for things that catch my eye, and mark them to investigate later. Unfortunately, later on, I can't find it, so I have to find it again. Therefore, I'll try to present the most I can re-find about a given topic. Also, my memory is very shoddy, so beware of inaccuracies. I am not stating this as a gospel truth, but as a jump off point to maybe catch your interest to go investigate something further. I welcome any discussion, but if you take an idea and make it your own, feel free to start a new thread about it.
Part I:
USB modes confusion, CD-ROM mounting bug, and how to make it useful
Samsung integrates several different USB devices into that one little plug. I count the following:
1. UMS - Mass Storage Mode (looks like a jump drive)
2. MTP - For use with media players to transfer music/videos/pics (looks like a media player)
3. CDFS - Mounts an image onto a virtual device (looks like CD-ROM drive)
4. DUN - Used for Dial-up-networking (looks like a modem)
5. COM port - Used for programming using low level tools like QPST (looks like a serial port)
6. ADB bridge - communicate over adb to the phones through a terminal
With the possibility of TV-out over usb, USB On The Go, or USB Host, then there are probably more.
There is a lot of weirdities that happen because there are different parts of the phone that activates different "modes" which are usually a combination of the above. Try rebooting into CWM and then select to mount the USB. Depending on your set up, you will probably find your SD-drive mounted to the virtual CD-ROM device. Is it the kernel or recovery that's not set to the right usb mode? I don't know.
There are so many different areas that can change the USB device, so it can be confusing to know why you are seeing a certain thing, even though you have it set as something else from the menu. Just a few examples: In the Settings, you have Debugging, which will turn on UMS, CDFS and the ADB. Depending on what Settings.apk you use, there is an accessible Dial-up networking option to enable the modem. There are dialer codes that affect the enabled devices(**usbii which accesses the PhoneUtil.apk, **debug which allows you to change the port map, and toggle DUN). There is a persistent ADB property that can be stored in "/data/property/persist.service.adb.enable". There are system settings that can be added to the .prop files that load on boot, or set by "setprop somepropertyhere" using a terminal or script.
Have you ever plugged in your phone and gotten an autorun prompt that says something about verizon? On the stock roms, there is an ISO that is stored at "/system/etc/verizon_i500.iso". It contains the samsung usb drivers and a couple other things. When it works properly, this would let you install everything you need to get your phone connected to a new computer, without going through the hassle of finding the files. This is especially helpful if you only have internet access through your phone and cannot obtain the drivers elsewhere. All this seems to be handled by the kies service manager, which does really weird quirky things. For instance, you can manually mount the iso onto this virtual cd-rom device, but kies will unmount it after 15 seconds or so. This is why sometimes, if your sdcard gets mounted as a cd-rom, you can actually read the contents for a little while before it disappears.
Why does this matter to anyone? Well for one thing, it explains a lot of the bugs. There are so many different devices, that sometimes they get mixed up in scripts. This is especially true when porting from other software, or mixing and matching kernels and OS's and recoveries. If they aren't all in agreement, weird things will happen.
Secondly, it opens up a cool built in feature that could easily be utilized: emulated cd-rom drives! I haven't isolated the properties (but it doesn't seem too hard to figure out using the logs and such), but I have successfully mounted the memtest boot iso to the virtual CD-rom drive. Think about it: you have a 16gb sdcard in there. Throw on a live-linux iso, and if the computer was made in the last 5-10 years, it should be able to boot from it (not tested yet).
Right now, you can quickly verify this works by making a symlink from /system/etc/verizon_i500.iso to the iso on your sd card. Then, if you know how, enable the virtual cd-rom (I can't remember the exact variable but its as easy as "setprop cdfs.something enable"). There you go! Instant Virtual CD-ROM drive. You can use it to install stuff on your netbook that didn't come with one, or turn your local library PC into a hacking command center (that's a joke... don't do that).
Now obviously, this could be easily packaged up into a neat little apk that would enable the right USB mode, and then allow you to pick the ISO you want to mount. This would be the ultimate goal, not this dirty little demo. Even easier to implement would be to call it from a script, using a script shortcut program.
Part II
Hunting for buried treasure
There are a lot of things hidden in the OS. Almost all of the APK's, if decompiled, have things that are hidden. Sometimes, the full code is there, but the ability to access it has been removed. To make it visible, you may only need to add the info to the layout xml, or remove a line of smali code (look for things like "removePreference" and such).
Other times, it's just a stub of the information. The great thing is, there are so many variations of our phone, almost anything missing can be inserted again if you can find it another device's code. Sometimes, this is a huge pain, because the dependencies can be spread over multiple files, requiring quite a bit of persistence and dedication. Other times, it's as simple as copy and pasting a line, or an entire method.
The i9000, Mesmerize, Captivate and Vibrant seem to have lots of our missing goodies, but a lot of them need to have the code adjusted, and I don't know what to work on first, since some of the easy stuff is worthless, and some of the valuable stuff is impossible. Here are just a few of the screen shots I've taken (yes, I realize a lot of them are probably not portable, but just showing you how much stuff can be hidden in an APK):
http://www.dropbox.com/gallery/22143517/1/Settings?h=7cc415
There are a lot of little APK's that can only be accessed by dialer codes or through a shortcut program. The useful features sometimes are very small and could either be hacked into the main Settings.apk, or called from it, or added into SpareParts.apk. There are a lot of dangerous things in there ("You want me to format your phone and your SD card?" "Nnnn-" "FORMATTIN YO SDCARD YEAAAAAY") so be careful exploring.
Which brings me to another big issue: EFS backups.
One night, before going to bed, I was poking around in a hidden menu (yep). I don't remember actually changing anything, but I lost a setting. Of course, I have no idea what the correct settings are, so I didn't know what to look for, and for 12 hours straight, my data connection would connect and disconnect every minute. I learned a lot about how poorly the os/radio/kernel/something handles the data connection, but I also learned about the EFS partition, and how this could have easily been fixed if I had a backup, and also how it could have been much, much worse.
If you wander through the i9000 forums, there are multiple warnings to backup your efs folder before messing with any settings. If you corrupt certain files, your phone will lose the ability to regenerate its EFS data, and you will lose your IMEI number. Meaning, your phone will not be activate-able. Meaning, your phone will have to be shipped to Samsung to get it fixed, so... good luck with that. If you think you are smart enough to avoid this, if I remember right, supercurio lost a device to this while trying to figure out the secret audio settings stuff.
It's simple to backup the entire partition using your favorite terminal command (I used dd to copy the efs dev/block device to the sdcard, don't know if this is the best method or not). However, it is virtually impossible to get it back once it is gone, if you don't have a backup. (There is someone charging for this service for i9000 phones).
My theory is that i9000's being used on different carriers causes lots of more people to play around with the EFS data, causing more people to corrupt it. Since the Fascinate is mostly only getting used on Verizon, then there aren't as many cases. However, one mistake in a mounting script in a recovery/kernel/os, and you're toast. Not only that, if you have a working backup and you go messing with the radio settings, then you will always have a backup that doesn't require you to activate another phone and then reactivate your's in order to get your phone working again. (All the while, watching in horror as your logcat fills with a continuous stream of data connection failures).
This is something I'd love to hear more from by someone who knows about it, and if it's as valid of a concern as it is on the i9000, then I'd really like to see more publicity about it's importance.
Part III
Is supposed to be about GPS and wifi, but dang, that is a crazy amount of stuff to write. I hope that a little bit of info, along with a link dump will be okay. And to be honest, I'm getting tired of typing now. I keep thinking of more stuff, but I haven't even fully fleshed out what I've posted so far. Hopefully, I'll be able to do some more later (and even more hopefully, there comes some good from it).
GPS
Most promising is the Captivate GPS work. This thread is a little bit old, but it contains good info. There might be newer information available as well:
http://forum.xda-developers.com/showthread.php?t=881941
The i9000 GPS dev has some good posts as well, explaining it very well. Again, there might be newer information, but this is what I have bookmarked:
http://forum.xda-developers.com/showthread.php?t=842694
It talks about using the "LbsTestMode.apk" for testing. I have no idea if it works for actually configuring the files (I was told it doesn't), but I am providing it here for the possible testing it can do:
LbsTestMode.apk
http://dl.dropbox.com/u/22143517/Android/LbsTestMode.apk
This is just a quick (and not very entertaining) video of setting up a shortcut to access it instead of using a dialer code, then running through the menus real quick so you can see what is available.
http://dl.dropbox.com/u/22143517/Android/lbstestmodedemo.mp4
From a cold boot, in google maps, I can get a lock down to 2 meters in 3-5 seconds with wifi off and GPS standalone enabled when I'm outside. Inside, usually 10-20 meters at first, then drops to 5 after a few more seconds. So I don't know if it's something I've done, or if I just got lucky with a good chip, but I have a hard time testing GPS fixes because I don't have problems (but things can always be better, right?)
I highly recommend checking into the app "GPS aids" if you like the idea of assisted gps. I find that AGPS hinders my GPS performance, but after using GPS aids, it's about as good as normal. So for someone with bad standalone GPS performance, maybe it would help them out using AGPS.
Wifi
Oh boy... I don't know where to start with this. It completely ignores the system property wifi.supplicant_scan_interval. There are files spread across /system and /data that relate to wifi. The binary 'wpa_supplicant' is a source of hackery on other systems, but I don't know if anyone has attacked it on the Fascinate side of things. Want to see ad-hoc networks? This is the file that they usually hack to do that. Other devices have hacked the ability to enable infrastructure mode for wifi tethering. I don't know if this has been done yet for SF.
There are a lot of hidden wifi, wps, and tethering options in the Settings menu. Several system settings properties relating to wifi, several .conf files for the messing, wlan services for the playing, and a nice engineering mode when calling WlanTest.apk that says it's loading a different driver (I can't remember what all neat stuff is in that).
Stuff About CDROM/USB Device Protocols:
My thoughts exactly, the cdrom driver is useful, maybe more so.
The issue as to what starts when is configurable, Eclair had a hard limit of 2 usb modes at any given time, if I recall correctly Froyo supports 4 and that maybe a hard limit by the device. So what is running has to be carefully chosen, with mtp, virtcd, virtcom, ums, adb, acm, usb-otg, tvout, wired tether you hit 4 quick. This is an issue on my table but of low prority, as without a fully working kernel these amenities become mute.
I intend to make the cdrom driver configurable to select various isos from sd and switchable on command, I feel it would be more useful in that state, and I plan to give the user more control over what usb modes are selected using a sysfs setup, the defaults are in about 6 profiles that barely cover my needs without slowing me down.
Edit, More Stuff About CDROM/USB Device Protocols:
I have never tried to get all of the devices working simultaneously, but I do know that if you enable the virtual com port for EFS editing that DUN support is disabled, and that if you enable UMS(USB MassStorage)/SDcard that UMS/VirtCD is disabled, and if you enable UMS/VirtCD that UMS/SDcard is disabled, and I don't use MTP (think syncing your music from WindowsMediaPlayer to Android) so I'm not 100% sure about this one, but I think MTP is disabled if ADB is enabled. At least this is how stock is anyway.
Stuff On EFS:
The I9000 EFS stuff is a little out of my department, but I would love the ability to edit EFS reliably within the OS, unfortunately unlike with the I9000 our devices do not mount an EFS partition, and I have not ventured to attempt looking for it. I imagine it would be just as easy for us to edit it in device as it is for the I9000 people, however if it is due to the way the radios are handled this may not happen, as we are still trying to figure out where the Fascinate keeps it's modem, it would make sense that the EFS partition and the modem code would rest in the same area or partition, if we could only for certain identify it. I think the FSR and FSR_STL drivers obscure our view of it, no fear, I will be attempting to import Gingerbreads MTD work into the my WIP Froyo to hopefully solve this issue once I get the radio working reliably. If and once we do have access to EFS, we could technically copy and replace or edit our Verizon EFS information live, flash from one network to another, and update tower information possibly without even restarting the phone....that is IF we have access to the EFS partition, and logic says we should have access to it ( as every other CDMA Verizon and Alltel device I have used does have one ) and it is programmable from within the Samsung device setup APKs.
Stuff On Hidden Options:
As for the special hidden stuff....it just boggles my mind the amount of crap they hide (or did they forget about this stuff?!?) from us, most of it doesn't work, most of it has no warnings for the DANGEROUS stuff it can do without prompting for a confirmation (ie complete factory reset and yes sdcard formatting) I think this crap should have been jammed into a single engineering menu accessible via a fixed passcode rather than scattered from A to Z in 20 different APKs with little more indicator of what an option does than some cryptic function name and a report of what someone else may have experienced only after executing the command. At the very best it's an unorganized, inefficient, undocumented, unreliable, low level, factory device configuration menu set that even most experts do not know how to fully utilize.
SirGatez said:
My thoughts exactly, the cdrom driver is useful, maybe more so.
The issue as to what starts when is configurable, Eclair had a hard limit of 2 usb modes at any given time, if I recall correctly Froyo supports 4 and that maybe a hard limit by the device. So what is running has to be carefully chosen, with mtp, virtcd, virtcom, ums, adb, acm, usb-otg, tvout, wired tether you hit 4 quick. This is an issue on my table but of low prority, as without a fully working kernel these amenities become mute.
I intend to make the cdrom driver configurable to select various isos from sd and switchable on command, I feel it would be more useful in that state, and I plan to give the user more control over what usb modes are selected using a sysfs setup, the defaults are in about 6 profiles that barely cover my needs without slowing me down.
Click to expand...
Click to collapse
Glad to see you in here, as I think the whole issue is very much best implemented/fixed from the kernel with the OS just facilitating from there. Also interesting that someone else was thinking about this while I was. With the little amount of knowledge I have, trying to hack around the different usb profiles at the OS layer is a pain. ("let me mount this" "NO, STOP IT!" "come onnnn let me turn that on")
I know I personally have had UMS, CDFS, DUN, Serial, and ADB all showing up in windows device manager at the same time, by manually toggling them on. That was as far as my test went, so I have no idea if they were accessible at the same time. But it's interesting to watch the device ids change as it switches modes. I have very little driver knowledge, so actually doing much digging was over my head.
Ok, I think I'm done for the night. Sorry for the quality of info, I'll try to work on it more sometime soon.
I feel like we are all just holding our breath for froyo source, but a lot of profitable work can be done in the meantime. Really, a lot has already been done that we can just kang from other devices. We just need to look outward at our foreign cousins.
For instance, supercurio did a lot of work on hacking the sound before they had kernel access. Using his methods from back then might give us some improvements in the meantime.
Things like GPS and Wifi will probably continue to be an issue even after we have source, so they can be done without fear of being completely forgotten about as soon as source drops.
Lots of mods and tweaks that are widespread across other devices don't seem to be discussed. Build.prop hacks are cheap and easy things that don't get much action around here (though not all of them are applicable/or even helpful). Someone brought up the FuguTweaks thing the other day from the Captivate forum. More of these cross-device discussions would be awesome.
God, my brain just exploded.
This is actually quite interesting, though. Now, on Part II: certain Sammy .apk's have hidden usage? Could we combine that into a massive super-settings app?
Samsung Fascinate, Verizon
EB01 Superclean 2.4
Kenesis' TransMyst GBKB (EPIIIIIC)
Mob87's Honeycomb Theme
Stock Kernel
obsidianchao said:
God, my brain just exploded.
This is actually quite interesting, though. Now, on Part II: certain Sammy .apk's have hidden usage? Could we combine that into a massive super-settings app?
Click to expand...
Click to collapse
That's the idea. CM has a lot of this kind of thing, but we aren't there yet. There are also a bunch of testing apks that I didn't mention built right into the stock ROM.
There are even some super mega apps (some available on the market) that are somewhat compatible (be careful with these, especially for low level stuff). "Sysinfo" reveals a lot of... system info that you normally have to go digging around for. So does "Under the Hood". "Tuxility" doesn't really have much, but could be an easy start for the basis of a SF compatible utility. "SuperPower" gives a lot of control over power options. "SpareParts" from other Galaxy variants have had lots of options added. There are some other SGS specific tools that half work, as well, but their names are slipping me now. One allows you to flash a kernel from the OS. Also, I wonder if Development.apk from the emulator might have some use?
There are tons of things that could easily be added to the SpareParts app too, if you didn't want to add it to the Settings app.
So much stuff to kang.... so little time.
Dude. This is... amazing. Can you mentor me on this stuff? XD
Now, Spare Parts is that app in SC that shows the battery info and stuff, no?
Edit: and what all could you drag to spare parts? Could it access those hidden .apk's and utilize the secret functions?
This is so cool.
Samsung Fascinate, Verizon
EB01 Superclean 2.4
Kenesis' TransMyst GBKB (EPIIIIIC)
Mob87's Honeycomb Theme
Stock Kernel
Part 4
GPS power toggle from Drop Down Menu
The GPS option from the drop down menu is essentially broken and needs to be fixed. I recall a similar problem on a different device with the wifi. With that device, on observation, I noted that on powering up wifi from the settings menu, I would be connected within 5 seconds, but from the power widget, it would take a full minute. After doing some investigating, the power widget was basically trying to control the wifi device directly. I found a different widget that essentially emulated the same method used in the system settings menu, and it starting connecting immediately. My guess is that the GPS power code on the pull down menu could be modified using the same examination/modification needs to be adapted in the same way.
EVRC-B Phone Voice Codec
Switching to the EVRC-B codec improves call quality substantially, for both parties of the call. If anyone knows of a way to set it that doesn't involve going into service mode and manually changing it, then please let me know.
Background Noise Cancellation during call
Also, I'd love to find a fix for the mic during calling. It's a frequent occurrence for the person I'm calling to be like "Who are you talking to?" because they hear someone talking in the next room away from me. Or a very light sound on my end, elicits a response of "WHAT IS THAT NOOOISSSE??!" from the person I'm talking to. So obviously an issue of background noise cancellation. I'm hoping its a software fixable problem.
I've seen this build.prop edit to mess with the noise cancellation for disabling noise reduction for the voice recorder (Say you are trying to record something like music, or something at a concert, the noise filter would hinder your ability).
Code:
media.a1026.nsForVoiceRec=0
media.a1026.enableA1026=1
Two things about this:
1. I've only seen this kind of property on other devices that have two mics that work in combination for noise cancellation. I'm guessing the SF only has one, and any attempted noise cancellation is done at the hardware level or in software.
2. This would assume that the noise shield actually exists, but the stock Fascinate behavior is to not have it enabled for calling... which is pretty dumb. Given some of their other decisions, this may be true, but I have my doubts. If it's parameters are accessible, and it's merely only needing some tweaking, then I will be happy.
I wonder if supercurio knows much about the noise cancellation, since he's worked with so much of the sound stuff?
Disabling of debugging stuff and additional code checking
Debugging stuff is essential for figuring out problems, but for the 99% of the time, isn't it probably slowing us down? I don't know what would be the best way to easily disable any additional debugging routines that might be affect performance.
As for disabling code checking, I used to run these build.prop edits on an older device. I have no idea if they still apply:
Code:
ro.kernel.android.checkjni=0
dalvik.vm.checkjni=0
dalvik.vm.verify-bytecode=false
Maybe you are the kind of person that needs their phone fully stable at all times (no you're not, because you are on a forum that is made to push your device to the limits). I, however, keep everything backed up, so if disabling this extra "security" might slightly increase risk of data loss, then I'm okay with that (not saying that this is an actual danger, but just in general). The only problem I have is if the increase is negated by a large rise in errors that actually hinder performance, or if it becomes significantly more risky (doubt that's the case, but it's always a possibility).
Somewhat related, we currently keep the dalvik heapsize at 48mb's. Is this the best match for our device, or just the default?
PNG/ogg optimization and Zipaligning
I recently took a superclean rom, and dropped 16MB losslessly just from throwing the pngs through PNGOUTWIN and deflopt (didn't touch the *.9.png files). Free RAM right there. Not to mention that some of those APK's have ridiculous extra resources that can be reduced by cutting color depth or taken out entirely (giant HTML based tutorial files stored in the apk... why?) Also, all of the ogg files can be slammed down using a sox script or an equivalent.
In compression, it's also important to know when its a free and harmless, or when it will reduce stability. You can zip up an APK nice and tight... but aapt is a better method. The files might be bigger, but they will run better (also, learn how to treat *.9.png files, or don't touch them at all).
I've adapted the script from Bugless pete's automatic, on-phone zipaligning utility (just had to change a couple lines). A lot of times there are apk's that slip through the cracks in the ROM's that aren't zipaligned (especially in themes and patches). Again, just free performance that isn't hard to obtain.
libdvm.so Optimization
Has our libdvm.so been optimized to run on on our processor? I know this was a huge boon for older devices, but couldn't find any info on ours.
Battery Service Polling
Ever watched the logcat even when your device is nearly at idle? Ya... that battery is always updating. How do we change this habit? I often wonder how much extra juice would we gain by increasing the length in between battery polls.
GizmoDroid said:
Ok, I think I'm done for the night. Sorry for the quality of info, I'll try to work on it more sometime soon.
I feel like we are all just holding our breath for froyo source, but a lot of profitable work can be done in the meantime. Really, a lot has already been done that we can just kang from other devices. We just need to look outward at our foreign cousins.
For instance, supercurio did a lot of work on hacking the sound before they had kernel access. Using his methods from back then might give us some improvements in the meantime.
Things like GPS and Wifi will probably continue to be an issue even after we have source, so they can be done without fear of being completely forgotten about as soon as source drops.
Lots of mods and tweaks that are widespread across other devices don't seem to be discussed. Build.prop hacks are cheap and easy things that don't get much action around here (though not all of them are applicable/or even helpful). Someone brought up the FuguTweaks thing the other day from the Captivate forum. More of these cross-device discussions would be awesome.
Click to expand...
Click to collapse
Your gonna hold your breath a long time if you're waiting for froyo source.
If anyone needed proof that Quadrant scores aren't good indicators of real performance, this is a real, unedited screen shot from my phone running EB01:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I dropped the link in IRC for giggles and a couple of people lost their minds, accusing me of lying. Sorry fellahs, I got better things to do.
You can boost your quadrant scores this high with a couple easy steps that provide absolutely no performance boost outside of quadrant (it's is similar to why voodoo enabled systems score so high, but only perform somewhat better). So for the hold-outs that still think that quadrant is a reliable benchmark... be aware of it's major flaw.
GizmoDroid said:
If anyone needed proof that Quadrant scores aren't good indicators of real performance, this is a real, unedited screen shot from my phone running EB01:
I dropped the link in IRC for giggles and a couple of people lost their minds, accusing me of lying. Sorry fellahs, I got better things to do.
You can boost your quadrant scores this high with a couple easy steps that provide absolutely no performance boost outside of quadrant (it's is similar to why voodoo enabled systems score so high, but only perform somewhat better). So for the hold-outs that still think that quadrant is a reliable benchmark... be aware of it's major flaw.
Click to expand...
Click to collapse
I have been trying to convince people of this flawed benchmark app for months when using Blazed Eclair, it scores almost normal but runs the same voodoo other kernels do plus lots of other tweaks on kernel side. Very few believed me and switched from Blazed JUST for higher quadrant benchmark scores
Sent from my SCH-I500 using Tapatalk
SirGatez said:
I have been trying to convince people of this flawed benchmark app for months when using Blazed Eclair, it scores almost normal but runs the same voodoo other kernels do plus lots of other tweaks on kernel side. Very few believed me and switched from Blazed JUST for higher quadrant benchmark scores
Click to expand...
Click to collapse
Maybe I should make a HOWTO tutorial on how to get ridiculously high quadrant scores on any OS/kernel, then people would be free from using it to influence their thinking and instead would base it on real world results.
The cynical side of me says that they would just find a new benchmark and do the same thing with it.
Meh, we know the truths, so sure make a howto, maybe quadrant will fix their flaws (yeah...i'm not sure about that one...) people on the otherhand will flock like you say without our intervention, but for the rest of us this could prove helpful in building roms/kernels that do not allow benchmarks to succumb to the same flaws that most current ones do
Sent from my SCH-I500 using Tapatalk
SirGatez said:
Meh, we know the truths, so sure make a howto
Click to expand...
Click to collapse
[HowTo] Release the most downloaded ROM of all time:
Take stock rom.
Insert the following line into a boot script:
Code:
mount -o rw -t tmpfs tmpfs /data/data/com.aurorasoftworks.quadrant.ui.standard
Upload ROM to host of your choice.
Post screenshots of Quadrant scores with download link.
Great Success.
There are lots of ways to inflate quadrant scores... but this is the funniest method because it makes it ridiculously obvious how voodoo can achieve inflated quadrant scores without gaining a similar amount of performance (they both write cache to memory, therefore inflating the I/O scores ridiculously high).
Adding more to the noise cancellation issue, I found some more info out tonight:
Jamezelle pointed out a property that is set in res/values/bool.xml in the Phone.apk "has_noise_suppression" and it's set to false. After digging around, I found that this shows up in the PhoneUtils class if you decompile Phone.apk. It reveals two options: "noise_suppression=auto" and "noise_suppression=off". Some realworld testing needs to be done, but if the fascinate has the noise surpression ability and its just turned off, then this could be turned on again by adding to build.prop, or by modding the options menu to have this show up as an option.
Its very possible that it's hidden because it's not implemented, but other Galaxy S phones have some type of noise cancellation, so it might just not be implemented in the software.
Don't know if you were still looking for how to change EVRC to EVRC-B, but dial **72, the spc code is 000000, press down on the directional button arrow until you see Svc mode nam 1 end of basic nam exit. Press the right directional key once, you will see EXIT change to more, hit enter, press down once and you will see HomePage VoiceSO and EVRC, push the right button to change to EVRC-B. Hit ok and phone will reboot. Sorry for the sloppiness, at work and trying to be quick.
Edit: Ah, nevermind, you didn't want service mode, sorry!
Sent from my SCH-I500 using XDA Premium App
Dread This Day said:
Don't know if you were still looking for how to change EVRC to EVRC-B, but dial **72, the spc code is 000000, press down on the directional button arrow until you see Svc mode nam 1 end of basic nam exit. Press the right directional key once, you will see EXIT change to more, hit enter, press down once and you will see HomePage VoiceSO and EVRC, push the right button to change to EVRC-B. Hit ok and phone will reboot. Sorry for the sloppiness, at work and trying to be quick.
Edit: Ah, nevermind, you didn't want service mode, sorry!
Sent from my SCH-I500 using XDA Premium App
Click to expand...
Click to collapse
Yeah, this way does work, and I have used it multiple times. But it resets itself every time you reactivate, and its near dangerous settings, so its not something I would recommend to newbies.
If there was a less dangerous way to set it (say from a script or an apk) then this could lead to it being more widely recommended. It really does provide substantial improvement of call quality.
If my gf calls using her bluetooth headset, which has mediocre sound quality, the further compression of EVRC makes her very hard to understand. With EVRC-B, I can understand her plain as day.
Dread This Day said:
Don't know if you were still looking for how to change EVRC to EVRC-B, but dial **72, the spc code is 000000, press down on the directional button arrow until you see Svc mode nam 1 end of basic nam exit. Press the right directional key once, you will see EXIT change to more, hit enter, press down once and you will see HomePage VoiceSO and EVRC, push the right button to change to EVRC-B. Hit ok and phone will reboot. Sorry for the sloppiness, at work and trying to be quick.
Edit: Ah, nevermind, you didn't want service mode, sorry!
Sent from my SCH-I500 using XDA Premium App
Click to expand...
Click to collapse
Thanks, working great! But you posted incorrect dial code. Let me correct you. **772
Here I am providing a link for a modified version of the 20110721 rootfs.img. But before anything else, allow me to explain exactly what was modified and why. And also, I'm running FRX07 with the default kernel it came with and the newest rootfs, OC'd to 614.4MHz (although OC doesn't play much factor in this tweak)
During the portion of the boot cycle when it loads the rootfs, at some point the read_ahead_kb (cache on the SD card) is set to 2,048KB as default with the newest rootfs. For higher-end SD cards, this is a good, wholesome number to work with..
With me, I'm running on a 2GB class 2, and using the program SD Booster (free), I was able to switch the read_ahead_kb while running Android. I tried multiple values and noticed the best results with 256KB.
Before with the 2048KB setting, the boot animation would cease a few times for probably a good 6-7 seconds, was terribly laggy throughout, and ultimately, from my experience, the performance of Android was impacted negatively. The system would literally halt while performing basic operations such as opening the Settings menu... although not all the time, still pretty annoying :\
By making this change in the rootfs.img, I noticed that the boot animation was MUCH MUCH smoother. I did not get the aforementioned problem at all using this rootfs.img with my SD card. And I also noticed a nice decrease in boot time, PLUS a pretty hefty boost in performance and stability after the boot even more than when manually changing the value with SD Booster!
I know not all people are running on premium SD cards and that is pretty much the whole point of this thread: to provide people who DON'T have the best with something that could help with their performance.
And for the record, I'm no dev. I just know some bits and pieces and like to share my experiences.
Please post feedback if it helps you!! It makes me feel better lol
ALSO: Before I even thought to post this, I made sure I uninstalled SD Booster to make sure it didn't apply any settings on boot, rebooted the phone into Android, reinstalled SD Booster, and noticed that it was no longer set to 2,048KB as default doesn't hurt to double-check!!
Since you're talking about a 1-line change, it would seem to me to have been far more efficient just to post the single line you changed, rather than make people download a multi-megabyte rootfs img file all over again.
highlandsun said:
Since you're talking about a 1-line change, it would seem to me to have been far more efficient just to post the single line you changed, rather than make people download a multi-megabyte rootfs img file all over again.
Click to expand...
Click to collapse
Good point.. although most people like swapping rootfs.img's and making things easy, plus I already had the rootfs ready for myself.. I figured why not.
But you're right, it would be helpful to know either way, so this is exactly what I did. I opened the init file within the rootfs.img (after mounting in Ubuntu) and searched for "read_ahead_kb" and found it. At the front of the line read: "echo 2048". That's the command that enables the 2,048KB SD cache during boot (the rest of the line I assume is to apply that setting to the SD card? Not sure..). I changed that value to 256KB, making that: "echo 256". Saved the file, unmounted the rootfs, and voila.
maff1989 said:
Good point.. although most people like swapping rootfs.img's and making things easy, plus I already had the rootfs ready for myself.. I figured why not.
But you're right, it would be helpful to know either way, so this is exactly what I did. I opened the init file within the rootfs.img (after mounting in Ubuntu) and searched for "read_ahead_kb" and found it. At the front of the line read: "echo 2048". That's the command that enables the 2,048KB SD cache during boot (the rest of the line I assume is to apply that setting to the SD card? Not sure..). I changed that value to 256KB, making that: "echo 256". Saved the file, unmounted the rootfs, and voila.
Click to expand...
Click to collapse
Interesting. I don't think my card would be considered 'premium', but it is a class4 card.
I'll see if this change makes any difference. IIRC this value was bumped in the newest build to provide better performance, not worse! I guess that's the tradeoff - better performance for some, worse for others... oh well. Thanks for your work!
arrrghhh said:
Interesting. I don't think my card would be considered 'premium', but it is a class4 card.
I'll see if this change makes any difference. IIRC this value was bumped in the newest build to provide better performance, not worse! I guess that's the tradeoff - better performance for some, worse for others... oh well. Thanks for your work!
Click to expand...
Click to collapse
You're very welcome I know the 256kb setting may not work better for all.. but I think this setting is key to how well Android performs on different cards.
Also, I DID notice that OC'ing is much more stable using this setting for my SD.. currently running at 768MHz and minimal instabilities.
Sent from my MSM using XDA App
I appreciate you posting the process you used to figure out optimal settings. I'm toggling between sd tools and sd booster as we speak. I'm still trying different settings. If my settings are different, that'll give me an excuse to figure out that virtualbox build I started on a few months ago.
EDIT: hmmm, I'm not sure sd tools is going to be a useful bench tool. 2 different runs on the same settings vary pretty wildly. I think the meter animations might be interfering with the testing. How did you decide which setting performed best while using sd booster? Were you just going with what felt best?
fortunz said:
I appreciate you posting the process you used to figure out optimal settings. I'm toggling between sd tools and sd booster as we speak. I'm still trying different settings. If my settings are different, that'll give me an excuse to figure out that virtualbox build I started on a few months ago.
EDIT: hmmm, I'm not sure sd tools is going to be a useful bench tool. 2 different runs on the same settings vary pretty wildly. I think the meter animations might be interfering with the testing. How did you decide which setting performed best while using sd booster? Were you just going with what felt best?
Click to expand...
Click to collapse
Personally, I never benchmarked my results.. I would change the kb setting in SD Booster to different values and resume normal operation of the phone (opening programs, checking for any abnormal "halts" during opening/closing animations and general program operation).
Basically, you're right; I found the best setting for my card based on trial-and-error and what felt right, then applied that setting in the rootfs to further increase performance over applying this setting AFTER boot.
Whichever setting feels right to you will most likely yield the best results.
Sent from my MSM using XDA App
maff1989 said:
Good point.. although most people like swapping rootfs.img's and making things easy, plus I already had the rootfs ready for myself.. I figured why not.
But you're right, it would be helpful to know either way, so this is exactly what I did. I opened the init file within the rootfs.img (after mounting in Ubuntu) and searched for "read_ahead_kb" and found it. At the front of the line read: "echo 2048". That's the command that enables the 2,048KB SD cache during boot (the rest of the line I assume is to apply that setting to the SD card? Not sure..). I changed that value to 256KB, making that: "echo 256". Saved the file, unmounted the rootfs, and voila.
Click to expand...
Click to collapse
Should I use DroidExplorer after booting the phone and then should I be looking for a file simply called "init" with no extension - or how do I do it ? It's just that I now see that a new rootfs 20110724 has just been released and since I'm sure it won't be the last, I'd like to know how best to edit these myself
C
championc said:
Should I use DroidExplorer after booting the phone and then should I be looking for a file simply called "init" with no extension - or how do I do it ? It's just that I now see that a new rootfs 20110724 has just been released and since I'm sure it won't be the last, I'd like to know how best to edit these myself
C
Click to expand...
Click to collapse
Yes, the init file will be located in the "/" directory (where you find the /system and /data folders), and in that file, seach for "read_ahead_kb", and once you find that line, go to the bbeginning of that same line and change "echo 2048" to whichever value works best with your SD card.
Personally, I would use a program on the phone such as Root Explorer to modify the file, save, and reboot to have the effects instantly. That would simulate the same process I used to modify the rootfs in Ubuntu.
Sent from my MSM using XDA App
Gee, why all this complicated workaround for something easily done in one line inside froyo.user.conf...
echo "256" > /sys/devices/.....
-- Starfox
Starfox said:
Gee, why all this complicated workaround for something easily done in one line inside froyo.user.conf...
echo "256" > /sys/devices/.....
-- Starfox
Click to expand...
Click to collapse
Um, it's not anymore complicated... Although my wording might have made it seem that way. The only difference was mounting the rootfs.img and changing the value in the init instead of the froyo.user.conf.
maff1989 said:
Um, it's not anymore complicated... Although my wording might have made it seem that way. The only difference was mounting the rootfs.img and changing the value in the init instead of the froyo.user.conf.
Click to expand...
Click to collapse
Well... the user.conf method probably is easier, considering you won't have to change it with any rootfs updates - you can swap rootfs', so long as that entry is in the user.conf file it will always get reapplied.
arrrghhh said:
Well... the user.conf method probably is easier, considering you won't have to change it with any rootfs updates - you can swap rootfs', so long as that entry is in the user.conf file it will always get reapplied.
Click to expand...
Click to collapse
Yeah, that's true, since you put it that way lol. I was simply looking for the most direct way to apply the change, and the modding the rootfs seemed like the logical choice. Tbh I didn't know the user.conf was that significant.. besides applying some user-based settings and whatnot.
Boy I have a LOT to learn...
maff1989 said:
Yeah, that's true, since you put it that way lol. I was simply looking for the most direct way to apply the change, and the modding the rootfs seemed like the logical choice. Tbh I didn't know the user.conf was that significant.. besides applying some user-based settings and whatnot.
Boy I have a LOT to learn...
Click to expand...
Click to collapse
You and me both! I still have quite a bit to learn about how Android has been pieced together on our phones. Doesn't help that I don't really know jack about Android itself .
The user.conf file is quite powerful, assuming you don't need stuff applied too early in the boot process...
arrrghhh said:
You and me both! I still have quite a bit to learn about how Android has been pieced together on our phones. Doesn't help that I don't really know jack about Android itself .
The user.conf file is quite powerful, assuming you don't need stuff applied too early in the boot process...
Click to expand...
Click to collapse
For me, Android as an operating system is easy to understand, since it operates similarly to any computer system. But the fine details like how the rootfs, initrd.gz, kernel, and (most recently) the user.conf work puzzles me like no other. +1 for a Dev Learning Thread!
And yeah, the initrd.gz is what is loaded first, and to my knowledge it's that portion of the boot process that handles the Apps2Ext2/SD function... Fun little tidbit of info
You just need to study init (the file) to find out where everything is located, then adjust what you put into froyo.user.conf. Anything that is done before userinit.sh parses *.user.conf can be manipulated directly, anything after you need to get creative with sed or similar.
Initrd is the INITial Ram Disk. Basically, the kernel when loaded does not have enough to load the whole root/etc. so the initrd contains enough tools to get the kernel to recognize where the rootfs is and load it, then pivotroots with the real root then exec init.
App2sd has nothing to do with initrd. /sdcard/.android_secure, if you look in a real Android handset, is a world-unreadable/inaccessible directory. If you look closer, you notice it's been bind-mounted with those permission to "hide" the content. If you umount it, you have files named *.asec, which is a encrypted (to my knowledge) mini-fs containing the files for each program moved to SD. When Android boots it loopmounts each file to a dir in /mnt/asec or something. I don't think XDAndroid has the necessary stuff that goes through .android_secure yet.
-- Starfox
Starfox said:
You just need to study init (the file) to find out where everything is located, then adjust what you put into froyo.user.conf. Anything that is done before userinit.sh parses *.user.conf can be manipulated directly, anything after you need to get creative with sed or similar.
Initrd is the INITial Ram Disk. Basically, the kernel when loaded does not have enough to load the whole root/etc. so the initrd contains enough tools to get the kernel to recognize where the rootfs is and load it, then pivotroots with the real root then exec init.
App2sd has nothing to do with initrd. /sdcard/.android_secure, if you look in a real Android handset, is a world-unreadable/inaccessible directory. If you look closer, you notice it's been bind-mounted with those permission to "hide" the content. If you umount it, you have files named *.asec, which is a encrypted (to my knowledge) mini-fs containing the files for each program moved to SD. When Android boots it loopmounts each file to a dir in /mnt/asec or something. I don't think XDAndroid has the necessary stuff that goes through .android_secure yet.
-- Starfox
Click to expand...
Click to collapse
Thank you for the information, it's very enlightening
I mentioned Apps2SD because I owned an HD2 and was able to modify the initrd.gz to remove the Apps2SD functionality in a NAND Android ROM.. But thank you again for helping clarify any misunderstandings.
Also, if you have any links/bookmarks to online resources regarding these topics, I'd love for you to share cuz I'd hate to ask questions that could be answered with the right research. Plus, I'm sure you have better things to do with your time than to answer all the questions I have lol
Found this link here on XDA:
Increase Read Cache
I'm using SD Tools and SD Booster to change the cache and test the speed.
Got a class 6 card. Still playing around
großa said:
Found this link here on XDA:
Increase Read Cache
I'm using SD Tools and SD Booster to change the cache and test the speed.
Got a class 6 card. Still playing around
Click to expand...
Click to collapse
I have seen that link a while back; never could get that method to work, though I'm not saying that it doesn't.
From my experience, the difference between using SD Booster and applying the change to the rootfs/user.conf is that the read_ahead_kb, during boot, will impact the remainder of the boot process and furthermore, impact overall performance. That's why, for me, SD Booster simply wasn't cutting it. Although, it was VERY useful in helping me determine which value to place in the rootfs to get the best results.
I've been trying to find a more reliable objective benching tool since sdtools results seem almost random for me. That thread above suggests timing the opening of the gallery, but when I do, not all of the lag appears related to reading the contents of the card -- some of it seems tied up in animations. Anyone have any other ideas?
I actually might try overclocking temporarily if I can't find another card speed bench that less animated. I think the problem with me and sdtools is related to speedometer graphics. It hangs for 15-45 seconds at the beginning of the test while the needle makes its way painfully slowly to the first burst of speed read before continuing the test. Running multiple tests on 2048, 1024, 512 and 256 as set in sd booster, there was almost as much variation at each setting as there was between all the settings.