[Samsung Captivate Glide] steadfasterX:
FAQ

Frequently Asked Questions (FAQ)

Why another ROM and why build on ICS?

Please read the full story here: http://xdaforums.com/showthread.php?t=2789119

[*]

Do you need to network unlock the Glide?

Follow the excellent guide here: >Click here<

And also take a look on my additions to it here: >Click here<

[*]

When version [FILL-IN-WHATEVER-YOU-LIKE] will be released?

Please keep in mind that this project is not a full time job so questions about a release date is something I will / can not reply to.

This is not because I don't like you but it is because I cannot promise anything. RL is my priority and this can not be controlled (fully) as you may know ;)

[*]

Is device encryption supported?

Yes, device encryption is supported since sediROM v1.1

You may want to check out a working TWRP version to be able to still do nandroid backups here sediTWRP with decrpytion support (click)

Hint:

Device Encryption is fully supported when choosing the easy installation mode while installing.

That means if you choose the modify mode afterwards be careful what to choose within the

TWEAK

section (kernel optimization/swap internal to external sdcard/...). Those are not all tested yet so do a backup before choosing them. ALSO for /sdcard! because that gets encypted to.

If you choose the easy installation method and change only apps/kernel/modem etc you will be safe though.

[*]

Can I upgrade from a previous version of sediROM?

basic* --> will be explained some lines later (pls look for: "What does "tested (basic)" means?" in this FAQ)

v2.0 ----> v2.1

Yes: tested (basic + full)

basic --> pls look for: "What does "tested (basic)" means?" in this FAQ

full -----> tested on my production device, too

v1.7 ----> v2.0

Yes: tested (basic + full)

basic --> pls look for: "What does "tested (basic)" means?" in this FAQ

full -----> tested on my production device, too

v1.6 ----> v1.7

Yes: tested (basic --> pls look for: "What does "tested (basic)" means?" in this FAQ)

v1.5 ----> v1.6

Yes: tested (basic --> pls look for: "What does "tested (basic)" means?" in this FAQ)

v1.1 ----> v1.6

(this is the last upgrade test for v1.1. I will not test upgrading to higher releases from v1.1!)

Yes: tested (basic --> pls look for: "What does "tested (basic)" means?" in this FAQ)

v1.1 ----> v1.5

Yes: tested (basic --> pls look for: "What does "tested (basic)" means?" in this FAQ)

The same pre-requirements necessary as in v1.0 ---> v1.1 !

v1.0 ----> v1.1

(this is the last upgrade test for v1.0. I will not test upgrading to higher releases from v1.0!)

Yes: tested (basic --> pls look for: "What does "tested (basic)" means?" in this FAQ).

Manual pre-requirements necessary! To upgrade from v1.0 to v1.1 you need to wipe /system partition manually before you start the upgrade because there is a bug in v1.1 and v1.5 preventing from doing the partial wipe which normally will do that for you.

These are the steps:

Within TWRP choose the wipe menu and then "advanced". Afterwards select only "system" !

Go on and afterwards start the sediROM installer again and choose "partial wipe". Because you have wiped /system manually the installation should run fine afterwards.

This way you will NOT wipe any configs or apps or something as long as you leave /sdcard and /data untouched in step 1.

That workaround should work even when you already tried the partial wipe in "Easy Installation" mode.

If you use L2SD here a special note: from [MENTION=5324737]maddbomber83[/MENTION]:

What does "tested (basic)" means?

When I test upgrades I do that very basic. As the system is still the same (ICS 4.0.4) and normally no android related things changed I strongly believe that doing upgrades shouldn't harm anything. Even all the apps should work as long as you don't played around with system apps (In Titanium Backup and other tools you can make an app a system app which means it will also be copied to the /system area which will be overwritten due to the upgrade. If you have converted a user app to a system app it will be lost then). Normally you wouldn't do such a conversion but as it is possible I need to add that hint here..

When I state an upgrade path as "tested (basic)" it means that it SHOULD work but as always no guarantee ;)

My Test setup is always as follows:

a custom wallpaper (Home + Lock Screen)

added some icons to the launcher

set a lock screen password

