I'm new to whole linux\android stuff. Didn't really used lunux, so my knowledge of shell scripting is around 0.
Anyway the stalling issue of galaxy is quit annoying. Fortunately Paul at Modaco has found a fix for that (beleve he had also had script for that to). http://android.modaco.com/content/s...298/got-the-stalling-problem-rooted-try-this/
The faster section\mount of the memory where the apps data should be copied is not so large, so you shouldn't place games or apps that use a lot of space. So you want only copy only a specific set of data.
I managed to create a shell script that will seek unlinked apps data directories in /data/data/ move them to faster storage partition /dbdata/data/ and link it back in /data/data. The apps directories that are exists in a ignore_list.txt will be skipped and not moved to /dbdata/.
!!! Be aware, use it at own risk !!!
Requirements:
Rooted SGS
ADB or terminal on SGS
SU
Busybox
how to:
1. download app_data_hack01.zip
2. copy context of app_data_hack01.zip to /sdcard/sd/Scripts
Remove or add directories that should remain in /data/data using in ignore_list.txt file
Execute using adb:
Code:
adb shell
su
sh /sdcard/sd/scripts/app_data_hack.sh
Using terminal on SGS
Code:
su
sh /sdcard/sd/scripts/app_data_hack.sh
in the terminal: "To proceed type [yes]:" type "yes" or "y" (without the quotes) to proceed..
To recover (move from /dbdata/data back to /data/data) use
Code:
su
sh /sdcard/sd/scripts/app_data_hack_recover.sh
Any feedback is welcome!!
tried it on XXJG3
systems runs much faster now with tons of applications installed
great work and nice instructions
Agree GREAT work, thanks
If I install new apps, they will be stored in the original /data/data right? And if I wanted to move them to /dbdata/data I just add them to the text file and run the script again?
psychedelic'd said:
If I install new apps, they will be stored in the original /data/data right? And if I wanted to move them to /dbdata/data I just add them to the text file and run the script again?
Click to expand...
Click to collapse
You can just run the sript again. You add to ignore text file directories that shouldn't be copied.
It would be great if everyone will post the directory names of apps that shouldn't be stored in /dbdata/ (apps that occupied a lot of space or somithing...)
wow this is good. much more friendly for newbies and linux illiterates like me than those bits and pieces found at modaco.
cheers!
Development
Often we have people post rubbish in the development section because the simply carnt be bothered to go to where their information belongs, e.g. Q&A... however in this case i think a very fine peice of developing has been done and would be seen my many more if used to the development section. Therefore i am asking if a mod could please move this thread, and also well done
Just a thought BTW, instead of everyone messing with this dbdata partition, why done we just increase the size of the partition so we done have to SQUEEZE our big apps in a very small space? Seems much more simple...?
sunwee said:
wow this is good. much more friendly for newbies and linux illiterates like me than those bits and pieces found at modaco.
cheers!
Click to expand...
Click to collapse
Glad it helped and found easy to use!
bratfink said:
Often we have people post rubbish in the development section because the simply carnt be bothered to go to where their information belongs, e.g. Q&A... however in this case i think a very fine peice of developing has been done and would be seen my many more if used to the development section. Therefore i am asking if a mod could please move this thread, and also well done
Just a thought BTW, instead of everyone messing with this dbdata partition, why done we just increase the size of the partition so we done have to SQUEEZE our big apps in a very small space? Seems much more simple...?
Click to expand...
Click to collapse
I wasn't sure where to post as it's not really an development of something new but only a tweak of existing...
As for increasing the partition size, it would be indeed great, but how and if it's possible? Could it be done PIT file using Odin 3?
Yes
Yes from what i know the PIT file contains the partition structure so if this file can be adapted to create a larger /dbdata partition then this should in theory be possible.
bratfink said:
Yes from what i know the PIT file contains the partition structure so if this file can be adapted to create a larger /dbdata partition then this should in theory be possible.
Click to expand...
Click to collapse
That's interesting, but kind off-topic.. Odin seems to be able to interpret pit files, so on web should also be more info available...
Related
After doing the boot_animation and the boot_sound trick (changing them), I got curious to see what else I can do. However, I'm pretty new to Android.
But I'm pretty familiar using ADB and learn new things very quick. So I'm hoping to learn a lot more.
Who knows, maybe one day I'll be making my own Roms and taking peoples requests. =D
Any help folks?
Anything is much obliged.
Do you mean /data/
You can su, cd /data/ , then ls for contents
elegantai said:
Do you mean /data/
You can su, cd /data/ , then ls for contents
Click to expand...
Click to collapse
Yes.
That's exactly what I was talking about.
Thank you bud.
If I have any more questions, may I PM you?
sure, or just post here But I make no promises of what help I can be. I have only been exploring this stuff for a month now, and just started 'cooking' and messing with the kernel
Get "root explorer" from market. Browse on the go.
Ok. For sometime i was trying to do things like copy/paste/delete to the system folders.
Im aware of what im doing. I shouldn't delete the original contents of /system partition unless im experimenting with it.
OK. My problem is , I WANTED TO DELETE AN ENTIRE FOLDER AT A TIME INSIDE THE /SYSTEM PARTITION THROUGH ADB. Donot recommend root explorer because while experimenting it is useless when the device won't boot. Even though I can mount the /system through recovery and play with adb. But what all i want is deleting the entire folder (with its contents) at a time. Just because it takes lot time to delete each and every file inside it.
I tried the shell "rm" command but it works only for individual files. So, pls help. Much appreciated and thanks in advance.
I've been looking at the root folder using Astro and there are several files/folders. Can any be deleted, without causing any problem? I'm running out of space and am hoping some are just temporary files etc...
For example I've spotted the APK files are in \system\app. I never use the Peep or Teeter apps. Can I safely delete their APK files?
Thanks
p.s - I am using an unrooted HTC Desire.
bradavon said:
I've been looking at the root folder using Astro and there are several files/folders. Can any be deleted, without causing any problem? I'm running out of space and am hoping some are just temporary files etc...
For example I've spotted the APK files are in \system\app. I never use the Peep or Teeter apps. Can I safely delete their APK files?
Thanks
p.s - I am using an unrooted HTC Desire.
Click to expand...
Click to collapse
you cant delete them using astro, we only have write access to /system in recovery, use adb in recovery to delete them
edit, without root you cant delete anything lol
bradavon said:
For example I've spotted the APK files are in \system\app. I never use the Peep or Teeter apps. Can I safely delete their APK files?
Click to expand...
Click to collapse
In addition, deleting anything from /system won't actually gain you any more space for applications anyway due to the way that the filesystems are partitioned.
Regards,
Dave
Thanks guys. I take it you mean we've got write but not modify access to the \system folder? So we can write to existing files but not delete them.
I wasn't just asking about \system though but any files/folders in the Root folder. Are there any at all, that can be safely deleted? Or are you saying you cannot delete a thing without rooting?
Not that it sounds like it will make any difference, due to partitioning.
Thanks
Ok to put it as simple as possible:
- no you cant pretty much delete a thing apart from sd without root
- we cant do anything in the system partition while the system is booted due to the nand protection
- we can modify /system while in recovery (using adb)
- when you are running out of space it is on the /data partition, which have a fixed size so deleting from /system or anything else won't help
And at last my advice to you is to go root and install a2sd easy as pie and i've never had space problems since.
Thanks for the informative reply mortenmhp
I have just rooted my 2.1 Desire, trying to remove two of the mms.apk and one other mms file in the /system folder so I can install a different mms.apk, however when I try to do it, it says I dont have the proper permissions. Its rooted, I see the Super User icon in applications.
Any suggestions?
Please read a little before asking questions. It is commonly known, that we dont have full root access on the desire yet.
Due to the nand protection you cant edit the system partition while the system is bootet. You have to use a custom recovery image either via fakeflash or installed by unrevoked. Then you can edit the system partition by using adb commands.
Edit: which i also stated quite clearly 2 posts above yours several months ago
Is A2SD better than the Android 2.2 implementation? Which as far as I can tell just moves the APK (not apps/data) to the SD Card.
Thanks.
Well it is kinda off topic here but in my opinion yes it is better. I'm running a2sd+ atm. and you can make it move /data/data as well.
In froyo there have been some complications though when remountingSD after using it as mass storage. But you can read more about that elsewhere(i would provide a link but I'm writing from my phone)
So the conclusion must be that it is down to personal preferences
Thanks because the official implementation is something of a cop out. On WM you could run the entire App/Data etc... on an SD card.
Is is possible to change the root folder of the sd card used by android? I don't like having it create so many files/folders in the root of my card...
HDR said:
Is is possible to change the root folder of the sd card used by android? I don't like having it create so many files/folders in the root of my card...
Click to expand...
Click to collapse
Of course, you can place Android where ever you wish... just adjust the rel_path statement on your startup.txt.
For example, my installs are in /sdcard/Androids/TP2Ref - from Android's perspective. So in my startup.txt, I have
Code:
relpath=Androids/TP2Ref
- Just make sure that goes in the cmdline section.
Pretty sure this is in the FAQ... Try searching before you post
My relpath is set to andboot, but Android is still creating files in / on my sd card, I want to move the media, cache, downloads directories and the FSCK001 files to a subfolder.
HDR said:
My relpath is set to andboot, but Android is still creating files in / on my sd card, I want to move the media, cache, downloads directories and the FSCK001 files to a subfolder.
Click to expand...
Click to collapse
Only way to do that is to modify the source. I could easily make the changes in init for you, but the next time rootfs is updated (which will probably be soon since stinebd has to prep it for GB), you will lose those settings.
I'm working on some NAND stuff at the moment, so if you feel adventurous, all you have to do is modify init in rootfs and "compile" it. I have a little guide on compiling stuff (see bottom of post #1 for rootfs): http://forum.ppcgeeks.com/tp2-andro...modules-tinboot-nand-boot-more-beginners.html
I'll have a look at that, thanks.
HDR said:
My relpath is set to andboot, but Android is still creating files in / on my sd card, I want to move the media, cache, downloads directories and the FSCK001 files to a subfolder.
Click to expand...
Click to collapse
I can at least give you a easy solution for the FSCK files (no offense Nate ). Put this in the "CustomCommands" section of your froyo.user.conf:
Code:
rm -f /sdcard/*.rec
im totally agree; i dont see the point of having the possibility of choosing android to start in whatever location we want....if anyways android will keep creating files/folders in the root of our sd card.
if i recall correctly the very first releases didn't have this problem it would be great if u devs can change this behaviour by default
elamodelmerol said:
im totally agree; i dont see the point of having the possibility of choosing android to start in whatever location we want....if anyways android will keep creating files/folders in the root of our sd card.
if i recall correctly the very first releases didn't have this problem it would be great if u devs can change this behaviour for default
Click to expand...
Click to collapse
This is what Android needs by default, and where they would normally be created by the system. It's nice to stick as close to AOSP as we can, because then there's this small group of devs that work for this company 'Google' that then become our system image maintainers. Thanks.
This guide is based on a guide by Candanga on the i9000 forums, and some commands from supercurio
Please hit thanks on their posts and show them some love for the write up.
-----------------------------------------------------------------------------------------------------------------------
I’ve compiled a quick guide to instruct how to make a copy of the /efs folder. I’ve found in many threads suggestions about backing up this folder but the methods itself are very general. Most of the times they suggest to “root and copy the folder” with Root Explorer or similar, but usually it’s not that easy or it just doesn't work for everyone.
This guide ASUMES you have read this Excellent Guide by Darkstrikerfirst:
H E R E <-- Make sure to read the ADB Guide.
I recommend doing this with a Mobile just taken out of the box or with any Official ROM of its Service Provider. If you have already Flashed your phone with another ROM but its working fine, then you can use that /efs also.
Why the /efs folder?
This is a very sensitive system folder that contains Phone-specific information such as the IMEI (encrypted in the nv_data.bin), wireless devices MAC addresses, product code (also in the nv_data.bin), and much more. Often users trying to change product codes or trying to unlock the mobile will end up corrupting data in this location.
Why back it up?
Well, let’s resume it saying that backing-up this little folder will keep you away from Samsung service centres.
***WARNING: I take no responsibility to any damage caused by the methods cited and/or written here. Their sole purpose is to back-up data and not to alter in any way the integrity of the original files of the mobile***
What you will need:
Rooted SGS II to get permissions as a SU (Super User) and perform the backup
I would suggest learning a little about the terminal commands used (in case you are not familiar with them), as it’s better to know what you are doing rather than typing strings like a little chimp without knowing what they are; if you are a little lazy, then you have a good chance bricking your mobile. <- Busybox Commands(or Google them)
Terminal Emulator by Jack Palevich (available from the market) <-Terminal Emulator or use ADB which is included in the SDK Development Tools
The standard prompt of terminal (adb) is a $ sign. Once you enter “SU” it will become a # Sign.
***NOTE: Make sure to keep an eye on the screen of your SGS II during this process, because it may request SU permissions [currently doesn't on CF-root]; else, you will get an error (just if it’s the first time). In Terminal Emulator you will need to reset the app after granting permissions cause it usually freezes***
*Remember: to use ADB you need to enable USB DEBUGGING under Applications/Development in your SGS II.
Here are 3 methods, I recommend that you do both Clean and RAW.
Basic, unix permissions lost :
Code:
su
busybox cp -a /efs /sdcard/efs/
Clean :
Code:
su
busybox tar zcvf /sdcard/efs/efs-backup.tar.gz /efs
After this, you will end up with the file efs-backup.tar.gz in your INTERNAL SDCARD in sdcard/efs/, which is a “tarball” or a ZIP of the /efs folder. That file is your backup. You can expand it with Winrar.
You can also back up the mmcblk0p1 (where /efs is stored) under /dev/block which can greatly support in recovering your IMEI in case of a screw-up:
RAW :
Code:
su
cat /dev/block/mmcblk0p1 > /sdcard/efs/efs_dev-block-mmcblk0p1.img
Same thing, the target is the INTERNAL SDCARD in sdcard/efs/, so go ahead and copy the file.
+1 just do it....
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
JJEgan said:
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
Click to expand...
Click to collapse
From the thread:
I’ve found in many threads suggestions about backing up this folder but the methods itself are very general. Most of the times they suggest to “root and copy the folder” with Root Explorer or similar, but usually it’s not that easy or it just doesn't work for everyone.
Click to expand...
Click to collapse
And just copying the folder won't preserve permissions etc.
JJEgan said:
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
Click to expand...
Click to collapse
As long as you don't copy it to /sdcard, because it's VFAT and you'll lose the permissions settings on the files. If you copy it to /data or something then that's fine.
bumpity bump
RyanZA said:
As long as you don't copy it to /sdcard, because it's VFAT and you'll lose the permissions settings on the files. If you copy it to /data or something then that's fine.
Click to expand...
Click to collapse
Thanks the SGS 1 EFs i copied was copied to external sd card and then copied off to PC . Did likewise on SGS 2 using Super Manager .
So according to what you are saying that was not going to back up if needed .
jje
JJEgan said:
Thanks the SGS 1 EFs i copied was copied to external sd card and then copied off to PC . Did likewise on SGS 2 using Super Manager .
So according to what you are saying that was not going to back up if needed .
jje
Click to expand...
Click to collapse
It would probably have worked, but it would have made your EFS files readable and writable by any app that tried - not the end of the world since it's unlikely that any apps would try, but you still might as well avoid it if you can. I don't think there are any executables in EFS or anything that this will actually break though.
Thanks i did lose IMEI at one flash on SGS1 but a second flash recovered it .
I do like full backup of original firmware and anything else before playing with phone .
jje
I've done all 3 forms of backup myself. . Clean, raw and basic
thanks for the info. have had close calls previously and having backups would have helped ease the stress
Updated first post
Vodafone Fimrware backup BUKE1
Guys,
Have got a new samsung from Vodafone UK , but the firmware kernel seems a bit different, BUKE1. Is this something now and is the above method correct to backup the entire firmware so that it might be useful for vodafone samsung users. Is there an easy guide to backup the firmware ?
Regards
VJ
Guys can someone give me a bit of advice pleeeease
I followed this guide but am a bit worried i might have messed it up, i'm comfortable with command prompt as i'm a software dev but haven't used linux commands much.
Anyway i used the ADB shell from the Android SDK tools and entered the first command to backup the efs directory to the internal sdcard....
Basic, unix permissions lost :
Code:
su
busybox cp -a /efs /sdcard/efs/
Click to expand...
Click to collapse
And i got a lot of
Code:
cp: can't preserve ownership of 'sdcard/efs/...' : Operation not permitted
messages flashing up?
However i checked to see if the backup had been made and it had? What does this mean?
Next i compressed it using...
Clean :
Code:
su
busybox tar zcvf /sdcard/efs/efs-backup.tar.gz /efs
Click to expand...
Click to collapse
Which seemed to work as i have the file in the place i expect
When i did the next step...
You can also back up the mmcblk0p1 (where /efs is stored) under /dev/block which can support greatly to recover your IMEI in case of a screw-up:
RAW :
Code:
su
cat /dev/block/mmcblk0p1 > /sdcard/efs_dev-block-mmcblk0p1.img
Same thing, the target is the INTERNAL SDCARD in sdcard/efs/, so go ahead and copy the file.
Click to expand...
Click to collapse
It completed really quickly, with no messages telling me it was done but when i checked root explorer i couldn't find /dev/block/mmcblk0p1?
What has it done with it? I have dev/block/ but there is no mmcblk0p1? Although i do have /sdcard/efs_dev-block-mmcblk0p1.img. Should i have both?
From what i understand cat concatenates files and prints them to standard output, so i'm assuming the > is piping the std output to the internal sdcard?
Sorry for the questions but i thought i understood what i was doing but the last step and the "can't preserve ownership of.." messages from the first step threw me
Could someone explain this to me a little ;p
These aren't steps but rather separate methods achieving different things. Don't bother about the first one - it notes unix permissions lost , which is why you are seeing the can't preserve ownership messages. The files still backup but correct r/w permissions do not. You may as well chuck the files really, since you managed the tarball (second instruction). Just grab this and backup to external storage, in case you ever need it.
The raw backup will be under sdcard as you have found - stash this away somewhere safe too. You won't find mmcblk0p1 in root explorer as it is a partition, not a folder.
Thanks for the swift reply simion_levi
These aren't steps but rather separate methods achieving different things. Don't bother about the first one - it notes unix permissions lost , which is why you are seeing the can't preserve ownership messages. The files still backup but correct r/w permissions do not. You may as well chuck the files really, since you managed the tarball (second instruction). Just grab this and backup to external storage, in case you ever need it.
Click to expand...
Click to collapse
Do if i move the tarball to the external drive i can get rid of the sdcard/efs directory i copied to the internal card? The tarball has all the correct permissions?
The raw backup will be under sdcard as you have found - stash this away somewhere safe too. You won't find mmcblk0p1 in root explorer as it is a partition, not a folder.
Click to expand...
Click to collapse
Ok i didn't realise it was a partition, so i've just created an image of the partition that the efs folder resides on? Should i copy this to my external sd card as well?
Cheers brother
No problem! Yes, you've got it - backup the tarball and the partition image to computers, external drives etc so you can recover back to the phone in case of future catastrophe. The sdcard/efs directory can be deleted as the tarball contains exactly the same files (but with correct permissions).
Awesome, will get it done later. Out of interest how do you recover the partition image in the event of a disaster occurring?
Sent from my GT-I9100 using XDA App
One question please, since i stumbled on this one almost by luck.
Is there anything else to save before departing from stock?
Thanks.
Okay, so this guide assumes I already rooted my phone, but as a newbie I am completely in the dark about what does and what does not potentially harm the /efs. I would rather backup EVERYTHING before I flash/change anything, but from what I have read so far I need at least root to do backups.
Would it be safe to flash the Lite'ning Rom v1.1, coming from stock I9100XWKE2/I9100XENKE1/I9100XXKDJ/I9100XWKE2, and then backup mmcblk0p1?
Thanks!
Hello everyone. I see a lot of very basic android questions floating around the forums, so I figured I'd give a VERY basic rundown of the android filesystem for those who don't know. (If you're even slighty experienced, this'll seem like a "duh" thread, you should skip this. This is for new people.)
Ok, to understand android, first thing you need to understand are the basic partition structures. There are 5 android partitions.
boot
cache
recovery
system
data
Before I get into the partitions, you'll have to understand what a mount point is. When you "mount" a drive, you are making it available to the system. On linux (and by extension, android), you need to have a mount point. This is a directory somewhere that serves as a path for the mounted filesystem. So for example, let's say I wanted to mount mmcblk0p1 to a temp directory to edit it. For this example I'll create a directory /data/temp. Now you'd mount mmcblk0p1 /data/temp. When you read the contents of the directory temp under the directory data, you'll see all the info stored on mmcblk0p1. Even something as simple as a flash drive needs to be mounted under linux. If you're an ubuntu user, usually it automounts to /mnt/name of device.
Now, when you boot android, the first thing it does is boot up the linux kernel (when you see the tmobile splashscreen, that's when the kernel is loading.) Next, it loads up the ramdisk. Both of these files are on the boot partition. (When you open up a cwm zip file, you'll see boot.img in there, that's where these reside.) There are two files on the boot partition. zImage (the linux kernel), and initrd.gz (the cpio archive containing the ramdisk.)
What is the ramdisk you ask? Well, very simply, it's the place where the root file system is loaded, and where the init.rc resides. The init.rc is the android startup script (again, basic analogy). If you'd really like to learn about android and how it works, this is the first file I'd start reading.
On to the partitions:
boot - Described above, containing the zimage and initrd.gz
recovery - this is where either the stock recovery or clockwork recovery is located. This is only accessed when entering recovery mode.
cache - You guessed it, this is where some parts of android cache it's file. (Not to be confused with the dalvlik cache, that's located on the data partition.)
system - this is where the system is located. (Esentially the rom you're flashing.)
data - this is the partition where all your installed apps go, as well as the location of a couple parts of the system, like the dalvik-cache and the batterystats.bin file. (Quite a few more, just givinig examples.)
So what does all this mean to you? Well, I see a LOT of people asking about wipes before installs, or asking about flashing kernels, this is why I took the time to explain this.
When you enter cwm, and do a backup, it creates 5 .img files on your sdcard. (One for each of the partitions mentioned above.) When you flash a kernel, it only replaces the boot.img, and a couple files in the system folder. Usually these are kernel modules like the wifi module, and any other modules that aren't compiled into the system. (Although most kernel builders build cifs.ko and all that right into the kernel so the modules aren't needed.)
When you flash a rom, it will always replace the /system and /boot partitions. The rest, that depends on the rom. If you'd like to know what your rom is doing, open up the cwm zip file, and go to meta-inf/com/google/android and you'll see 2 files. Updater-script and update-binary. Updater-script will tell you what it does on install. (You'll see it mounting the partitions it needs, what it does and doesn't format, and also it does a whole bunch of simlinks.) Simlinks, or symbolic links, are either files or directories that point to somewhere else. For example, let's say you are a user who uses ext-sd. What you do is create a simlink for /data that points to the ext3 partition on your sdcard. This way, anytime the system goes to /data it writes somewhere else. Most of the simlinks created in android are more for busybox commands, but that's for another post
If you'd like to see what your mount points are, from an android terminal emulator (or of course adb, but if you are experienced with adb chances are you don't need any of this info in the first place ), type mount. (You might need to type su first, hit enter, then mount). This will list all your mount info. If you'd like to know the actual device name of the mount point, you'd look here. On ours, for example, it's:
mmcblk0p24 is /system
mmcblk0p26 is /cache
mmcblk0p25 is /data
and so on.
Ok, finally, a couple other questions I see often:
Why does my system "hotboot"?
When a system hotboots, it means that zygote has crashed. This is the virtual machine that android runs in. So if you are using your phone, and you all of a sudden go back to the boot animation (NOT the splashscreen with the kernel logo), you just hot-booted. When an application allows you to hotboot all it does is the following command from inside linux: pkill zygote (or pkill -9 zygote).
How do I calibrate my battery?
The batter calibration is a file called batterystats.bin. This is located in /data/system. When you get to 100% charge, if you delete this file, it'll start over on the battery calibration. (There are also market apps to do this for you for the squeamish.)
Other notable files:
gps.conf
Located in the /system/etc folder. This has all the gps configuration, nameservers, and things like this.
build.prop
Located in /system
A lot of device info is stored in here. For more info, google it.
Hopefully this wasn't too mashed together and confusing. I tried to follow a logical order, but I've had way too much turkey and beer today, so I'll post this and let it fly.
Have a happy thanksgiving everyone!
Good stuff, thanks OP.
Powered by the SGSII....
Very very useful for someone like me who knows a bit here a bit there but not sure of the whole picture.
Thanks!!
this should be useful for alot of noobs!
Thanks so much for this, being new to android this is incredibly useful. Bookmarking!
Sent from my SGH-T989 using xda premium
This thread should help alot of new people that just joined this forum and that are new .
Very informative, thank you.