Related
I've been a lurker since I got my eris back when root was a dream. Now I have quite a few things floating around my work dirs that aren't on xda or are wanted, so I figured I would start releasing some of my better/more polished things. So here is my first:
cbackup v0.4
Based upon craft_backup v0.5.3: showthread.php?t=628743 (sorry no links)
Backup and restore apps/data just like craft_backup
Changes/Features of cbackup:
- Change names to cbackup and crestore because I got tired of typing out "craft_backup" and "craft_restore"
- Move backup dir to /sdcard/backups/cbackup/*
- For cbackup, allow a choice for destination in backup dir (defaults to cb<date>)
- For cbackup, automatically move backup dir to timestamped location instead of overwriting it
- For crestore, display menu of all cbackup dirs along with original craft_backup dir if it exists. This menu has the latest last, numbered first with number 1 being the default.
- Works with roms that don't have the busybox symlinks installed
Changelog:
v0.3
- First public release
v0.4
- Fix problem when missing bb symlinks
Disclaimer: I am not responsible for damage caused by this app. I take no credit for the good work done on craft_backup, I just wanted something it didn't do so I hacked it up to suit my needs. Eventually it became nice enough to share. I will not support it, unless there is something wrong with my added code (which is possible, since the listing code is complex). Refer to the original app's thread for almost all problems.
nXuaJunYYc
Testing it now.
EDIT: WORKS PERFECTLY- 5 STARS.
Crestore- not found.... help?
I assume you're running "crestore" and not "Crestore" nor "Crestore-". Can you post the output of:
echo "$PATH"
from adb shell?
If that's fine, I think I know what may be wrong, but try that first
edit:
I'll be uploading a new version in a minute that I think will fix your problems, but if it doesn't, if you could also try the following it would be helpful:
# which crestore
# which sed
# echo abc | sed -es/a/d/
# ls -l /system/bin/crestore
# ls -l /system/bin/cbackup
# /system/bin/crestore
So I got it to find it, but it says not found for everything. Also comes up in Italian no matter what, but no biggie.
or use the eris master app, which can do most of that right now. the good thing is that its in a gui interface. jamezelle and i will be adding additional features later for the backup / restore apps as well. and one thing that we will have shortly is the ability to restore market update links for apps installed outside of the market.
@ECLIPS3:
Sorry, I'm a command line guy and I'm a linux guy. I really don't want to install wine and mono on my poor little linux netbook just to run your app and then navigate a gui. Plus these scripts run entirely on the phone, so you should be able to run them anywhere with only your phone (maybe even using terminal on the phone...haven't tested that yet). And before we start a war, I'm not saying that there is anything with wrong with your app, and I'm sure it has/will help a lot of people who want the easy gui, but it wasn't for me, and I thought other people may feel the same way. There's no reason both apps can't exist. I also appreciate you letting people know in this thread so the less cli-oriented people know their options.
@Erisftw:
That is really strange if it's continuing to not give you a choice for language. Are you sure you flashed the latest one that I uploaded (cbackup-v0.4-signed.zip)? And that you made your backup either using v0.4 or using v0.3 on a phone with busybox properly installed. If so could you copy and paste the first ~20 lines of output from crestore, and let me know if you are on windows or linux?
dont worry, not trying to start a flame war at all. i love diversity and competition as it creates better programs to arise, that ultimately are better for the end user. theres plenty of room for everyone here. i love CLI as well, but not a lot of people do. arent you glad this is a free world to have competition?
Changed to 4, restored. fine, but it has old rosie, and when you click on the app, it says app no longer installed.
Well hello everyone.
I am an application development student from Belgium.
I am proficient in Java, VB.NET, some c/c++ and also PHP/JS/HTML/CSS
Anyways, my recent interest has been going out to creating custom roms for the galaxy S!
The problem now is though, I was able to find some guides and such, but most were incomplete, and for HTC(and other) devices.
I have no idea what is different between making a ROM for galaxy S or a ROM for an HTC device.
If anyone would like to link me to some good resources that can help me on my way, or would like to collaborate (and in the meanwhile teach me a bit) I would be more than happy! (I am open for collaboration as I am pretty proficient in Java and I'm always happy to code and learn more about coding!)
I think the question is really want you want to do!
Custom ROMs for Android are as simple as using recovery console to replace files on the system with your own versions.
ie. Replace the framework.apk which contains all theme images with your own modified one, which you can use to skin the device. Same for replacing other system apps.
Unfortunately, most of these apps are closed source, so modifying them is difficult. The stock android system has open source versions of most of them though, and you can modify those and build them, and then replace the ones on the device. I'm not entirely sure how to build them up though, but it probably isn't too hard.
Then there are custom kernels, which let you actually change the underlying linux system underneath android - Samsung has an open source version of the kernel available that you can compile, and then flash to your phone using Odin or other tools. Compiling the kernel is pretty tricky though.
Well i'm really talking about stuff like SamSet, MoDaCo, Doc's ROM and others.
I'm not saying I want to create a pro ROM in a day or anything, but i'd really love to learn more to get better (always looking for more stuff to put on the resume, I guess?!)
Thanks a lot,
Kenny
Bump for some help
(sorry for the double post but i'm really eager to learn)
I don't have time to give a detailed response right now. However you will want to read up on yaffs (file system) and odexing/deodexing ROMs.
Thank you I will definately do that,
I am following a guide now to start out creating custom ROMs for android, however it was written for Motorola Droid and I have no idea what you have to do different for a samsung galaxy s.
I am a good coder, even though I say so myself, with a lot of experience. I also have a lot of linux experience, you name it
Only the problem is the old, and much known "where do I get started?"
So if anyone can point me out in the right direction on that, tell me how/where you started out, I would appreciate it greatly!
Thanks!
Very sorry to bump again
I set up my environment in ubuntu today to get started (just gotta fix a few errors, didn't know android wouldn't compile on java 1.6, only on 1.5)
Anyways, still need some help here! thanks!
Again I am awefully sorry for the bump here but i'd really like some help.
Note that i'm not a newbie at coding whatsoever and i'm not unfamiliar with some hardcore java, c/c++ and other languages, I'm just having trouble getting started when it comes to modding an existing android release (there are tutorials on HTC and other devices but some methods do not apply to the galaxy S)
If you're trying to create a ROM from scratch then unfortunately you're out of luck at the moment. No one has really managed to do so yet. By "from scratch" I mean the Android Open Source Project (i.e. official Android git repository).
What you can do is grab an existing firmware. Extract the contents, de-odex the apks, modify them or add new apks, optionally you can also compile a custom SGS kernel using Samsung's kernel source. Then you can re-odex the ROM, pack it back up and distribute it.
There's no real "starting place" as such and you won't yet find any tutorials about how to create SGS ROMs. Just give it a go and see where you get.
Yes, I do mean creating a ROM from stock samsung firmware, of course.
So my next logical question would be now:
How do I go over extracting contents from the existing samsung firmware, de-odexing and so on?
Any links/guides/tips are greatly appreciated, as long as they are applicable to this cell phone and not totally crap, thanks!
Samsung uses rfs, I think you should know. There is a thread somewhere in this forum regarding extracting .rfs file. Understood you need Debian though.
For some readup, go search for a famous guy named JesusFreke. Tons of materials...
Hope that from here onwards, this can lead you on, and to find out more. Google is your friend too...
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Raykoid666 said:
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Click to expand...
Click to collapse
Agreed completely! Getting a full cross-compilation to Samsung's Android going is seriously difficult! There have been some promises for tutorials and guides for setting things up though, but none have appeared yet. Probably because it's hard!
Well thank you for agreeing with me on that.
I am really hoping for anyone that can help me out here, either on here or in private, and give some detailed instructions on how to get started.
Hell there is enough information on creating roms alread, deodexing, adding/removing apps etc etc etc... The real problem lies in setting everything up properly.
I think I have gotten to the point where I'm compiling the android source (without samsung specific files)
note i'm saying "i think i am compiling" because i'm hoping it won't error out on me again after an hour of compiling!
But once that is done... I have no idea where to go next, where to get the samsung specific files, or what to do with them whatsoever once i have them
thanks!
Android generic source won't actually help you much. Samsung has made a huge number of changes to it, and while it is all open source, backporting their changes to get your stock source running on the phone is a major undertaking. I believe cyanogenmod was actually working on this, but it seems without much success so far.
What the other rom makers you see are doing is taking a snapshot of a running rom, copying over all of the APKs and the files on a running device, and then tweaking those. ie. Opening up framework-res.apk and changing the image files inside.
The update.zip roms that are what most people are doing are really just using the Android recovery to replace files on the phone with their own versions. Since the underlying system is linux, and everything is a file, this actually works pretty well.
The kernel development effort is completely separate from the rest of the system though, and Samsung has provided the entire source tree that just has to be compiled. I'm a bit stumped myself on all the details of setting it up, but I have seen some threads on this forum about it, and it didn't seem too bad to set up. Apparently you shouldn't use the codesourcery toolchain though, or something. Not too clued up on it, sorry. Hopefully someone with the details can chime in, or give us a link to the old post on it (I'm failing to find it using the search function! )
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Raykoid666 said:
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Click to expand...
Click to collapse
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
RyanZA said:
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
Click to expand...
Click to collapse
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Tayutama said:
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Click to expand...
Click to collapse
Haha cool, didn't know you could pull whole folders!
Raykoid666 said:
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Click to expand...
Click to collapse
The apk files in Android are odexed - that means they have a special index applied for dalvik that speeds them up somehow! I don't know how, I haven't checked how it actually works.
The important point is though:
odexed is faster, but you can't edit it because of signatures or something technical
deodexed means you can change it however you want
More useful info can be found from google - lots of it!
update.zip is easy - it's a zip file in a special format that can be understood by Android's recovery console. The easiest way to do it is to grab an existing update.zip and modify it as needed. Tayutama has millions of em around, so use his!
Then you need to sign it once you're finished with it so that the SGS will accept it. Samsung made a boo-boo and didn't disable the test keys for the 2.1 SGS firmwares. That makes it easy!
http://www.londatiga.net/it/how-to-sign-apk-zip-files/
Just use the test keys to sign it, and then copy it to /sdcard/update.zip and reboot into recovery and it'll work.
I will try to set up a guide to contain all of the information to get the most out of your I9000 Galaxy S. First the fineprint:
I am not responsible for any damage that any of these instructions may inflict to your phone, computer or any other device that is used in the processes described herein. I am also not responsible if you lose your warranty by flashing your phone with unsupported firmware or if any of these instructions brick your phone, if it will rape your wife or if it will eat your liver with some fava beans and a nice chianti.
I didn't test any of the programs specified herein for viruses/trojans/etc. I run Windows in a VirtualBox that doesn't have access to the internet and doesn't contain any private data, so I don't care for viruses, if you care for your OS though, you should check the programs for viruses before running them.
Use common sense when following such instructions, some of the things may differ because of different program versions, different operating systems or different setups.
Some of these instructions are based on a stock firmware, if your firmware is modded in any way, some of the things described herein may be inappropriate for your device.
1. NOT bricking your phone.
--Why, when, where: Everyone's afraid of bricking their phone. I see the term "bricking" is being a bit overused in these forums though. Everyone is using it, even for the case where the phone can actually be "repaired" with a few simple hacks, IMHO the term "bricking" should only be used in the case where you get your phone in a state where it is inoperable AND you can not in any way repair it yourself.
--Prerequisites: A bit of common sense.
There are a few simple steps that you can follow, to get the risk of "bricking" (as in, you can not repair it yourself and need to somehow get Samsung to either repair it for you, or give you a new device) to a minimum:
1.1. Before trying any of the other steps, make sure that you can get to both the "Recovery mode" and the "Download mode" using the 3-button-combo. If this doesn't work for your device you can try following the steps described here: http://forum.xda-developers.com/showthread.php?t=810686
1.2. Try to avoid flashing stuff that contains a bootloader. The only way to permanently brick your phone so that you can not repair it yourself (at least AFAIK) is to flash a bootloader and then interrupt that flashing. If the bootloader didn't get flashed properly and it's broken, there isn't much you can do about it, and you need to somehow get Samsung to either repair it or give you a new one (if you're lucky). If the bootloader is fine, there is almost always a way to "repair" your phone yourself.
1.3. Do not interrupt the flashing processes. When using Odin or Heimdall to flash stuff to your phone, there is always the risk of bricking it if you interrupt the flashing process. If the bootloader is fine though and you can get into the "Download mode", you might be able to repair it.
If you follow these simple advices, it might save you money, nerves and also some time without your phone (the time that it takes Samsung to repair it, which can sometimes, depending on country, be even a couple of months).
2. Flashing stock firmwares.
--Why, when, where: You should usually do this if your phone doesn't work with your current firmware, if there is a new firmware out that might work better or if you just want to go to a stock firmware.
--Prerequisites: Odin, a stock firmware (from www.samfirmware.com for example).
NOTE: Apparently there are people that report that using Odin v1.3 might interrupt the flashing and leave you with a soft brick and that v1.7 doesn't have this problem. I have always used v1.3 and never had problems because of it, but if v1.3 isn't working for you, you might give v1.7 (or even heimdall) a try before giving up.
The steps to flashing a stock firmware are already described in a couple of other threads, like: http://forum.xda-developers.com/showthread.php?t=818556
Nonetheless, here a quick sum-up of what you have to do:
2.1. Open up Odin.
2.2. Put your phone in the "Download mode" with the 3-button-combo (Volume Down + Home + Power).
2.3. Connect your phone to your computer (DO NOT CONNECT THE PHONE BEFORE OPENING ODIN OR THIS WILL NOT WORK).
2.4. Odin should recognize your phone and one of the "com" boxes should light up yellow. If this isn't the case, try repeating the previous steps and eventually connect your phone to another USB port.
2.5. Select your firmware in Odin.
2.5.1. --OPTIONAL-- If you want your phone to be like new, you can select "Re-Partition" in Odin, which will make it repartition your Internal SD. In this case you also have to use a .pit file (WARNING -- you will lose all of your installed applications and settings).
2.6. Take a deep breath and click the "Start" button.
2.7. Wait for the firmware to be flashed and for the device to be restarted.
2.8. You now have a stock firmware. If you also selected "Re-Partition" in Odin, all your programs and settings will be gone and your device will be like new.
3. Rooting your phone and flashing a custom Kernel.
--Why, when, where: Rooting your phone will get you super-user permissions to Android (super-user is Linux's equivalent of "Administrator rights" in Windows). This will allow you to execute some programs that need root permissions, access partitions that you otherwise couldn't and do other cool stuff with it.
--Prerequisites: Stock firmware (as most --if not all-- of the custom ROMs or kernels have root permissions already), Odin or Heimdall.
There are many ways to get root permissions on your device, like with special apps (OCLF for example), with CWM (aka ClockWork Mod) or, my preferred method, flashing a kernel that has this built-in. For this example I will use the SpeedMod Kernel, which is my preferred one. If you have another kernel that you like and that has root built-in, you can use that one.
3.1. Download your preferred kernel (the version for Odin, not the one for CWM).
3.2. Open up Odin or Heimdall.
3.3. Put you phone into "Download mode" and connect it to your computer (DO NOT CONNECT THE PHONE BEFORE OPENING ODIN OR THIS WILL NOT WORK).
3.4.1. If you are using Heimdall, unpack your kernel until you end up with a file called zImage. Select that in Heimdall in the box for "Kernel (zImage)" and click Start.
3.4.2. If you are using Odin, select the file you downloaded in the PDA box and click Start.
3.5. After your Phone reboots, go into "Recovery mode" and go to "Advanced Speedmod ULK features" -> "ROOT / Install Superuser".
3.6. After rebooting the phone again, you should have root permissions.
4. Deodexing your apps and framework.
--Why, when, where: The system applications and the framework files on the Android OS are normally 'odex'ed. By deodexing, you will get rid of the .odex files that come with every apk and jar file and you will be able to edit the apks like any other apk. It will also save you a wee bit of space, and make your apps launch a wee bit faster.
--Prerequisites: Stock firmware (as most --if not all-- of the custom ROMs are deodexed already), xUltimate (this is what I found to be the easiest, if you know any software that is better, please let me know), root permissions.
You can download xUltimate from here: http://www.droidforums.net/forum/xeudoxus/47283-release-xultimate.html
There are more ways to deodex your apps, but I found xUltimate to be the easiest.
4.1. First of all, you need to get the files from "/system/app" into the subdirectory "origi_app" and all of the files from "/system/framework" into the subdirectory "origi_frame". Both "origi_app" and "origi_frame" should be in the folder you extracted xUltimate to. If they don't exist, create them yourself. There are actually two ways to get the files there, either with xUltimate itself (options 1 and 2) or by copying them to your SD with "Root Explorer" for example and then copying them from your SD to your computer (or with adb of course).
4.2. Deodex the apps and framework with xUltimate, options 3 and 4.
4.3. After deodexing is finished, the deodexed files will be located in the directories "done_app" and "done_frame" in your xUltimate folder. You have to get these files back to their original directories, in /system/app and /system/framework. Again, there are a couple of ways to do this, either with adb (MOST RECOMMENDED ONE), or with "Root Explorer". For the adb method, you should open a command prompt and execute following code:
Code:
adb shell
su
stop
mount -o rw,remount /dev/block/mmcblk1p21 /system
rm /system/app/*.odex
rm /system/framework/*.odex
cp /sdcard/done_app/* /system/app/
cp /sdcard/done_frame/* /system/framework/
mount -o ro,remount /dev/block/mmcblk1p21 /system
reboot
5. Optimizing and zipaligning your apps.
I wasn't yet successful at optimizing or zipaligning. Optimizing (aka Compressing) the apps gave me a lot of FCs, optimizing the framework files gave me bootloops. If anyone has any advice on this, I'd be very thankful.
Also, see post #2
6. Protecting your screen.
--Why, when, where: This is not about protecting your screen from scratches, but rather about protecting it from degradation over time. As you might already know, AMOLED screens are prone to the "burn-in" effect. To elaborate a little: AMOLED uses Organic LEDs to display the amazing graphics you see on your display. These OLEDs are very good at displaying bright, colorful pictures, they have a downside though -- they fade over time. That means, the more a specific OLED is used, the less light it emits. If the whole screen would degrade at the same pace, that wouldn't be such a BIG problem, but the very nature of the OLED screens makes them degrade unevenly. That means the OLEDs that are used more frequently (like clock, phone signal, wifi, notification bar), get dimmer faster and this leads to ugly "shadows" on fullscreen apps. To be able to keep your screen as beautiful as new, I got a couple of tips, so that the display degrades more evenly and you avoid the ugly "shadows".
!! Most users won't even notice these degradations, also they won't be noticeable in 90% of use-cases and they will only appear after longer use (6 months+), but you can still use these tricks if you want your display to be almost as good as new a couple of years from now !!
6.1. Don't set brightness to 100%. At least not all the time. You should best be using a brightness setting that fits your ambient light, or the "Automatic brightness" setting. This will ensure that the OLEDs don't wear out as fast (the brighter you use them, the faster they will degrade).
6.2. Use a grey notification bar. The notification bar is the biggest "static" element on the screen. Most apps that are not fullscreen, will also show the notification bar, and this leads to an uneven degradation in that area if it isn't a neutral color. If you use a white notification bar, the OLEDs there will get dimmer faster and you will get an ugly shadow when using fullscreen apps, if you use a black notification bar, it will not degrade as fast as the rest of the screen and that area will be "brighter" in fullscreen apps, that's why I recommend a medium grey.
6.3. Use as little static elements as possible. If you don't need the clock in the notification bar, get rid of it. Get a theme that uses grey or green icons (see next step why) and try not to leave the phone on over night displaying the same static image.
6.4. Avoid blue. As you can see here for example: http://img24.imageshack.us/img24/8057/new1ls.png the blue OLEDs are degrading at a much faster pace than the green or red ones, this is why you should avoid using blue wallpapers or blue themes, they will make your display degrade faster than if you use a green theme and a green wallpaper for example.
These tips won't make your screen live forever, it will degrade too, but by using these tips, at least you can assure that you will have the most of your awesome display even in a year or two from now.
7. Theme-ing your phone.
Coming soon...
8. Unlocking your phone.
--Why, when, where: If you bought your phone with a contract, chances are that it might be locked in that specific network. If you want to also use other SIM cards in it, that are from another provider, you will have to unlock the phone (!! WARNING !! in most cases this will lead to a void warranty, please consult your contract).
--Prerequisites: Root privileges, adb.
8.1. Get the /efs/nv_data.bin file from your device to your computer. You can do this either with adb or by copying the file to your SD card with "Root Explorer" and then copying it over to your machine from the SD (Be sure to keep a backup of this file and the /efs/.nv_data.bin.md5 file.)
8.2. Open up the file in a hex editor, go to the address 0x181468, where you will see something like this:
FF 01 00 00 00 00 46 46 46...
We are interested in that first '01', that means the phone is locked. Just change it to '00' and save the file. Copy it back to your SD card and then with "Root Explorer" back to it's original location (or 'push' it directly with adb). Then remove the .nv_data.bin.md5 file and restart the device (Again, be sure to make copies of these files before modifying or deleting them!). After this, you should be able to insert any SIM card into your device and it should work without the need for any further hacks.
9. Setting up 'adb' on your machine.
--Why, when, where: adb (aka "Android Debug Bridge") is a tool that will let you execute remote commands on your android device. It is useful for debugging, accessing and copying files from/to your device and much more.
--Prerequisites: The android SDK, which you can download from here: http://developer.android.com/sdk/index.html and the USB drivers for your phone, which you can get by either installing Kies or by downloading and installing these drivers: http://www.mediafire.com/?a6ni32dk6nn953b (password is 'ragin' -- I didn't test them, so feedback on these is welcome).
9.1. Unpack the downloaded android-sdk.
9.2. Go to the unpacked directory and launch the SDK Manager.
9.3. Go to "Available packages" -> "Third party Add-ons" -> "Google Inc. add-ons" and tick the box next to "Google Usb Driver package" and the click on the "Install Selected" button. This will download and install the Google USB Drivers.
9.4. Whenever you want to connect to your phone through adb, make sure that you have enabled "USB Debugging" under "Settings" -> "Applications" -> "Development".
9.5. You should now be able to open up a command line ("Start" -> "Run..." -> Type "cmd" and click "OK"), cd to the subfolder "platform-tools" under the folder where you unpacked android-sdk and run "adb" in there.
Take some time to get used with the commands that adb offers, as these will help you to debug problems when you encounter some.
10. Lagfixing
--Why, when, where: It is said that the default filesystem that is being used for the partitions on the SGS (RFS) is having slow read times and thus the programs launch a bit slow, sometimes perceived as "lag". This can be fixed by converting the filesystem on the most used partitions to a more modern filesystem, like the ext filesystem, which not only has a bunch of improvements over such old filesystems like RFS, but also seems to be a bit faster.
--Prerequisites: A kernel that supports lagfix.
10.1. Since every kernel has it's own way of converting your FS, you should best look into the documentation of your kernel on how you can apply a lagfix. Some even apply it automatically for you (as in, "lagfix on" is their default setting).
11. Do NOT overcharge
--Why, when, where: Almost all new batteries have an overcharging protection. This means that the protection that is built into the battery will not let it charge to 100%. This is a feature, not a bug! This will help prolong your battery life while also keeping it safe from overheating/explosion/etc. Do not try to trick it and unplug and plug again until you see 100%, just get used to the fact that you can't have 100% battery anymore and live with it, or you risk destroying your battery.
12. Call recording
--Why, when, where: Most Galaxy S firmwares don't have the ability to record both streams of a call. This is not a bug, it was designed like this because in most countries it is illegal to record someone without their permission. Yes, there are apps that will let you record a call, but without software support, it will record the other end from the microphone, which will result in low quality, but there is a workaround.
This might be illegal in your country! I'm not responsible if you get sued for recording someone without their permission.
--Prerequisites: Root permissions, adb/root explorer, a 2.2.1 firmware.
12.1 Download the attached "CallRecord.zip" and unpack it.
12.2 After unpacking you should have 3 .so files. You need to get these files into your /system/lib folder with either adb or by copying them to the phone and then using "Root Explorer" to copy them to the proper folder.
12.3 Reboot.
12.4 After the phone has rebooted, you can use most apps that are on the market to record calls properly (that means not from the microphone). I use AllCallRecorder because it is simple and does the job. There are also Phone.apk's that have call recording built in, you could also install one of those and record your calls with it.
That is all for now. I will add more information as time goes by and I hope this will become a full guide on how to make the best out of our devices. If you have constructive criticism, questions or any ideas or tips on how to improve this, please let me know. If you don't have anything constructive to add to this thread, please DO NOT post. If my troll alarm goes off, I WILL ignore you.
Thanks goes to:
ragin for the USB drivers.
I have learned most of the stuff I put here from various searches on Google and the xda forums and I may not remember the exact threads I got them from. If you feel I have copied your work without giving you credit, I am very sorry for that. Please let me know via a post or a PM and I will link you in the "Thanks".
I am sorry if my English is bad, it's my third language though. I hope that the post is understandable by most people.
This post will contain instructions for *nix based operating systems
Because I am using Linux myself and because it is much easier to do stuff in the command line on Linux than it is on Windows, I will mostly post instructions for *nix systems. If anyone wants to help out by "translating" them over for Windows machines, I can include it in the next post.
Optimizing and zipaligning
I have managed to Optimize and zipalign the apps in /system/apps with the following code.
You need to run this on a *nix distribution (I used Ubuntu) with at least the following packages installed: bash, zip, unzip, optipng. Put all the .apk files from /system/app in a folder on your machine, cd to that folder and execute this code snippet.
Also, beware that some of the apps might not work (I had for example FCs with the camera and the phone app), I'll try to figure this out and make it pretty much foolproof. Currently everything but the .9.png files are optimized (the .9.png files are some special files that can't be treated like normal png files).
Code:
for apk_file in *.apk; do
file_name=`echo $apk_file | sed -r s/.apk//`
echo -ne "Unpacking\t$file_name.apk... "
mkdir $file_name
unzip -qq $file_name.apk -d $file_name
cd $file_name
echo -ne "Done.\n"
echo -ne "Optimizing\t$file_name.apk... "
for pngfile in $(find . -name '*.png' | fgrep -v .9.png); do
optipng -quiet -o 5 $pngfile
done
echo -ne "Done.\n"
echo -ne "Repacking\t$file_name.apk... "
zip -q -0 -r ../$file_name.apk *
cd ..
rm -rf $file_name
echo -ne "Done.\n"
echo -ne "Zipaligning\t$file_name.apk... "
zipalign -fv 4 $apk_file $apk_file.za
mv $apk_file.za $apk_file
echo -ne "Done.\n"
done
EDIT: I added the -0 flag to the zip command, since you should never "compress" apk files, because this leads to the FCs I was experiencing.
Post also reserved.
Last reserved post. You can start flaming now.
shantzu said:
Last reserved post. You can start flaming now.
Click to expand...
Click to collapse
Posted in the wrong place... try reading the faq's about where this belongs.
davidf said:
Posted in the wrong place... try reading the faq's about where this belongs.
Click to expand...
Click to collapse
Well, the rules of the development section state: "Rom Development - only meant for very advanced technical discussion directly related to ROM development activity and the delivery of actual ROMs and ROM components ONLY."
I'd regard this as an "advanced tehnical discussion", since it also contains information on how to deodex and (to come soon) optimize/zipalign your apps, that's why I thought it would belong here. I would also like this to be a place for advanced discussions on best practices on deodexing, theme-ing, and otherwise modifing a stock ROM manually. If the moderators still think that this doesn't belong here, I'm sorry, and would like to ask them to move it to the proper Forum.
Sticky Material.
Don't you think your Title is misnamed? The thread contains much more than just a guide getting most out of our SGS.
Very good effort anyway.
ragin said:
Sticky Material.
Don't you think your Title is misnamed? The thread contains much more than just a guide getting most out of our SGS.
Very good effort anyway.
Click to expand...
Click to collapse
Well, I didn't know what else to name it, and didn't want to use a really long name. I think this title best describes what it's about...
Thank you for your reply!
very good post. It'll be extremely helpful for new users i reckon.
question
can this method be used on almost any samsung galaxy? (i have galaxy 551)
and about deodexing...is xUltimate a general app for any Android phone or only for SGS ?
Awesome stuff thanks for this cleared up a few things
waveboy2u said:
can this method be used on almost any samsung galaxy? (i have galaxy 551)
and about deodexing...is xUltimate a general app for any Android phone or only for SGS ?
Click to expand...
Click to collapse
Well, the program seems to be posted in the "Motorolla Droid" forum, so I don't think it was even intended for the Galaxy S. If I were to guess, I'd say it might work on any Android device. Just be sure to make a backup in case anything goes wrong.
Thanks alot! Never knew the degrades display.
Sent from my GT-I9000 using XDA App
Shantzu, first, thank you very much for this valuable contribution!
While I agree that it is related to "highly technical discussion", it's not directly connected to ROM cooking/development. In fact, this is the kind of thing that people should read before they start mucking about in the dev section
I've gone ahead and moved it to the general section and made it a sticky topic for now. However, those are starting to pile up in this section, so we'll likely roll up several useful threads like this one into one unified reference sticky here soon.
sirphunkee said:
Shantzu, first, thank you very much for this valuable contribution!
While I agree that it is related to "highly technical discussion", it's not directly connected to ROM cooking/development. In fact, this is the kind of thing that people should read before they start mucking about in the dev section
I've gone ahead and moved it to the general section and made it a sticky topic for now. However, those are starting to pile up in this section, so we'll likely roll up several useful threads like this one into one unified reference sticky here soon.
Click to expand...
Click to collapse
I was thinking about this guide as some kind of "cook your own ROM directly on the device", that's why I was also including tips on how to deodex the apps and I'd also like to include tips on how to set up themes (not install third party themes, but rather explain where each icon can be found and how it can be modified) and other mods. Anyway, if you think it better fits in the General section, I'm fine with that, as you can see I'm pretty new in these forums and not that experienced (for example I have also seen a guide on how to manually unlock the phone that was stickied on the Developers section).
Anyway, sorry again for the trouble and thanks for clearing it up!
Very good post. Thank you!!
Very good work. One thing i noticed though: you use ext fs for the system rw remount. This i think will only work for ext converted system partitions not the original rfs system.
Sent from my GT-I9000 using Tapatalk
liraindon said:
Very good work. One thing i noticed though: you use ext fs for the system rw remount. This i think will only work for ext converted system partitions not the original rfs system.
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
I know, it normally shouldn't work, but it actually does. I don't have any lagfix applied and it works just fine. I will try and see though if I can come up with a more general command that 100% works in all cases.
EDIT: ok, not specifying any filesystem at all works too. I will have to see if this also works with a lagfix enabled, but I guess there shouldn't be any problems.
Thanks for your comment!
whoa didnt know about degradation... thanks!
nice
very good write up.. +1
Hi All,
Unfortunately as a new user I can't post this in the Dev forum. So I'll put it here for now and perhaps can move it later.
I'm wanting to tinker with uboot on the Iconia. Ideally what I'm hoping to achieve is;
A versatile and usable port of uboot to the iconia complete with documentation (both how to get/build as well as use) and binary files available for download.
1) uboot to replace the default bootloader or the existing kernel image in flash and have the uboot able to load the standard kernel image from the system partition.
2) To have uboot able to run an interactive shell, either over USB or on the local console with a USB keyboard.
3) A boot menu would be nice with control by builtin buttons.
For my build box I'm using the current Debian with GCC 4.1 available
Anyway, if any anyone can help at all please fell free to respond. It is my intention to update this thread as I go, documenting the journey and ultimately publishing the results with how to info.
Tonight I will edit this with a better outline (more verbose) of what I'm attempting to do and some info regarding what my build env is and what info I already have.
Hope to create something useful here for everyone.
Owen.
OK. I'm still checking things out... eppeP, did you get anywhere with the SBK? if not uboot will just have to replace the android kernel and maybe be patched so it can load it from the system partition instead. One guy (lost the thread) said he had to mod the patch to get it to complile, but didn't say how.
As far as a boot menu goes, I'm thinking of a script that will search the boot folder of all mountable volumes and present a menu, much like the Apple boot selector does. Still don't know if its possible though and is somewhat secondry issue anyhow.
Can anyone give info on uboot env storage. also I need to know the partition layout for the internal MMC (got a good idea already but need to be sure and whats the partition layout?)
Have you talked to sp3dev and sc3k? Ive been followng the native linux thread and i believe they are trying to do just that. They would be your best source of help i think
Thanx gh123man,
Yep, I've seen good & exiting posts from sp3dev, muromec and hexeh about this stuff. Unfortunately I can't post in the dev threads cause I'm new to xda forum.
I was kinda hoping they might spot this thread and respond
Sounds like fun, I might be interested in helping.
So far I've been looking into generating the SBK, decrypting BCT/EBT and are just about to start looking at the partition format (there seems to already be some code for this, so that should not take long to get an idea of). So I guess unless I find something more interesting, trying to pick apart the bootloader to get a better understanding of that part might come soon anyway.
Is there any way to image a custom ROM (for example) 10 Nexus 7 tablets at once? I ask as my job is trying to figure out a time-saving solution as most Google searches and forum searches say that it's a one-by-one ordeal.
Don't think so... Although flashing through fastboot or recovery really doesn't take too long.
Call up Asus and tell them you want to buy 10,000 tablets @ MSRP - but with your ROM on it. 100% time savings.
If that doesn't work, you are going to need to unlock the bootloader for each. That is only a one by one if you have just the one laptop.
Borrow some extra laptops and go hire some day laborers down at the local Home Depot. Maybe buy some USB hubs and extra cables if the laborers speak your local language and can follow instructions well.
Before that all happens you could cobble together your own boot image which manually brings up WiFi, mounts a SMB share from your WiFi LAN, downloads your ROM across wifi and then flashes that ROM. (You only need a command file in /cache/recovery to get somebody's else's non-graphical /sbin/recovery started on that job) A 5 Mb boot image will dance down the USB cable in a couple seconds, and the cable can be yanked almost as soon as the boot begins. After that, the tablet takes over doing your scripted evil bidding without human intervention.
For that, you will need only a kernel that deals with CIFS mounts and a non-graphical /sbin/recovery. But lucky you; someone has already built them for you and and you can kype them right off of XDA for free. Write your scripts and fire up mkbootimg.
Buy both devs a cup of coffee each and tell your manager that you got some day laborers to do all the work. Yay! No insurance premiums or workman's comp!
Promotion time? Yes. Assuredly. Happy days.
korockinout13: That was on par of what I was expecting... =\
bftb0: I wish it was 10,000+ units LOL! It's more like an academic deployment of 50 - 100 I'd estimate.
On the latter idea, is the custom kernel stuff in a Development section sticky? If not, do you have a link to it? Cause honestly that sounds like the best and most pain-free way of doing the images: push the boot image via USB, yank the tablet from the USB cable and put it on a charger, then continue to the next tablet.
The main reason I am asking is cause I'll be doing the imaging and I really don't want to babysit 50 - 100 Nexus 7 tablets on top of doing my daily duties. Being able to do a semi-automated deployment would be awesome and allow me to keep productive.
I have looked into this for a couple hours.
It might indeed be possible, but not without quite a bit more work. In fact, a significant enough effort that it might actually take someone unfamiliar with the territory more time than it takes to flash 100 tablets (I estimate that effort at about somewhere between 15 and 20 man-hours if done in a serial fashion with one "flashing station". Seems like a better approach would involve more than one "flashing station", though.)
I looked at current CWM and TWRP recoveries. In terms of pre-built stuff that is symlinked to the busybox, I note that TWRP have "tftp" and "ftp" and "wget", whereas CWM doesn't symlink any tool name with network functionality to it's busybox. The thinking here was that if a CIFS mount could be avoided by pulling file(s) down to the tablet with wget or ftp, that could simplify things - even raw IP could be used.
TWRP (and CWM) configures the kernel with
CONFIG_CIFS=m
but neither provide the kernel modules in their shipped recovery, nor the proprietary Broadcom drivers for the Broadcom 4330 WiFi/Bluetooth combo phy. (The latter is readily available though).
I kanged the latter into a booted TWRP recovery manually, and the firmware load seemed to take but there were other dhd_bus errors. Even if it had taken, there is still an lack of wpa_supplicant. That can be overcome by yanking one from elsewhere, but most of them are dynamically linked. That's not a big deal either - the supporting linker and shared libraries could in principle also be kanged into the recovery ramdisk as long as there is enough space in the boot partition. You have to recursively examine the shared libraries for dependencies though - one can pull in others that are not first-descendant dependents of "wpa_supplicant". (It needs stuff like SSL libs, etc).
But there is more; for example, examining the config for TWRP 2.4.1.0:
grep BCM config
# CONFIG_ARCH_BCMRING is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BCM4329_RFKILL is not set
CONFIG_BCM4330_RFKILL=y
# CONFIG_BCM4329 is not set
CONFIG_BCMDHD=y
CONFIG_BCMDHD_FW_PATH="/system/vendor/firmware/fw_bcmdhd.bin"
CONFIG_BCMDHD_NVRAM_PATH="/system/etc/nvram.txt"
CONFIG_BCMA_POSSIBLE=y
# CONFIG_BCMA is not set
# CONFIG_BCM_WIMAX is not set
Note those paths in /system. I mention this because the recovery generally mounts the (flash memory) system partition right on top of /system in order to restore files during a ROM installation - which covers up any file contents stored below that mount point in the ramdisk during the time that the mount is active (file restore operations being performed into flash memory).
Same thing wpa_supplicant. Among other things, it wants to read things out of /data/misc/wifi/ e.g. wpa_supplicant.conf
Mount /data and that stuff gets covered up as well.
It might turn out that all that stuff only needs to to be read once; so I suppose if you could get the wlan0 interface configured to a pre-defined AP SSID (with no encryption and no authentication!), maybe that's only a minor issue.
Probably rather than kanging files this way and that, the right way to approach this is to clone the TWRP git repository, and modify paths and the build tree to have firmware and wpa_supplicant support infrastructure not live in either /system or /data - that way you could mount whatever you want at /data and /system without bolluxing up WiFi state management.
Or, mod the /sbin/recovery and "updater-binary" code to mount the system and data partitions at temporary mount points (instead of /system and /data) for the purpose of unpacking the ROM archives into their destination filesystems. Then any supporting firmware/configuration files for WiFi support could be done out of the ramdisk, and would not run the risk of being "covered by mounts".
Well, cheers. I'm not sure I should carry the ball on this any further, unless you have some coffee money on you.
It is tangentially related to understanding how to get Ad-hoc WiFi working, and I would like to see that though.
Maybe. Maybe not.
Good luck