system settings for screen timeout and screen off

WiFi settings for my WLAN

Installed Titanium Backup app

acquiring root permission (ES File Explorer and after "adb shell")

Upgrade guide:

do a nandroid backup! <-- sigh this is VERY important do not skip that step!!

copy that backup to your pc just to be sure!

choose to install sediROM

choose easy installation

then (the upgrade magic): choose "partial wipe" !

complete the rest of the installation and you're done.

[*]

Screen wakeup delay?

I have a screen wakeup delay when using sediROM! AND I use sediROM < v2.0 (e.g. v1.7).

The problem here is the default used kernel in sediROM before v2.0.

All smaller versions uses "Litekernel" as the default kernel which is the root cause for this problem.

Before v1.7 there is no really option for fixing this other than installing another kernel manually.

In v1.7 you are able to switch to the CM11 kernel in the modify mode within the sediROM installer but the shipped version has issues with MTP (connecting storage to PC).

So that is also not a workaround for everyone unfortunately but if you do not use MTP (USB mass storage works btw) this may an option for you.

Well so what is the

solution

?

Install sediROM v2.0 and use the latest sediKERNEL (default in easy installation mode) or the CM11 kernel (including the MTP fix) provided by bubor or the modified STOCK UCLJ3 kernel by xdajog (me).

All of them have no screen wakeup delay issues and working fine.

All are available in v2.0 and you can switch between them in the modify mode as always (sediKERNEL is default since v2.0)

[*]

What is that "Bluetooth HSP fix"?

Bluetooth HSP (HeadSet Profiles) is buggy in ICS 4.0.4. All paired devices gets lost after a reboot. In sediROM there is a fix for this implemented. To be honest that fix was the reason why I started sediROM..!

It is implemented in two steps:

a shutdown script which backups the bluetooth pairings and settings

an init.d script on boot which restores those pairings

The problem that pairings go to hell after a reboot is kind of special. The first thought was to simply backup the correct folders and restore them again when boot up. That alone won't work - the pairings will not shown up when enabling BT afterwards because they are deleted right when BT gets enabled. I tried to find out why but without success. Then I found a way by simply protecting the BT config file. That said when BT starts up it can not delete it anymore and stops trying that and that means the restored pairings will be read and shown.. A little bit crazy I know but it works very great (in my case).

Further Readings (they

may

related to this issue):

Kenneth Thorman's discoveries

Google Issue 34161

Some suggestions at stackoverflow (5885438)[/MENTION]

Another one from StackOverflow: 5102549

There are different

caveats

depending on which sediROM version you are using with the current implementation:

sediROM >= v1.7

Since v1.7 the BT fix is very stable and the caveats we have are absolutely minor:

Bluetooth will from now on always beeing OFF after a restart. That is wanted and nothing really bad and is a protection that things goes right.

After sediROM is up'n'running you can switch on BT and/or off again - only when rebooting BT will be always off again.

The system needs to be fully started in order to get BT working. As this is only a couple of seconds (about 10-20 sec) and starts while in boot process this has no impact for the user.

sediROM < v1.7

If you change the name in BT settings that will not be restored atm so it is sticked at "SGH-I927"

Under some circumstances the BT fix hasn't worked. check out the details at the bottom to find out the reason.

sediROM = v1.5 OR sediROM < v1.5

If you want to delete a pairing it was restored in sediROM <v1.5 when you reboot - to completely delete a pairing you need to:

in sediROM = v1.5:

You don't need to do anything. If you delete a pairing or add a pairing both will be saved and no need to do anything else then reboot.

In case you have problems you can delete /sdcard/.sediROM/btfix/00_btbackup.tar and/or check the logs in /sdcard/.sediROM/btfix/ . But that is normally not needed anymore.

in sediROM < v1.5:

delete "/data/local/tmp/00_btbackup.tar" and then reboot

Detailed background information

and the reason why before v1.7 it may haven't worked for everyone:

"rm" will delete the directory and I'm not able to find out which file will be deleted first and therefore I can't prevent the deletion of the pairings as I do before!

Background:

