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.
Related
Hi all,
I've learned that the StarTrek is able to boot the current kernel from the Linwizard project without any modifications. I've posted a video of this at http://vimeo.com/2114567. Before you get too excited, however, there's a few things to keep in mind:
The buttons aren't mapped correctly by default.
You need a networked computer to log in and do anything fun, for now.
If you're wondering about Android, the answer is "not yet".
I will do my best to address the important things here; what works, what needs tweaks to work, and (most of all) what needs attention. I will also, over the next day or two, try to post my findings regarding the button GPIOs collected from HaRET, kernel modifications necessary to fix a few things. etc.
Consider this post a call for help. I'm hoping this will encourage others to contribute toward more complete linux support on the phone. I personally am driven by the opportunity to dual-boot Android on the device, but I have much to learn and can't do this alone. So, if you have kernel experience and a StarTrek, here's your motivation to get hacking! (If you'd like to help, but don't have a device to test kernels on, I'm often in #xda-devs.)
Status (Let me know if there's anything missing here.)
Internal LCD - YES - Seems to work great.
External LCD - ? - Shows the device's default image. Not sure how to control this in linux.
Backlight - ? - Unsure. As far as I can tell, Linux will retain the brightness level being used when HaRET finished loading the kernel.
USB Networking - YES - Works like a charm.
Audio - ? - No idea. I don't know how to test this.
Cellular - ? - No idea, but I don't think it will necessarily come easily.
Buttons/Keypad - SOME - By default, the keys and buttons are mapped either incorrectly or not at all. The phone keypad and some of the special buttons type random keystrokes, since we are using the mappings for the Wizard. I have a modified board-htcwizard.c with correct mappings for the StarTrek I'll post really soon, as well as a list of the GPIO readings for many of the buttons. Unfortunately, the Up/Down/Left/Right/Select/End buttons function differently than the other, matrix-based keys. I have yet to discover how to configure them.
Camera - ? - No idea, but they don't even have this working on the Wizard (Linwizard's primary target device).
Light Sensor - ? - I wouldn't know where to begin. It barely works in WM, anyway.
MicroSD - YES - I can mount the MicroSD with no issues, full read/write. Even managed to open my photos in the GPE photo gallery on the device (launched over telnet).
X[\B] - YES - I am able to start X, by calling startx over the telnet connection. However, X will try to run a touch screen calibration before doing anything else, and this is a bit of a problem for us! Fortunately, on newer Linwizard versions, you can disable this by passing tslib=0 to the kernel (in the defaults.txt file you give to HaRET). GPE also seems to be running perfectly after X starts.
Problems - After a few idle minutes in linux, the screen likes to black itself out automatically, as per the design of Linwizard. Unfortunately, on the Star Trek, there seems to be no way to make the screen wake up. Telnet still works in this situation.
I promise to keep this post updated, and get my data together and uploaded soon. Please share your own results and tricks as they come along, and join me (and some talented people) in #xda-xevs and #htc-linux on irc.freenode.net. Happy hacking!
Attached:
arch/arm/mach-omap1/board-htcwizard.c - Contains key matrix mappings modified for StarTrek. Be sure to remove the ".txt" from the file extension before using.
default.txt - Used with HaRET to make Linux boot. The only thing unusual in here is the TSLIB=0 option that's passed to the kernel, telling linux to skip touchscreen-related tasks.
great work! but you need some advanced startrek owners to test linux - that's a big problem
Fantastic news! I' would really try it out. Unfortunatly my startrek's connector is damaged. I can charge the device, but I cannot connect with the pc. If I can use the micro sd card to install it(I think is possible) I will try it.
Thanks for the great job.
dancer_69 said:
Fantastic news! I' would really try it out. Unfortunatly my startrek's connector is damaged. I can charge the device, but I cannot connect with the pc. If I can use the micro sd card to install it(I think is possible) I will try it.
Thanks for the great job.
Click to expand...
Click to collapse
You can, by dropping Haret+default.txt+zImage+initrd onto the SD card. Unfortunately, without a USB connection, you won't be able to telnet into the device and run commands.
very interesting! Ive been waiting to hear this kind of news Unfortunately, I still use my StarTrek as my primary phone, so I can't test it out until it moves along a little further. I'll be sure to keep an eye on this thread, as this is good news!
gigawatts said:
very interesting! Ive been waiting to hear this kind of news Unfortunately, I still use my StarTrek as my primary phone, so I can't test it out until it moves along a little further. I'll be sure to keep an eye on this thread, as this is good news!
Click to expand...
Click to collapse
Linux actually boots directly from a Windows Mobile program called HaRET; When you're done playing with Linux, you can just reset the phone and you're back to normal. No permanent changes.
awesome! I'll give it a go right now, thanks!
BHSPitMonkey said:
You can, by dropping Haret+default.txt+zImage+initrd onto the SD card. Unfortunately, without a USB connection, you won't be able to telnet into the device and run commands.
Click to expand...
Click to collapse
I already did it, and works. Thanks anyway.
Why not combine the effort to get Android on it?
Kwen said:
Why not combine the effort to get Android on it?
Click to expand...
Click to collapse
Are you volunteering your expertise on the subject?
The point of this post was to accomplish just that: to attract the interest of more people who can contribute. I'm in the process of setting up a repository of changes right now, so the patches I've made so far are kind of scattered about my hard drive for the moment. If you're interested, you can try catch me in #htc-linux or #xda-devs on irc.freenode.com. Otherwise, I'm trying to keep the post at the top of this thread up-to-date.
Unfortunatly Android cant work, it needs 128 ram.
http://source.android.com/release-features
BHSPitMonkey said:
Cellular - ? - No idea, but I don't think it will necessarily come easily.
Click to expand...
Click to collapse
from linwizard wiki page :
What we need
Right now we need people with experience with GSM and WiFI to help get linwizard connectivity up!
Click to expand...
Click to collapse
about two years ago , another linux project ran that called Xanadux. why you don't use from Xanadux ?
sorry for my english !
I have linux booting
it up booting to the point correctly then sit conclusion cannot one yet start?
sorry for my bad english my german are better
Oh.......I think HTC Phone can do that ADIDAS ' AD "impossible is nothing"
Been a few months since ive been on the scene, any news here? My Cingular 3125 is nearing the end of its life, and I figured I can play a bit more with it
P.S. Whats new BHSP?
autologin on linwizard
hi
http://wlcrck.wl.funpic.org/wlcrck-elf-linux/autologin
to solve the problem i develop a simple aplication to automatic login but dont have any security autologin in root mode
to use this have to make a couple of things
you need decompress the inirtd and add this app to /bin and set suid and modify
/etc/inittab file and compress the initrd again.
change this line
tty1::respawn:/sbin/getty 38400 tty1
for
tty1::respawn:/sbin/getty -l /bin/autlogin 38400 tty1
sorry for my english
thanks for the code of htc board
First of all I have to thank the CM people, especially mbm, nemith, fattire and cvpcs for their work on gingerbread which helped me a lot in understanding where to look and what to patch.
The whole thing is based on the honeycomb preview emulator images, some of the B&N modules+driver, pieces from the upcoming CM7 and manual patching ARM assembler in libraries, writing ugly scripts to hack around various issues, a lot of time and many brain cells.
Use this on your own risk. I'm not responsible for any damages. This is not meant as a primetime ready rom. This is a preview after all.
The unzipped image is around 3.5gb and fits on 4GB SD cards.
MD5 (nookhoney04.img.zip) = 27396e63396a59a25f5d6fdbe0341276
http://www.rbrune.de/nookhoney04.img.zip.torrent
http://www.rbrune.de/nookhoney04.img.zip
Changelog
v04 - 02/07/2011
increased touchscreen sensitivity and made touchscreen more usable close to the borders (kernel change)
fixed heap size issue to get much more programs running (e.g. nook app, kindle app, etc.)
v03 - 02/05/2011
fixed screen turning animations and previews in taskswitcher
sd card access and secure storage support
turned off the debug screen flashes and vibrator
added display timings
sd card image now usable on 4gb cards
changed to a self compiled kernel to make these things work
reduced compressed image size
v02 - 02/02/2011
sound support
patched in some graphics improvements. Can play non-hd videos from m.youtube.com
sdcard storage
v01 - 02/01/2011
initial release
Status
What works:
Graphics acceleration
Accelerometer
Wireless!
Touchscreen
Buttons
Sleep/Wakeup
Sound
Known issues:
The accelerometer behaves funky. Will try to fix this.
The Gallery app crashes when opening an image. Not my fault, it's broken in the emulator from google too.
Doesn't work:
DSP e.g. no hardware video decoding (and will possibly never work before the AOSP release)
FAQ
Q: Why?
A: I thought it would be fun. It was and still is. And now developers have an actual device to test their apps on instead of relying on the slow emulator.
Q: How?
A: I'm planning to write a blog post. Mostly learning how Android works, debugging, patching, reusing binaries from different sources, finding easy ways to reach a goal, try and error, a lot of brain power.
Q: During boot I get stuck at the Android screen with the blinking cursor.
A: It seems to be a timing issue with mounting the partitions. Sometimes rebooting helps to get it booting. If not a different SD card might to the trick.
Q: Why is there no Market app installed?
A: There's no legal way to distribute the google apps with a ROM.
Q: Angry Birds, Nook reader, Kindle app?
A: Yes.
Q: I want to port Honeycomb to device xyz... send me the instructions how to do that now!
A: I like the 'I' in that sentence - but there are no instructions, no source, no nothing. Learn and read about Android, Android porting, making custom roms, embedded systems, ARM assembly, driver programming, programming in general, the Linux Kernel and much more - and when you're comfortable and have experience with all of that come back and do your port.
Q: Can you port Honeycomb to device xyz?
A: I don't have xyz. And even if device xyz would magically appear at my front door doesn't necessarily mean I'll have the time and motivation to port anything to it.
Q: I want to use a different kernel what changes did you make in the kernel?
A: https://github.com/rbrune/nook_kernel
Q: Where can I donate?
A: I don't want any money. If you want to put your money to good use donate to a humanitarian organization and/or the EFF.
--
Rafael Brune
awesome, time to mess around with this.
Amazing work. I'm always impressed when people get an SDK image booting on a device and working properly, but this isn't even technically a tablet! It's an e-reader that was hacked. Unreal.
Keep up the good work.
deeper-blue said:
I decided to release what I have so far. May everybody have some fun with it.
But first of all I have to thank the CM people, especially mbm, nemith, fattire and cvpcs for their work on gingerbread which helped me a lot in understanding where to look and what to patch.
What works:
-Graphics acceleration
-Accelerometer
-Wireless!
-Touchscreen
-Buttons
-Sleep/Wakeup stuff
Doesn't work:
-Sound (sadly! Despite my efforts the last hours I didn't get it working properly yet)
-DSP e.g. no hardware video decoding
The whole thing is based on the honeycomb emulator images, the B&N V1.1 kernel+modules+driver, pieces from the upcoming CM7 and manual patching ARM assembler in libraries and writing ugly scripts to hack around various issues.
Use this on your own risk! I'm not responsible for any damages!
The unzipped image is around 4gb. I use it on a 8gb sd-card. In principle the image should work on a 4gb card.
http://www.rbrune.de/nookhoney01.img.zip
--
Rafael Brune
Click to expand...
Click to collapse
Dude, you are awesome!
in b4 thread explodes
great work, its running pretty nice
I'm going to buy an 8GB card on payday. My 2GB isn't enough for this, but that's amazing. Will definitely be using a lot. Thanks a ton for all of your hard work! Expect donations.
Looks like you're gonna make the front page of engadget and the other sites again
Heres a Mirror to v04:
http://android.stolenrobot.com/NookColor/Honeycomb/nookhoney04.img.zip
Here are some basic instructions on how to flash it:
Windows Instructions
Download Win32DiskImager.exe
Download the file in the first post and extract the img from the zip
Run Win32DiskImager and make sure you pick the drive letter corresponding to your MicroSD card
Click the Folder icon and locate the img file you extracted earlier
Click on Write and then wait...
Once its done remove the SD card from your computer
Power off your nook color and insert the MicroSD you just prepared
Power On your Nook Color and wait for it to load
Welcome to Honeycomb!
This makes you wanna buy a nook! GJ!
Robotic Clone said:
Looks like you're gonna make the front page of engadget and the other sites again
Click to expand...
Click to collapse
He already made it here: http://www.androidcentral.com/honeycomb-nook-now-available
cloud79 said:
This makes you wanna buy a nook! GJ!
Click to expand...
Click to collapse
nooo...
This makes you wanna buy a nook...
just a quick question, does anyone know if this does fit a 4gb micro sd?
its all i have on me at the moment.
urbanengine1 said:
nooo...
This makes you wanna buy a nook...
just a quick question, does anyone know if this does fit a 4gb micro sd?
its all i have on me at the moment.
Click to expand...
Click to collapse
It doest, 4gb img, formatted 4gb cards really 3.69gb, installing
Linux now just so I don't need to wait
Sent from a NC on [email protected] using tapatalk pr0z
Wow this is just incredible, downloading it right now. - Thanks
Who would of ever thought that a book store would be the one to release the goto android tablet?
what linux users do? to use it? just like booting other OS?
thanks
10 characters
Damn it. I only got a 2gb card
Nook Color via Xda App
can this be chopped up and used on the htc hd2
Thanks for this bro.
10076757 said:
can this be chopped up and used on the htc hd2
Click to expand...
Click to collapse
right now that seems a bit (quite a bit) pre-mature, also honeycomb is definately destined for tablets (atleast the pre-release is) so even if you could it seems that it wouldnt run (see http://phandroid.com/2011/01/28/and...ator-shows-signs-of-smartphone-compatibility/ for more info)
Dude you are so the man going to try this first thing in the morning. Words really don't express our appreciation for you.
mckooter said:
right now that seems a bit (quite a bit) pre-mature, also honeycomb is definately destined for tablets (atleast the pre-release is) so even if you could it seems that it wouldnt run (see http://phandroid.com/2011/01/28/and...ator-shows-signs-of-smartphone-compatibility/ for more info)
Click to expand...
Click to collapse
If you take a look in the settings there are a lot of references to phone features but yes I do agree this is will more than likely start out on tablets and large screen phones
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
Based on this thread:
http://forum.xda-developers.com/showthread.php?t=1595531
and this one:
http://forum.xda-developers.com/showthread.php?t=903507
After quite some reading and messing about it worked...
I have patched sqlite3.c from CM9 ICS source and recompiled CM9 (for nexus, the tutorial used that one... but files seem interchangable).
!!!WARNING!!!
!!!Use this at your own risk! I will not be responsible for any messed up primes, errors and/or loss of data!!!
This can mess up your prime! Only do this if you have a working CWM backup and can restore that backup from recovery! Root is required at this time to replace the files...
I have no idea what this does with data integrity, if you value your data extremely it might be wise not to try this!
!!!WARNING!!!
*RISK*
As explained by Hobbesian in this post: http://forum.xda-developers.com/showpost.php?p=27121811&postcount=39
Fsync off means that SQLite is unbound by the need to check that data has been written to disk successfully, it also means the operating system can freely re-order the writes before they are comitted to flash memory, which in the event of a hardlock will very likely result in database corruption, of the unrecoverable sort.
Fsync in itself is often used -deliberately- to incur an I/O buffer, so whilst it might seem like a great idea to turn it off, what you're essentially doing is risking the CPU going faster than the device controller can write to memory. This is bad. I cannot begin to imagine how many klaxons would go off if you're working on something remotely important and use this patch.
*RISK*
I hereby attach the zip containing the libsqlite.so and libsqlite_jni.so.
1. Copy the files (using root explorer for example) to the /system/lib folder, replacing the original files. (Mount that folder as RW if necessary).
2. Set permissions to the same as the other files, rw-r--r--.
3. Reboot.
If something went wrong your prime will not boot but will be stuck at the booting screen, in that case recover to a working backup using CWM.
SQLite benchmark went from 100+ secs to 20-25 seconds. Quadrant IO bench improved as well.
Have yet to decide on realtime performance but I actually believe the internal memory is pretty mediocre, physically... So this only helps partially in that case.
It's fun to play with sync settings but not if you value your data. I would strongly advise against it except for testing and benchmark purposes...
Thanks, but Iḿ awarre of possible consequences... But I believe the conclusion in earlier versions was that, even though there are indeed risks, they aren't as huge as you'd might expect. Mainly with unexpected reboots or shutting down the risk is big(ger).
But even if itś just for testing/benching... I would still very much like to see the results.
Btw, it should be ARM v7 even... that is the proper instruction set. Updated starting post.
Ugh, got it to build for arm-v7a but of course it looks (completely) different from the module with the prime. Structure the same, but compiled different enough. So thought I'd compule the library and install it on the prime but that resulted in the prime not booting...
Hmmm
I'd love to help, but I have zero knowledge in anything SQLite...
I wish you good luck!
I think everyone is hoping that the slow random write speeds are purely software related. And it makes sense that they are. The SQLite benchmarking thread is giving a lot of details on what is making our performance so sluggish, but not why.
Next step, compile complete CM9 source (hopefully including libsql src ) so I can use that as a base...
Copying the libsqlite.so and libsqlite-jni.so from an AOKP rom worked fine, so perhaps this is a (not the easiest) way to get things to work.
And ah well, otherwise I learnt how to compile a rom
xTRICKYxx said:
I'd love to help, but I have zero knowledge in anything SQLite...
I wish you good luck!
I think everyone is hoping that the slow random write speeds are purely software related. And it makes sense that they are. The SQLite benchmarking thread is giving a lot of details on what is making our performance so sluggish, but not why.
Click to expand...
Click to collapse
Same here, thanks for taking time out to tinker with our primes...........hmm, im not intirelly sure if i should refrase that???
GD LUCK
dagrim1 said:
Next step, compile complete CM9 source (hopefully including libsql src ) so I can use that as a base...
Copying the libsqlite.so and libsqlite-jni.so from an AOKP rom worked fine, so perhaps this is a (not the easiest) way to get things to work.
And ah well, otherwise I learnt how to compile a rom
Click to expand...
Click to collapse
Are you actually changing rom code to remove fsync?
hairdewx said:
Are you actually changing rom code to remove fsync?
Click to expand...
Click to collapse
Ehm, basically... Not rom code itself but one of the libraries in the rom (for which I hope the code is in there as well).
Background info:
http://forum.xda-developers.com/showthread.php?t=1000899
Android phones as the underlying database using sqlite3. sqlite3 writes efficiency is very low, because the sync feature turned on by default, and fsync() must be performed after each insertion, the resulting system efficiency is low, and the disk life is reduced.
I try to disable sync feature by default in exchange for greater IO performance and reduce disk consumption. While doing so may result in data integrity problems, but I still like to use it because most of the sqlite insert action can be completed within a few seconds, not too much to consider issues such as sudden power-down.
After modified, the time of insert 2000 records to sqlite3 db, from 1m11s reduce to 2s.
-----------------------------
With Android applications, the database operation is non-persistent, normal step in app is:
1.open db
2.do read/write
3.close db
with step3, the data in cache will be flush to disk. so user will not notice any sudden lag, always smooth.
With SYNC-ON, the db operation like this:
1.open db
2.1. write a record/do a transcation
2.2. fsync()
2.3. write a record/do a transcation
2.4. fsync()
.....
3.close db/fsync()
with SYNC-OFF, operation like this:
1.open db
2.1 write a record/do a transcation
2.2 write a record/do a transcation
....
3. close db/fsync()
So, no-sync can significantly save IO time.
Click to expand...
Click to collapse
Patch for libsqlite.c:
http://forum.xda-developers.com/showpost.php?p=12695464&postcount=1966
Code:
diff -urNp external/sqlite/dist.origin//sqlite3.c external/sqlite/dist//sqlite3.c
--- external/sqlite/dist.origin//sqlite3.c 2011-01-07 15:26:32.000000000 +0800
+++ external/sqlite/dist//sqlite3.c 2011-01-07 15:27:55.000000000 +0800
@@ -34761,7 +34761,7 @@ SQLITE_PRIVATE int sqlite3PagerOpen(
pPager->readOnly = (u8)readOnly;
/* pPager->needSync = 0; */
assert( useJournal || pPager->tempFile );
- pPager->noSync = pPager->tempFile;
+ pPager->noSync = 1;
pPager->fullSync = pPager->noSync ?0:1;
pPager->sync_flags = SQLITE_SYNC_NORMAL;
/* pPager->pFirst = 0; */
@@ -65838,7 +65838,7 @@ static void attachFunc(
sqlite3PagerLockingMode(pPager, db->dfltLockMode);
sqlite3PagerJournalMode(pPager, db->dfltJournalMode);
}
- aNew->safety_level = 3;
+ aNew->safety_level = 1;
aNew->zName = sqlite3DbStrDup(db, zName);
if( rc==SQLITE_OK && aNew->zName==0 ){
rc = SQLITE_NOMEM;
@@ -97124,7 +97124,7 @@ static int openDatabase(
** database it is 'NONE'. This matches the pager layer defaults.
*/
db->aDb[0].zName = "main";
- db->aDb[0].safety_level = 3;
+ db->aDb[0].safety_level = 1;
db->aDb[1].zName = "temp";
db->aDb[1].safety_level = 1;
So the basic idea is to limit IO-interaction by disabling fsync.
Interesting, I figured it would have been in one of the kernel modules.
Ok, I have been able to compile the CM9 source (for the galaxy nexus, because the tutorial was for that one) including the sqlite source...
First test was now 36,6 secs which is pretty nice, have to check for other issues (and will compile for TF201 if I can soon). The semi patch caused a number of force closes so we'll have to see how this one goes.
But at least happy I was able to compile
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Code:
Device: Transformer Prime(TF201)
ROM: AOKP B38
Kernel: Motleys running at 1.8 set to performance governer for testing
Tests: ( All tests done Run 1 after fresh boot, Run 2 immediatly after, all set to performance governer )
Couldn't get the damn formating to look right in the post ... check the image for results.
RubenRybnik said:
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Code:
Device: Transformer Prime(TF201)
ROM: AOKP B38
Kernel: Motleys running at 1.8 set to performance governer for testing
Tests: ( All tests done Run 1 after fresh boot, Run 2 immediatly after, all set to performance governer )
Couldn't get the damn formating to look right in the post ... check the image for results.
Click to expand...
Click to collapse
What about actual use performance? Is web browsing lag gone? What about switching apps?
I'm a little hesitant about the data stability... with my luck I'll have rock solid stability until the ONE TIME I actually need it and lose important data
Updated main post...
This should be in dev section?
Looks promising, thanks OP.
Sounds very promising. Rooted people, start testing!
sweet. going to try it tonight!
---------- Post added at 01:33 PM ---------- Previous post was at 01:13 PM ----------
RubenRybnik said:
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Click to expand...
Click to collapse
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Tempie007 said:
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Click to expand...
Click to collapse
Posted this in the TFP's AOKP thread in that 'other' forum:
I'm seeing some great results personally. Chrome on prime seems really responsive, apps launch pretty much instantly, haven't seen a desktop redraw on Nova the whole time. I have an image folder with about 300 wallpaper images, opening that in quickpic in the past has been pretty slow( several seconds ), now that is almost instantly done, all thumbnails before I blink lol.
Now I'm not saying this is all the sql patch I did at all, unfortunately I didn't put much time into using Montleys new kernel in a 'real world' case, I only benchmarked with his kernel then applied sql patch and benchemarked again( still using his kernel ). So perhaps I'll flash back tonight just to see if I can gauge how much the patch vs kernel is doing.( Thanks again Motley! ).
As for side effects, I installed Chrome last night so I could test, had about a 2 second freeze at the end of it installing, but came back and was fine after. Haven't seen any other freezes. I did 'loose' wifi for about 20 min last night. I was connected to the wifi the entire time, but even a reboot and net wouldn't work on the Prime, not sure what happened, or if it's related, but seemed to have 'fixed' itself after 20 min last night.
Click to expand...
Click to collapse
Tempie007 said:
sweet. going to try it tonight!
---------- Post added at 01:33 PM ---------- Previous post was at 01:13 PM ----------
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Click to expand...
Click to collapse
If it is, it is not done in the library itself...
I also tried the libsqlite files from the SGS3 for example and copied them to the prime, but that didn't help much... So if fsync is handled differently on those devices it is done in a different place.
This is just a workaround for (part of) the problem... The real issue is elsewhere. I mean, the CM9/AOKP/AOSP roms use the same source for the differnt devices yet the issues are not the same on all of them.
So somewhere in the kernel code? Or another level, the controller for example. As the HTC One X performs decent it seems that it's not (JUST) the tegra3 but some of the other components.
Ah well, maybe tonight I can try the full wipe and reinstall and see if that helps anything.
Booting time doesn;t improve with this mod, titanium restores improve a bit but nothing extreme (20-25% faster is my guess) so there IS more going on. My guess is the used memory is at least part of the problem.
Some SD benchmarking indicating the memory used isn't the best one :/ (Done with the 'Device Performance' benchmarking app)
Asus TF201:
[email protected]/mnt/sdcard (=internal)
Max Write: 14,4
Mean Write: 12,1
Min Write: 9,4
Max Read: 28,8
Mean Read: 23,2
Min Read: 14,9
[email protected]/Removable/MicroSd (=external)
Max Write: 14,7
Mean Write: 11,4
Min Write: 9,9
Max Read: 14,6
Mean Read: 12,7
Min Read: 9,0
SGS3:
[email protected]/mnt/sdcard (=internal)
Max Write: 26,7
Mean Write: 25,3
Min Write: 23,9
Max Read: 43,8
Mean Read: 42,2
Min Read: 39,4
[email protected]/mnt/extSdCard (=external)
Max Write: 10,6
Mean Write: 10,0
Min Write: 9,6
Max Read: 13,8
Mean Read: 10,6
Min Read: 6,2
Is it possible to make an intelligent fsync where it basically syncs after some clock time after the last db write or inserts an fsync with a high count of writes?
I've noticed a lot of similar questions around these forums, so I decided to collect some in the same place. This is by no means an exhaustive list.
I can haz root/S-OFF?
There are options for unlocking your bootloader by changing your SuperCID, also there are options for obtaining S-OFF.
Thanks to Team Fireballas for the root method, and thanks to unlimited.io for S-OFF.
Now, please, don't talk like that anymore. Proper grammar, spelling, and punctuation help us understand the question or point you're trying to get across.
My FriendStream (or another HTC) app is missing
HTC decided to remove the FriendStream widget from view in an attempt to de-bloat Sense. On the stock ROM, you can still access it via the lockscreen and somewhat through the Social Clock.
Lockscreen: Settings -> Personalize -> Lock Screen Style -> Friend Stream
Social Clock: Widgets -> Clock -> Social Clock
On the stock ROM, there are several HTC apps missing from our phone, including the beloved flashlight. However, not all the apps are truly missing, just hidden. If you have root, you can re-enable it in the default.xml file located in the /system/customize/MNS/ folder. Remove the listing for FriendStream or whatever app you want to view in the app drawer from the "application_hide" function. FriendStream might also require the listing under "shortcut_hide" to be removed, as well. If you are rooted, a custom ROM may not have this problem.
Why do I have this annoying Wi-Fi icon?
For whatever reason, HTC or Verizon decided to add an annoying Wi-Fi nag icon in the notification bar telling you that you should turn on Wi-Fi. Why Verizon wouldn't want you to go over your data limit and owe them more money is beyond me. If you have root, there is a pretty simple fix for this, or try a custom ROM.
Can I use 64GB MicroSD cards?:
Our phone lists 32GB as the largest capacity microSD card it is capable of utilizing. However, that is the largest capacity allowed by the SD 2.0 standard, SDHC. SD 3.0 currently allows 64GB SDXC cards to be backwards compatible with SD 2.0 ports. Since every single 64GB card isn't necessarily going to work, it's best to read around and find the specific models which do.
Why do the official specs say our phone has 8GB of internal storage but I have less?:
Due to the controversial naming scheme of hard drives and other forms of data storage, companies actually give you less storage than you anticipated. 'Giga' is an SI decimal prefix meaning 10^9, or 1 billion bytes. Before hard drive capacities were in the gigabytes, hard drives used the IEC binary capacity for megabytes (2^20), albeit with the SI prefix. RAM is still calculated with the IEC value but with the SI prefix. So, when your internal storage is calculated to be 8GB, it's actually 8 x 10^9 rather than 8 x 2^30. Since Microsoft has been around since the other standard was set, Windows still displays storage capacity in the binary fashion and labels it with the decimal format.
On top of that, the Android system takes up a sizable amount of storage space, which is included in our phone's internal storage capacity, so you're only allowed 4.15GiB of data storage, which is 4.457GB. In short, you've got 8 billion bytes, but only 4.457 billion bytes usable, which is 4.15GiB. A similar capacity change will be noticed on your MicroSD card size. For example, I have a 32GB MicroSD card, which is actually 29.7GiB. I have a 2TB hard drive, but I only have 1.818TiB available. That's almost 200GiB "missing" because of the naming scheme.
What's the deal with the SD card naming scheme?:
Android 4.0 introduced a new way that SD cards are handled by the system. Previously, the eMMC internal storage of the phone was in the '/emmc/' folder, and the SD card was '/sdcard/'. Makes perfect sense, right? Way to screw it up, Google. Now, the internal storage is in the '/sdcard/' folder, and the real SD card is '/sdcard2/'. There's nothing you can do about this without serious modding to the system. It was changed because Google considers our phones to be high capacity now, so the need for microSD has passed. Yes, portable storage isn't necessary. If you have root, there's a mod that can switch it for you.
Can I install apps to the SD Card?:
Unfortunately, if you are unrooted and on the stock ROM, as per the SD card naming scheme change mentioned immediately above, apps can no longer be installed to the SD card. Like I mentioned above, if you have root, there's a mod for that. Otherwise, when saved in the 'Internal storage', apps are saved in the normal location of apps, '/data/app/'. When saved in the 'Phone storage', apps are saved in the eMMC internal storage partition '/sdcard/.android_secure/' as a '.asec' file.
Can I use Google Wallet?:
If you are rooted, then there's an experimental method that may let you successfully run Google Wallet.
Is our phone capable of being used globally?:
The latest 2.17.605.2 update enabled global phone on our phone. Go to Settings -> Call, and change Preferred Network to Global.
These have been the most common questions I have seen, and I'll be updating this list with more pertinent information when it arises. There are plenty of other questions that have been answered, even more which haven't. Look around for questions, and if there isn't an answer, don't be afraid to ask.
FYI the debugfs root method doesn't look to be working... not sure if you saw that in the other thread or not.
Had to throw up a pic...64GB....the only way to go
Card is a Sandisk 64GB micro.
Is there a patch available for that Wifi thing? I don't have much of a problem doing it manually through the APK, but if there's a faster way...
Platypus222 said:
Is there a patch available for that Wifi thing? I don't have much of a problem doing it manually through the APK, but if there's a faster way...
Click to expand...
Click to collapse
Hey self, nevermind. If anyone else wants to just copy over the APK that you need to modify, just do what I said here -- http://forum.xda-developers.com/showpost.php?p=30679535&postcount=40. You will need root, though, and I understand a lot of people don't. All it is is removing a few images that for some reason stops the notifications as well.
Platypus222 said:
Hey self, nevermind. If anyone else wants to just copy over the APK that you need to modify, just do what I said here -- http://forum.xda-developers.com/showpost.php?p=30679535&postcount=40. You will need root, though, and I understand a lot of people don't. All it is is removing a few images that for some reason stops the notifications as well.
Click to expand...
Click to collapse
lol. I appreciate you making it readily available for us, but most of us don't have root. Here's to hoping our spamming Verizon works quickly!
I added to and updated a few things on the list. Hopefully people will read it before asking the same things over and over.
IceDragon59 said:
Hopefully people will read it before asking the same things over and over.
Click to expand...
Click to collapse
Ha ha. You funny guy...
Jafmf95 said:
Ha ha. You funny guy...
Click to expand...
Click to collapse
I know. The likelihood of that, right?
Bump
Please add the DirtyRacun s-off method.
I'm sure there's other stuff, too. Lots had happened since we received s-off.
Thanks
Sent from my Fireball using Xparent Blue Tapatalk 2
+1 sticky plz
IceDragon59, you've done a nice job with the FAQ, I wonder if you might also consider taking on the task of making an index post for ROMs, recoveries, unlock methods, scripts, themes, etc?
Oh, and it looks like you can remove the please sticky notice from the title.
mdmower said:
IceDragon59, you've done a nice job with the FAQ, I wonder if you might also consider taking on the task of making an index post for ROMs, recoveries, unlock methods, scripts, themes, etc?
Oh, and it looks like you can remove the please sticky notice from the title.
Click to expand...
Click to collapse
That's not a bad idea. I'll make it my weekend project. And thanks for pointing out the fact that this thread finally got stickied after 5 months.
FYI, the direct link in the OP to the post with the .apk for killing the wifi nag is outdated. It takes you to post #40 in that thread, but that .apk may actually botch things up for folks running the latest stock Sense. There is a post a few posts later with an updated .apk to match the more recent Sense.
Question
Is this an hpdi/mdpi device? sorry for being ignorant...
Thanks in advanced to whoever can answer this!
mr_dr_parker said:
Is this an hpdi/mdpi device? sorry for being ignorant...
Thanks in advanced to whoever can answer this!
Click to expand...
Click to collapse
hdpi
Thanks!
jose51197 said:
hdpi
Click to expand...
Click to collapse
Thanks!
My incredible dont work with samsung USB cable (I hawe 2), but works with LG G2 USB. why is that?
kobebryant said:
My incredible dont work with samsung USB cable (I hawe 2), but works with LG G2 USB. why is that?
Click to expand...
Click to collapse
Strange, my works with Samsung cable good, same like on original htc usb