/system/bin/bluetoothd will remove the whole directory /data/misc/bluetoothd (well that is known and at the end the reason why the pairings gets lost in ICS)

I "fixed" that by making the config file immutable so Android is not able to delete the directory anymore which results in the fact that the pairings will stay!

Unfortunately it is not such easy as thought. On my second device I saw that my pairings still get lost..

Well ... As mentioned bluetoothd wants to remove and it uses "rm -r" for this. Exactly it will call "rm -r /data/misc/bluetoothd/".

.. and "rm" uses the C function "readdir()" when it parses the directory and readdir() will give you the result randomly (it depends on several not predectivable things).

There is no chance to know the exact order and even when it would be the case then mine would be different from yours!

... but that's not all. Some docs said that subdirs will be deleted first when using "rm -r" but in fact that is NOT true! If it would be true then the solution would be very easy.

The question stays why it happens on my productive phone and the previous fix still working fine on my DEV device. I believe that it is because I restored a previous made BT backup after I installed sediROM v1.6.

The command "tar" uses the same behaviour as readdir() so it is also randomly when it comes to restoring a backup. That would explain it maybe but I'm not totally sure.

You can test that readdir() behaviour very easily. If you execute a "find . -type f -print" you will see what readdir() see.. The result is obviously unsorted.

Execute it again and the result stays the same but that changes when files are deleted or other things happens to the filesystem!

In my case the problem occured after enabling encryption because that changes also things related to readdir() obviously.

Further readings:

- http://linux.die.net/man/3/readdir

- http://utcc.utoronto.ca/~cks/space/b...x/ReaddirOrder

- http://stackoverflow.com/questions/8...antee-an-order

The way of finding a solution:

- I tried to find out the root cause again (means bluez Java code).

- I tried to port the latest v4 of the bluez stack which contains a lot of fixes.

- I tried to re-compile bluetoothd in order to remove the whole folder deletion.

- I tried to save/restore the settings.db sqlite3 database (alone and together with the BT files)

- I tried some other stupid things.

The solution:

At the end I found a working solution (again). Instead of protecting a single file only which readdir() accesses randomly I switched over to protect the whole directory.

This way the order within the directory doesn't matter anymore

That alone wasn't enough. I needed to completely restructure the way of handling that fix.

That means:

- the bluetooth main.conf was changed to set InitiallyPowered=false !

- I stop all bluetooth related processes when booting

- I restore the previous BT settings and pairings

- I make the BT dir(!) immutable

- Then I give rfkill0/state the info (add a "1") that bluetooth is able to start

- Then I start all BT processes in correct order

- Then I remove the immutable bit from the BT dir

(Minimal) Caveats:

- Bluetooth will from now on always beeing OFF after a restart. That is wanted and nothing really bad and is a protection that things goes right.

After sediROM is up'n'running you can switch on BT and/or off again - only when rebooting BT will be always off again.

- The system needs to be fully started in order to get BT working. As this is only a couple of seconds (about 10-20 sec) and starts while in boot process this has no impact for the user.

[*]

What is that "adb" thing??

adb stands for: Android Debug Bridge and can help a lot when it comes to work with your device. It is not for developers only but they use it a lot of course.

But a normal user can use this to exchange files without the need of mounting, backing up the device, reboot the device and use it as a very comfortable way of having a terminal emulator.

Normally adb itself is not available as a standalone application - it comes with the Android SDK which is very big and heavy if you want to use adb and/or fastboot (another great tool) only.

But we live in a great world with many people wanting to make things easy so here you go when you want/need only adb and fastboot:

download & install adb at lifehacker

(Direct link for Windows users: Got to easy ADB install thread)

[*]

What is a "nandroid" backup?

nandroid means essentially: "a full image of all your partitions" so it is a full snapshot of your ROM including all your apps and contents.

The name NANDroid is a portmanteau of "NAND" (as in Flash memory - NAND flash) and "Android." (Source)

[*]

How to create a "nandroid" backup?

(See above for the meaning of "nandroid backup")

You have several options on how to do that.

The normal and absolutely recommended way is to do that "offline" (from within recovery mode) but you can also do it "online" (while Android is running).

.

Off

line nandroid backup by using TWRP recovery: Guide

If you have no custom recovery installed read on.

.

On

line nandroid backup:

by using an app:

There is 1 (known to me) "online" nandroid backup tool available which will backup from within your running Android: PlayStore.

I tested it and still using it since a while and I really like it but I would not fully resist on it.

I had no problems backing up but sometimes an app is lost when restoring. This may have been fixed but well it is like imaging a running Windows or Linux system:

Do not do it online if you can - it may/will work but there could be problems/inconsistencies later!!

If you never made a nandroid before doing it online will not harm anything and should be your first start. So install the Online Nandroid backup tool and begin.

Check out this guide for some hints: Guide

(If you like the Android app do not hesitate to buy the unlock key to support the developer!)

by using commandline tools:

First of all you need "adb" installed (check out the FAQ #8 above).

Then you need someone who is telling you the device partition table and you need a big sized SD card to hold the images.

The reason is that you will use a special command named "dd" which images the whole partition (not the content only!).

dd is a VERY dangerous tool because if you use it wrong your device may get bricked so it is essential that you are using the

correct command and check that twice!

Check out the next FAQ on how to do this for the

i927

.

[*]

How to create a "nandroid" backup for the i927/cappy - WITHOUT having a custom recovery?

The whole process will take a big amount of time but it is worth to follow each step including the md5sum checks at the end.

Please read the previous FAQ first because there you will find more information about background and other options you may have.

Ensure you have a SD card inserted which is big enough and having enough free space available (4GB at least! I recommend at least 8 GB but this depends on the size of your current data partition. A completely stock ROM with nothing installed and unused will need 3 GB space).

.

Install "adb" on your pc (check out the FAQ #8 above).

root your device (check out FAQ #12)

connect with adb to your (running) i927:

adb shell

(you should see a prompt)

su

(you need to grant permission if you haven't yet)

Then backup your current ROM and data:

Just to be sure you can do an online backup now, too ( Guide ) Online Nandroid backup App

.

copy the backup(s) to your device (connect USB cable - open your external storage and drag&drop) <---

DO NOT SKIP THIS STEP!!!!

It is absolutely essential!

Check your copy on your device:

Download a md5sum checker like this one Windows MD5 and load each file you copied to it (on Linux the "md5sum" command can be used of course).

compare the md5sums from the above output and ensure that they are all matching.

[*]

How to root the i927/cappy?

There are several guides on this here are 2:

- First or

- Second

[*]

"efs" backup and/or restore?

There are several guides on this but here is mine.

Backup

efs:

1) open a terminal

2) type in su --> now you may need to give root permissions

3) type in tar zcvf /sdcard/efs-backup.tar.gz /efs

4) type in dd if=/dev/block/mmcblk0p1 of=/sdcard/efs-dd.img

5) connect your device to a PC and copy both the efs-backup.tar.gz and efs-dd.img to your PC

6) now you have a full backup of your efs and therefore your phone unlock state

Step 2 is essential you need root for this in order to work.

Normally you can see a change from a dollar $ sign to a hash # one after root has been achieved like this:

xxxxxx:/ $ > su (answering the request for root permissions with yes)

xxxxxx:/ # >

Restore

previously saved efs:

1) open a terminal

2) type in su --> now you may need to give root permissions

3) connect your device to a PC and copy your dd-image backup "efs-dd.img" to /sdcard of your device

optional: do the same for the tar archive "efs-backup.tar.gz". This is just needed for the case the dd image is corrupt.

4) type in the terminal dd if=/sdcard/efs-dd.img of=/dev/block/mmcblk0p1

optional: if that step

fails

ensure you have mounted /efs (ls -la /efs should show you several files) and execute (press Enter after each line):

su

cd /

tar xvzf /sdcard/efs-backup.tar.gz

5) reboot your device

6) now your efs is fully restored and therefore your phone unlock state, too

Step 2 is essential you need root for this in order to work.

Normally you can see a change from a dollar $ sign to a hash # one after root has been achieved like this:

xxxxxx:/ $ > su (answering the request for root permissions with yes)

xxxxxx:/ # >

.