Develop Bugs

[Q] Building NBH from zImage

Finally managed to build a zImage, but now trying to build a *.nbh file with it. I've git both bootenv, tinboot, and also the latest kernel commit for 2.6.32.
Compressed initrd.lzma down to 1.1MB (original initrd.lzma was about 950KB, but with it, still got the error), and my zImage is 1.9MB, but I continue to get this error whenever I run this:
Code:
./compilekaiser
Code:
tinboot.S: Assembler messages:
tinboot.S:142: Error: attempt to move .org backwards
./arm-none-eabi-objcopy: 'tinboot.o': No such file
cat: tinboot: No such file or directory
=== yang v1.1: Yet Another NBH Generator
=== (c) 2008 Pau Oliva Fora - pof @ XDA-Developers
[] Output NBH file: KAISIMG-PANEL3-320-TILT4-FROYO.NBH
[] Input files: output.nb
[] Input types: 0x400
[] SignMaxChunkSize: 64
[] Device: KAIS****
[] CID: 11111111
[] Version: 1.0.MARTIN
[] Language: WWE
[] 0x400 --> output.nb
Done!
I've done some searches, and found that I have to decrease the size of my initrd, but not sure what else to strip from it, and also my zImage is base built, and the size really doesn't change whenever I change any options in menuconfig.

Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?

Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.

n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.
Click to expand...
Click to collapse
Thanks! Using the default initrd.lzma did the trick. Now if only the bootenv git was updated with this compressed initrd. xD
Currently using a custom kernel I built. Made some changes to yaffs2, mtd, and NAND configuration. Had a crash on initial boot, did a soft reset and phone came back with no corruption, and my "bad block 160" went away. I'm currently testing it for 24hrs, then if all goes well, I'm going to go a week and report back.
Though currently I have no bluetooth, as the module isn't loading.. Will look into that, and try and see if it's build related, and if the module can be loaded manually.

if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.

l1q1d said:
if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.
Click to expand...
Click to collapse
Currently bluetooth is not my concern, though I did get it running, by loading the modules manually using 'modprobe', but I have no idea how well the bluetooth subsystem works in its current state, but it does turn on, and do a search of nearby devices.
My main concern is my NAND configuration. So far no issues as of yet, but will know more when 1.5days elapses. Had an issue last night with the phone app crashing with acore failing, but coming back after rebooting the phone with no data loss.
Gmail app also crashed, but after 2 crashes it reloaded (possibly some data loss), and started re-syncing my email.
Besides those two, no real issues yet.

Krazy-Killa said:
Besides those two, no real issues yet.
Click to expand...
Click to collapse
What have you changed, just options in the defconfig?

scooter1556 said:
What have you changed, just options in the defconfig?
Click to expand...
Click to collapse
Enabled yaffs ECC support, but forced it to use the same ECC as the NAND driver. Enabled NAND ECC support inside the driver itself, as well as other changes.
Also left block refreshing, background processing, and left force chunk erase check enabled.
Had to disable EXT2, and EXT4 file system support to decrease kernel size, but for my case, don't need them as I'm using full NAND install anyways.
Currently approaching 18hrs, with no issues, installed more apps with no issues with corruption, still getting random FCs with core apps, but they re-enable afterwards (Most likely isolated, so not a real concern at the moment). Once i approach 18hrs, I'll do a safe reboot, and see what happens there.
My bad block 160 came back, but that's the only bad block that has returned, no new ones as of yet.
I'm hoping to concentrate my efforts on working on cpu scaling, whether it be using CPUFreq, or a kernel hack... I'm actually interested in knowing how Myn got his Rogue Tools to adjust the CPU Scale dynamically. As I'm thinking (though horrible at coding), of writing a kernel module to dynamically adjust the CPU core based on activity of the core.

If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App

n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App
Click to expand...
Click to collapse
I'll most likely contact Myn first chance I get. Been busy with family matters as of late.
Built a new kernel yesterday morning, and showing promise. Phone goes into a very deep sleep now (literally have to wait 5-10 seconds for the phone to respond like when a PC wakes from suspend), and actually shows improvement in battery life while in sleep mode but massive increase in battery usage when phone is waking, so may have to change how the phone sleeps.
Phone stability has increased as well. Despite the slow time it takes to wake, the phone has yet to crash, or slow down performance wise.
NAND is also showing improvement. Did a soft reset last night, phone restarted without problem, and no loss of data or any yaffs tragedy errors. Still installing apps at the moment. Data partition is at 45MB out of 101MB.
Free RAM is at 35MB while on home screen.
Currently using Radio 1.70.19.09, and HardSPL 3.56.
If all goes well, tonight I may post my kernel flavor as well.
*EDIT* Anyway that the bootenv git repo be updated with what's being used in initrd.lzma file?

Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App

tiagoclc said:
Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
Click to expand...
Click to collapse
Currently running into a problem with the acore being corrupted, which doesn't make since as it's in /system.
I'm testing out having CompCache running but not JIT, as each time acore gets messed up the JIT was enabled.
If all goes well tomorrow, I may post the updated kernel and and androidupdate.tgz file with modules.

n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
Click to expand...
Click to collapse
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Click to expand...
Click to collapse
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";

Can parted be moved from initrd to the android rom?
That saves a ton of space, and allows all to fit.

NO, parted is needed for atools - sd partitioner, i change both the 2.6.25 and the 2.5.32 to lzma initrd for it.

n2rjt said:
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";
Click to expand...
Click to collapse
I haven't had a problem with repacking initrd.lzma. I've kept mine below 975KBs, which is perfect for me.
Also as far as using what Rogue Tools uses, I've determined it wouldn't be a good system to code, as it requires to phone to sleep first before the new clock settings take effect.
I'll continue to look into the cpu coding, to find why scaling is not being recognized by the kernel. For now, I'm going to try and downclock the cpu core to 250MHz to see how much of a difference I get in battery life, but I suspect I won't get much since the voltage isn't being changed.

Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
Hi! Could you share what you did to slove the problem "tinboot.S:142: Error: attempt to move .org backwards".Thank you in advance.

Kernel plus initrd are too large if you get that message. First be sure your initrd is built with hardlinks to busybox. If that is still too large try fewer kernel features. For me, the standard kernel and bootenv fit. What sizes are the zImage and initrd.lzma files for you?
Sent from my Android on HTC Kaiser using XDA App

Man I need to read up on all the new Linux stuff... I'm so far behind I'm getting lost.
Personally I want to pack initrd and everything else into a package along with a singular build (current 2.2 8/25/2011) and just make one install package for everything. That way I can pack the install, updates and kernel into one kaisimg.
Keep up the good work guys!!!

The starting idea is wrong!
The multiple file: the nbh for kernel and initrd and the tgz file are setted up for large compatibility (multiple device use them). So creating a nbh only for kaiser is a bad idea.
Also you need to create a nbh for every single parameter in atools (like screen, keyboard, panel) it's crazy!

[ROM][ICS] sediROM - current inside - stable - smooth - rooted or not-rooted

|
|
| sediROM - or why I created a new ROM based on good old (ancient) ICS
|
|
| Read the background and the whole story and all the discussions about sediROM here:
| http://forum.xda-developers.com/showthread.php?t=2789119
|
|____________________________________________________________________________________________
Some first words:
A lot has changed since I forked LiteROM v0.9 in May 2014 and therefore started sediROM. sediROM has grown up in the meanwhile to a standalone ROM with some mods coming from LiteROM but in comparison to the current state of sediROM they are not many anymore.
LiteROM was a very good starting point for me to dive into ROM development and doing my first steps here so many thanks going to thegreatergood, of course.
As a result of that learning process I will change the base of sediROM in one of the next major releases (see Roadmap) to remove the rest of LiteROM stuff which I do not need/use anymore.
Summary:
Debloated, Partially De-odexed, Zip-aligned, SuperSU, Busybox, Init.d Support, Tons of Memory and Build.prop Tweaks, Sysctl Tweaks, 14 toggles Mod, Power Menu, Tethering fix and more...
Aroma Install
Customizable Apps, Tweaks, Mods
BLN Support
Selectable Kernel, Modem, Bootanimation
No Samsung backdoor inside!
Full Feature List:
Explanation: Default values in "Easy Installation" mode are marked in the following lists in RED
Installer:
sediROM flashing will be done by AROMA installer which gives you 2 selectable modes when starting:
Easy Installation:
This will do all the hard stuff for you and installs besides the ROM itself well tested preselected apps & enhancements.
You need to choose this mode when you install sediROM the first time or want to install an upgraded version of sediROM.
Default values in "Easy Installation" mode are marked in the following lists in RED
.
Modify Installation:
This mode needs an existing sediROM installation first. So you can choose the Easy Installation mode first and after that has finished simply choose this mode to modify things like the Kernel, Modem whatever. This mode can be choosen whenever you want - e.g. you can test a Kernel X and after a while you want to test another one - no problem - simply restart the Installer and choose the Modify Installation mode!
Available Kernels:
sediKERNEL v1.0 (Kernel 3.1.10) (see changelog for details)
CM11 based (Kernel 3.1.10)
JB 4.2 LiteKernel release-20130222 (see changelog for details)
JB 4.2 LiteKernel release-20130221 (see changelog for details)
LiteKernel v1.2.2 GPU not OverClocked and with UnderVoltage
LiteKernel v1.2.2 GPU OverClocked and with UnderVoltage
LiteKernel v1.2.2 Original LiteRom v0.9 Kernel.Tweaked - LiteKernel v1.2.2 overclocked with UnderVoltage
LiteKernel_l2hsicpatched-bubor-r20150506 with L2_HSIC patch based on code of 2014-04
Stock ICS Kernel UCLJ3 (Kernel 3.1.10)
Enhanced UCLJ3 stock Kernel
enhancements:
- init.d support (this enables sediROM bluetooth fix for this kernel)
- added custom boot animation support
Stock ICS Kernel UCLH2 (Kernel 3.1.10)
Available Modems:
UCLJ3
UCKL1
UCLH2
UCKI3
RUXKJ5
Some meaningful Apps & Tools:
ATOM launcher
Several other launchers available in "modify" mode (Apex, Nova, ADW, Stock)
Ghostery, Quickpic, ES File Explorer, AndroidTerm, Vodoo Sound Control
Camera apps: Open Camera, HD Camera Ultra, Stock, ICS, JB)
Kii Keyboard, Samsung Keyboard (default enabled), Go Keyboard, Stock Keyboard
"Under the hood" - Integrated Features:
The possibility to execute shutdown scripts (and for boot-up but every Kernel in sediROM supports that out-of-the-box)
The possibility to choose a non-rooted mode! If you're running Apps which detects root (and hiding is not possible) or if you want to be most secure than this mode is for you. Enterprise users may want this to be complain with their security policy e.g.
(Major) Bugfixes (related to ICS and/or LiteRom):
That was driving me nuts and costs WEEKS to fix -> BT fix (better a fully working workaround) for loosing paired devices after a reboot!!!
Lags/waits when pressing the power button to switch the display on
Within Aroma installer: Many many fixes and enhancements when modifiying or/and installing the ROM to get the most out of it
There are many other fixes which can be found in the full changelog
Device encryption was not working in LiteROM. That was fixed in sediROM since v1.1.
Known issues:
Check the open bug reports for a complete list: Click
HOW-TO flash & Download:
Disclaimer:
sediROM is not fully finished nor bugfree (yet).
[*]But is has less bugs and more features then it's fork "LiteROM" and fixes bugs within stock ICS as well.
[*]I use it continuesly since 1th of May 2014 and sporadically developing / enhancing sediROM since then.
Installing sediROM may result in several explosions in your garden (or in that of your neighbour) .. you have been warned!
DO NEVER USE OPTIONS WHICH ARE MARKED AS "TESTING" IN THE INSTALLER!
I'M NOT RESPONSIBLE IF YOU BRICK YOUR PHONE (nor the things that happens to your house and/or car!)
Requirements:
Do a nandroid backup and ensure you have an EFS backup, too !! EFS: (http://forum.xda-developers.com/showthread.php?t=2019540)
COPY THAT BACKUP TO AN EXTERNAL DEVICE TOO !!!! --> SAVED MY DAY TODAY BECAUSE OF MD5 MISMATCHES THAT CAN HAPPEN.. (I cannot recommend that "fixes" cursing around to simply workaround MD5 sum checking! If the md5sum mismatch you should NOT restore IMO. That may simply not work or can result in bad behaviour etc minutes later or some days later)
Check your backup! (e.g. md5sum -c nandroid.md5) in BOTH places (on the Glide AND on your external ressource)
Install TWRP(!) or migrate to it! DO NOT USE CWM - flashing may fail with CWM (and is besides that not recommended).
DL- Link CWM: CWM v6 (click) (several users reported CWM will not work! use TWRP!)
DL- Link TWRP: twrp v2.7.1 (click)
You should have a windows box running Odin + TWRP near - just for the case.
Flashing Guide:
I'M NOT RESPONSIBLE IF YOU BRICK YOUR PHONE (nor the things that happens to your house and/or car!)
Copy BOTH the sediROM zip AND the sediROM md5 file to your Glide!!
Boot into Recovery mode (Poweroff the device then Power on while holding Volume Down)
Ensure that you use TWRP and that the MD5 sum file is in the same directory as the sediROM zip! Only then TWRP will automatically check the MD5 !
Flash the latest sediROM zip file
Choose "Easy Installation" mode
Answer the few questions and wait until the flashing finishes
When finished - reboot and wait until it has fully started up
The Android setup wizard should come up (if not -> flash again
Go through the wizard and reboot once again afterwards
Enjoy
Please read the FAQ (click)!
Please file a bug if you encounter problems: File a bug (click here)
Download:See above in the Download Menu (click here to open it)http://forum.xda-developers.com/devdb/project/?id=4942#downloadshttp://forum.xda-developers.com/devdb/project/?id=4942#downloads
Mirror:
Use this ONLY when the above xda DL does not work!! Mirror Downloads may be outdated or not available all the time! Mirror-Link <-- DOWN. Write me a PM if the xda download does not work and I will upload it for you
Take also a look on:
Changelog
FAQ
Roadmap
Trouble
File a bug
Request a feature
Best regards
xdajog
Special THANKS (please give them a Thanks-Click ! That costs you nothing but 2 seconds (for each)!!)
thegreatergood for LiteROM v0.9 and LiteKernel builds --> Give a "Thanks" here
bartito for Shutdown-Script option (and therefore the possibility to fix the BT issues!!) --> Give a "Thanks" here
PS: Happy for every single click on my "thanks" button (you are free to do that on the changelog, roadmap and faq post again... )
And as an absolutely premiere I want to say thank you to maddbomber83 for the donation.
You're the first one (until now the only one ) who say thx this way. Highly appreciated and motivating.
Sources:
sediROM --> https://github.com/xdajog/android_i927_sediROM
sediKERNEL --> https://github.com/xdajog/kernel_samsung_i927
.
XDA:DevDB Information
sediROM, ROM for the Samsung Captivate Glide
Contributors
xdajog, bubor (for all his work! highly appreciated!), maddbomber83, organic2 (for heavy testing!)
Source Code: https://github.com/xdajog/android_i927_sediROM
ROM OS Version: 4.0.x Ice Cream Sandwich
ROM Kernel: Linux 3.1.x
ROM Firmware Required: sediTWRP or TWRP >= v2.7
Based On: STOCK, LiteROM
Version Information
Status: Stable
Current Stable Version: v2.1 (2.1.2)
Stable Release Date: 2016-01-04
Current Beta Version: ---
Created 2014-07-11
Last Updated 2016-07-26

FAQ
Frequently Asked Questions (FAQ)
Why another ROM and why build on ICS?
Please read the full story here: http://forum.xda-developers.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 @maddbomber83:
maddbomber83 said:
Just as a note; upgrading an install that has a lot of symlinks (such as L2SD) does not appear to be working properly. If your install includes any of these then as the Developer has stated, MAKE SURE TO DO A NANDROID BACKUP!
On mine at least, the phone had a lot of FC errors focused around the PHONE APK. If you did do a data wipe and can get back into your phone but are missing your linked apps then:
Q. I upgraded/changed my ROM and I can not see my linked apps, their files are on the 2nd partition but the system can not see the apps. How can I make them available, do I need to reinstall and relink them again?
No, if you didn't wipe data when updating ROM the only thing you need to do is to run "Recreate mount scripts" from "menu -> more" within Link2SD and do a normal (not quick) reboot.
If you wiped data, after executing "Recreate mount scripts" and rebooting, run "Relink all application files" from "menu -> more" and then reboot. All of your linked apps should be available again after reboot.
If you also wiped dalvik-cache, in addition to the above step run "Link dalvik-cache files".
Click to expand...
Click to collapse
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).
.
Offline nandroid backup by using TWRP recovery: Guide
If you have no custom recovery installed read on.
.
Online 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:
dd if=/dev/block/mmcblk0p2 of=/storage/external_SD/system.2015-07-20.img
dd if=/dev/block/mmcblk0p9 of=/storage/external_SD/boot.2015-07-20.img
dd if=/dev/block/mmcblk0p6 of=/storage/external_SD/userdata.2015-07-20.img
dd if=/dev/block/mmcblk0p8 of=/storage/external_SD/recovery.2015-07-20.img
# If you never backed up your EFS you really should do that once:
dd if=/dev/block/mmcblk0p1 of=/storage/external_SD/efs.img
Click to expand...
Click to collapse
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:
md5sum /storage/external_SD/system.2015-07-20.img
md5sum /storage/external_SD/boot.2015-07-20.img
md5sum /storage/external_SD/userdata.2015-07-20.img
md5sum /storage/external_SD/recovery.2015-07-20.img
md5sum /storage/external_SD/modemst1.img
md5sum /storage/external_SD/modemst2.img
Click to expand...
Click to collapse
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:/ # >
.

Changelog
Changelog of sediROM
v2.1.0 - v2.1.2 (Release date: 2016-01-04)
--------------------------------------------------
Bugfix Release
Github detailed changelog (compared with the previous version):
https://github.com/xdajog/android_i927_sediROM/compare/v2.0...v2.1
Github tag for this version:
https://github.com/xdajog/android_i927_sediROM/tree/v2.1
Enhancements
introducing sediROM testsuite: /system/xbin/sediROM_testsuite.sh
execute it like this to test if your sediROM version is fully working:
adb push sediROM_testsuite.sh /sdcard/ && adb shell "su -c sh /sdcard/sediROM_testsuite.sh"
Fixes
issue #25 (https://github.com/xdajog/android_i927_sediROM/issues/25)
YES ALL THE FOLLOWING IS > 1 < SINGLE RELEASE
v2.0.68 -v2.0.1 (Release date: 2015-12-29)
--------------------------------------------------
Major Release
Github detailed changelog (compared with the previous version):
https://github.com/xdajog/android_i927_sediROM/compare/v1.7...v2.0
Github tag for this version:
https://github.com/xdajog/android_i927_sediROM/tree/v2.0
Enhancements
first sediROM app (sediROM_boot.apk) inside.. the app itself is extremely simple: a text and a button thats all. When
sediROM boots the first time a new added init script will detect if this is the first boot and if this is the case it will open
the sediROM_boot app. Read & follow carefully the hints there!
you to reboot. May be annoying but due to douzends of changes in v2.0 it is really necessary to point to a clean reboot.
All scripts related to run sediROM on github now !!!! Starting from v1.7.
Introduced the first version of sediKERNEL (v1.0) a customized kernel optimized for STOCK ICS so as for sediROM.
sediKERNEL is based on CM11 kernel made by bubor (so l2_hsic patched, no wakeup delays, OC etc) enhanced by:
- adding MTP support for STOCK ICS!
- less battery drain
default kernel = sediKERNEL v1.0
Upgraded AROMA from v2.56 to v2.70-RC2 (means compiling 2.70rc2 from the sources!)
Go DIRECTLY from the installer to the MODIFY mode!
That means when you choosen the easy installation mode and everything went fine you will get the
offer to open the modify mode instead of rebooting
No adb debugging from initial ram disk (security fix)
No adb debugging as default (security fix)
Integrated LiteKernel_l2hsicpatched-bubor-r20150506 with L2_HSIC patch included (hopefully fix battery drain)
The kernel is based on code of 2014-04 afaik also maded by bubor
Integrated enhanced UCLJ3 stock Kernel (option in modify mode)
enhancements:
- init.d support (this enables sediROM bluetooth fix for this kernel)
- added custom boot animation support
Migrated and integrated JB 4.2 LiteKernel release-20130221 to sediROM (option in modify mode) which comes with the following changelog:
(all changes between v1.2.2 to 20130221)
- Interactive set as default governor ... Wheatley lags on AOSP
- Added FM Radio Driver
- Fixed Mic for AOSP
- Fixed/Added 1.4ghz frequency
- Fixed/Added Smartassv2
- Removed USB Whitlists
- Recoded BLN myself so that there is no need for an app... has in kernel blinking ...
- Tons of Cleanup
- XZ Kernel Compression
- Removed Wake Lag
- Fixed and increased Charging Current
- Tweaked Ondemand for better performance
- New Storage Setup
Migrated and integrated JB 4.2 LiteKernel release-20130222 (option in modify mode) which comes with the following changelog.
HINT: MTP does not work with this kernel. I will not fix that! If you need MTP use release-20130221 or sediKERNEL!
(all changes between r20130221 to r20130222)
- Entropy Tweaks inspired by lambgx02s Seeder (for silky smoothness)
- Memory Managment Tweaks
- Added Dynamic vsync
- Zipaligning and Fix permissions at boot (zeppelinrox script)
- Tons of Kernel Tweaks for Battery life and Performance...
- IO tweaks...
- Auto EFS Backup...
- New Experimental WIFI Management battery saving feature: If at screen off, WIFI is inactive and or using very little traffic, it gets turned off
and then on again once you wake device, if battery level is below 50% it will no longer turn wifi on again, if you disable WIFI it will be left alone...
- Decreased Vibration Intensity (when you boot up device you will feel a slight vibration)...
- New Experimental CPU Management feature: Frequency get changed according to battery level....
- No more laggy lock screen drawing ...
- Instant wake to lock screen
- Removed Increase Charging Current mod till more testing can be done
- Improvements for better battery life
- Stability
- Option to Disable WIFI and CPU Control
- Clear Memory after boot
- Massive Improvements to: Performance, Battery Life
- Fixed Battery leak with CPU + WIFI manager
- Memory Management Improvements
- SD card Speed Tweaks
- Reduced Wake Lag
- Reduced Stuttering when playing music on screen off
- CPU-Manager is now enabled by default ... it boosts wake speed manages sleep speed and reduces max speed as your battery diminishes ... the profiles are fully modifiable and all with no battery drain ...
- MTP is now the default pc connection ... if you want mass storage change /data/LiteKernel/MTP to "0"
- Memory management improved .... should also help for battery life
- frequency with Interactive governor will now stay a little lower ... should help with screen on battery life ....
crond (provided by busybox) activated to automatize things like in Linux
init script 00sediROM will prepare the settings, paths etc for crond to start
and init script 99sediROM will start the crond
Open Camera will be the only camera app installed by default. HD Ultra camera stays an option in modify mode.
added this changelog to AROMA installer screen
added modify option after easy install in README of the installer zip
updated sqlite3 binary to v3.8.7.4 (THANKS to user tech128 details: http://forum.xda-developers.com/showpost.php?p=52174054)
Removed all my own copyright hints and licensed all sediROM scripts under CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0) license! Freedom for everyone ;o)
New script header including new version concept of all sediROM scripts
Updated SuperSU app and binaries to v2.46
Installation of SuperSU is now completely based on the original installer to avoid any problems while installing
Added a new minimalistic terminal app AndroidTerm (https://play.google.com/store/apps/details?id=jackpal.androidterm) which replaces connectbot as default installed terminal app.
Connectbot will not being installed by default anymore but you can still install it in modify mode.
Connectbot has many advantages but 1) updating within a ROM is harder then with AndroidTerm and 2) I want to keep it minimal so no ssh, telnet. only a local console.
BACKUP Connectbot before upgrading when you still want to use it.
If you want to continue using CB you can upgrade and at the end of the installer select "Start sediROM modify mode"
and install Connectbot directly after installation (Screen "Main Features" - Section "Tools"). Nevertheless you still need to restore your settings as they are lost.
Added Ghostery (v1.2.1) - a very tiny (around 2 MB installer files), fast, stable and anonymous browser (https://www.ghostery.com/en/how-it-works). Will be installed by default!
Removed Google Chrome to save disk space (the installer files are 64 MB!)
Chrome is VERY slow on our phone in comparison to other browsers (try to open several tabs & browsing) and last but not least updating it within sediROM is harder then with other browsers.
BACKUP Google Chrome before upgrading when you do not want to loose settings.
Started to use a common function file for the init scripts in sediROM (/system/etc/sediROM/init.func)
Several new boot logs are written to /cache/*.debug which makes debugging easier (commit b053e738 and commit e3fe9332).
After sediROM is booted fully up everything will be moved to: /preload/.sediROM/boot/.
Added commandline aliases/shortcuts for remounting any mountpoint as read-write (remountrw) or read-only (remountro) - handled by commit 41fcc3c6.
Added automatic /efs backup !!!
- The backup is a full image dump made by dd
- backup will be saved to /sdcard/efs_[current-date].dd
("[current-date]" will be replaced by the current date+ unix timestamp)
- if somehow no timestamp could be generated the sediROM version number will be used instead
- if the backup fails we will CONTINUE! That means the installer will not abort to ensure that you will not end with an unused device
That also means that you should not rely on that efs backup it is a help for those not familar with the CLI only.
Added a "getdate.sh" script in aroma installer to filter tzdata errors
Added a sediROM bootanimation (NSA) and made it default
Removed facebook installer files from sediROM zip (was unused since the beginning) which frees some space of the ZIP
Fixes
on first boot bluetooth will be enabled once. This is needed to ensure that /data/misc/bluetoothd/MAC-ADRESS will be created.
That directory is device specific and will be created by Android when not existent. As the bluetooth fix from this version on
depending on a indicator file within this directory it is necessary to enforce its creation by enabling bluetooth once.
This is done within the init script 00sediROM_1stbootDT.
(!) whenever a soft reboot or system force close has happened bluetooth has stopped working. The only workaround was to
reboot the device. A fix was added which checks every minute if the bluetooth indicator file is there and if not the init
script for fixing bluetooth will be restarted. This way in worst case scenario of a soft reboot crash after 1 minute latest
Bluetooth becomes usable again (so no reboot anymore needed).
Changes:
- /etc/cron.d/root
Added:
- /system/xbin/sedi_btFCdetect.sh
fixing some problems with encrypted storage detection
due to a timing issue some early logfiles of sediROM were not got written to /sdcard. The fix was to use /preload instead:
When sediROM boots the init script 00sediROM_first will try to mount /preload.
If mounting /preload was successful it will be used for all logs and existing data will be moved to /preload.
It would be nive to have a symbolic link here but this is not possible across different filesystem types. So there will be
an indicator created in /sdcard/.sediROM with the hint to goto the /preload for logs instead.
All scripts within sediROM were modified to check for the existence of this indicator file and dependending on that they use
/preload or /sdcard for their logging data.
(!) when a soft reboot occured the bluetoothd directory gets trashed, too. If you then rebooted the empty bluetooth settings gets
backed up and therefore you boot with emtpy BT settings. This was fixed by using an indicator file (btfix.indicator) which
will be added after booting the first time. When a system shutdown is initiated sediROM will check for this file and as a
soft reboot would also delete that indicator file it will detect this and backup when this indicator file is still there.
In other words: when a soft reboot has occured you can safely reboot now and your settings will be there on the next reboot and
not lost.
cosmetics within updater-script output and AROMA
(!) Extreme battery drain caused by Google Play Framework Service.
This fix is a big one and splitted into 3 parts:
1) When system booting up /system/xbin/sedi_fix-gplay-drain will be triggered by /system/etc/init.d/00sediROM_first
2) /system/etc/init.d/00sediROM_first will also enable the cron daemon crond (coming with busybox) so we can automatize things
"enable" crond means several things need to be setup first:
a) creating a /etc/passwd
b) creating /etc/cron.d/
c) starting crond as a process
3) With the now introduced crond we can run the script /system/xbin/sedi_fix-gplay-drain every 8 minutes.
This is to ensure that even when Google updates (this will be done SILENTLY! by Google) it's app(s) it will be fixed again on the next cron run.
/system/etc/cron.d/root contain's the magic line for that.
For details checkout the original thread here:
http://muzso.hu/2014/09/18/how-to-f...yanogenmod-11-with-google-play-services-and-o
http://forum.xda-developers.com/showpost.php?p=53881089
http://www.imoseyon.com/2011/02/cron-on-android-is-awesome.html
init.d scripts cleanup. 00sediROM_tweaks in the installer package under /system was never used because always replaced by the BTfix one.
I moved the both scripts 00sediROM_first and 00sediROM_last to /system/etc/init.d/ instead of havin them within BTfix.
All this is firstly cosmetic only but becomes more and more important to have things clear for coding.
Removed the option to install Cranium & IcePop Bluetooth (was for testing purposes only)
compat linkage when coming back from JB now respecting it's existence. That means it will check first and do the links when needed only.
RNGD's init script was blocking for 30s the next boot scripts (changed to 3s intervalls)
changed order for the BT fix init script (from 99 to 92)
the 00 sediROM init script was not respecting encryption state which itself is not a problem but as the switch to /preload is happening in this
version this has result in problems. The fix was to check for encryption state and /data/misc before proceeding
fixing enhancing databases coming with init script 16sqlite:
- sqlite3 binary was not working (since literom days....!) and therefore replaced!
- when /data and/or /sdcard is encrypted no enhancements had taken place (now respecting encryption state and wait until decrypted)
installer: When FULL-wiping all init scripts were not executed because of missing /preload/.sediROM and /sdcard/.sediROM. Those directories are
created by the installer now or when they exist the following files gets deleted instead:
- /preload/.sediROM/.initialized
- /preload/.sediROM/dir-moved-2-preload.txt
- /sdcard/.sediROM/.initialized
- /sdcard/.sediROM/dir-moved-2-preload.txt
installer: When PARTLY-wiping all init scripts were not executed because of missing /preload/.sediROM and /sdcard/.sediROM. Those directories are
created by the installer now or when they exist the following files gets deleted instead:
- /preload/.sediROM/.initialized
- /preload/.sediROM/dir-moved-2-preload.txt
- /sdcard/.sediROM/.initialized
- /sdcard/.sediROM/dir-moved-2-preload.txt
BETA-related (fix affects BETA release only): litekernels in modify mode could not be installed (therefore may soft bricked the phone!)
RFKILL switch desc added inside 92sediROM_btfix, slightly modified the log output too
(!) Not everything was cleaned/removed when UN-ROOT was selected. The uninstallation/unrooting will remove all related parts now including dalvik cache etc.
daemon mode in install-recovery.sh makes no sense in sediROM as it is not SDK 18+ and no selinux forced therefore removed
When switching the kernel the modules within /system/lib/modules/ were not deleted (e.g. dhd.ko) which could had caused trouble in rare situations.
The installer now deletes all modules when switching to another kernel
BETA-related (fix affects BETA release only): new sediKERNEL version (v1.0 build 50). Change: wifi as kernel module instead builtin.
On encrypted devices the installer was not able to mount /data and /sdcard. Now it will:
- check for the existence of dm-0 and dm-1 which are the unlocked /data and /sdcard partitions
- when they can be found they will be mounted and used accordingly and correctly
- when they can NOT be found an abort is raised to avoid data loss - 3 hints are given to solve the situation
- you N--E--E--D sediTWRP - Clockworkmod cannot unlock encrypted devices and "normal" TWRP versions are not able to unlock STOCK ROM encryption!!
--> sediTWRP can be downloaded here: http://forum.xda-developers.com/showthread.php?t=3007035
installer: When upgrading / partial wiping the system partition will be deleted at the END now. This is to avoid data loss e.g. when you have an encrypted
device and not unlocked the partitions in sediTWRP (or when using CWM or other "normal" TWRP versions)
installer: When normal installing / full / recommended wiping the system partition will be deleted after successful mount of /data and /sdcard first.
This is to avoid data loss e.g. when you have an encrypted device and not unlocked the partitions in sediTWRP (or when using CWM or other "normal" TWRP versions)
installer cosmetics:
- Easy installation description changed
- "Recommended Wipe" renamed to "Clean install / Recommended Wipe"
- "Partial Wipe" renamed to "Upgrade mode / Partial wipe"
fixes an issue where Android goes into a boot loop in rare circumstances (issue #11). In rare cases several XMLs will be zeroed out by Android when not shutdown cleanly.
Those XML files still be there but they are empty! When Android boots up it tries to open those XMLs and as they are empty the whole boot process will hang!!!
I fixed this by:
- adding a new function which searches for all opened /data/system/.*xml files after a given period of time
- after this time period a file size check will be made: if the open xml is 0 it will be renamed
- when a renaming happened the parent process will be killed to ensure the boot process will not stop
moved the first boot detector to the near end of the boot process instead! That may fixes other issues as well regarding displaying the first boot app
better integration of the wait for system readiness while booting up (commit d0970abf6ec6c65af9999e2428b96fe293a55f17).
bluetooth file exchange was not working since a change in audio.conf
content in installer welcome screen
modify mode: when no kernel was selected the radio/modem force selection dialog appears
modify mode: removed several hard coded preselections
modify mode: modifying failed under some circumstances which resulted in aborting and may have left you with an unusable device
For older releases see attached file (View attachment CHANGES.log) !
Click to expand...
Click to collapse
Dev facts
sediROM v2.1 (Bugfix Release)
Development duration: about 8 hours
Finished on: 2016-01-04
Builds taken: 3
Changes: 2
sediROM v2.0 (Major Release)
Development duration: about 304 hours
Finished on: 2015-12-29
Builds taken: 69
Changes: 64
sediROM v1.7 (Important Bugfix Release)
Development duration: about 68 hours
Finished on: 2015-02-02
Builds taken: 7
Changes: 6
sediROM v1.6 (Important Bugfix Release)
Development duration: about 24 hours
Finished on: 2015-01-08
Builds taken: 22
Changes: 11
sediROM v1.5 (Big Maintenance Release)
Development duration: about 67 hours
Finished on: 2014-12-24
Builds taken: 24
Changes: 21
sediROM v1.1 (Bugfix Release)
Development duration: about 28 hours
Finished on: 2014-10-21
Builds taken: 15
Changes: 8
sediROM v1.0 (First Stable Release)
Development duration: about 640 hours!
Finished on: 2014-09-02
Builds taken: 58
Changes: more than 82
Click to expand...
Click to collapse

Trouble?
Trouble after flashing?
For EVERY request you have to upload the install log:
after every installation an automatic logfile will be saved to /sdcard/install_sediROM_vX.x.x.log where vX.x.x is the sediROM version number. Upload that log to pastebin and give me the URL.
Flashing failed? or Download mode always coming up?
Download rooted stock ICS http://forum.xda-developers.com/showpost.php?p=30421243&postcount=1
Go in download mode
Open Odin in Windows
Select Auto-Reboot and nothing else and add in the PDA section the above ROM (unzip first - you need the tar.md5 inside)
When it finishes your Glide should reboot (and Odin should say PASS). You do not need to wait if it is fully booting up and you can reboot once again in the download mode
Open Odin in Windows again
Flash TWRP (pretty nice gui, better handling, charging while active) or CWM (ugly gui, more robust, will NOT charge while active) over the PDA slot again (see flashing guide above for DL links)
(I use TWRP and several reflashings etc and it is working fine for me - but keep in mind that Nandroid backups are NOT compatible between those both recovery tools so choose the one you had before. I can highly recommend that you switch to TWRP when you currently using CWM because the handling and features are great (besides flashing probs of course)
For those who need more details and screenshots etc: http://unbrick.itcse.com/unbrick-soft-bricked-samsung-captivate-glide-sgh-i927/
"no recovery kernel" displayed when trying the recovery menu?
That is easy to solve when you know the correct partition name.. That is for the glide "LNX".
On Linux: Start heimdall or heimdall-frontend and simply flash a kernel back. For this you need a pit file which need to be catched first:
Download PIT:
Code:
$> heimdall download-pit --output mycurrent.pit
Flash the kernel with that catched PIT info: (Click to see an image of the heimdall frontend)
Flashing itself failed? Corrupted image message or /cache mount failures?
Flash with TWRP instead of CWM! See the OP for the DL Link (section Howto & Download)
loosing signal / bad signal ?
In my case I had sometimes problems with my baseband (loosing signal / bad signal) which was silly.
I found out that this was not ROM related because happens with several ROMs and total random.. Because of that randomness it was first hard to say if it is ROM/Modem based or not.
So if you come in such a situation and a modem change does not help I can recommend to open you Glide's back and check the SIM..
Sometimes (not often) it can be easy: In my case a little tape fixed my problems with that because the SIM is hanging very lax in it's case..
Maybe that little trick helps others, too

Roadmap
ROADMAP FOR sediROM
I never promise that a requested feature will be in a specific version or even added!
But you can add your ideas and wishes here if you like:
Open a Feature request (click here)
If you find a bug then it is your absolute responsibility to file a bug.
You can do it here: >CLICK HERE<
Version X.x
The Roadmap has been completely moved to github:
Github Milestones
upcoming features/enhancements need to fulfill at least one of those:
Fixing a (real) bug or serious problem
Performance optimization
Battery optimization
System optimization or stability
Even if your request met one ore more of those requirements I will decide on my own if it will be added or not.
If you don't like that you're free to create your own ROM
On the roadmap the base of sediROM was planned as UCLJ3 but to be honest according to the thread poll () I will look into the base question before starting v3 again.
The poll result is clear: It has to be stable - I don't care about the base
So I'm free to decide I will look into the issues CM9 has and compare them with UCLJ3 and then I will decide which will be the base at the end.
If someone is willing to help - let me know your results, analysis!
sediROM BETA download area / file exchange
http://tinyurl.com/pv7utvl
(password protected - PM me to get access)

Great!!! :laugh: Downloading tonight! :fingers-crossed::fingers-crossed::fingers-crossed:

It's great to have so many choices for people to choose from
I've added this to the guide of course ;D People would love using this ROM because you can be close stock and have the stability of a custom ROM!
Also I would like to remind people if you cant post bugs in the dev section,post what ROM your using and bug in my thread so we can figure it from there

Waiting for the link:thumbup:
Sent from my HTC6435LVW using XDA Premium 4 mobile app

I believe sediROM's installer is the main show stopper atm.
but as now it is good enough to state as alpha because it is working fine in my tests (tested preseleted config only) and therefore if someone wants to help me - even when it is still a risc - write me a PM.
... and I cannot say it often enough:
DO A NANDROID BACKUP
COPY THAT BACKUP TO AN EXTERNAL DEVICE TOO !!!! --> SAVED MY DAY TODAY BECAUSE OF MD5 MISMATCHES THAT CAN HAPPEN..
ENSURE THAT YOUR BACKUP IS FULLY OK (e.g. md5sum -c nandroid.md5) in BOTH places (on the Glide on on your external ressource)
You should have a windows box running Odin + CWM6) near - just for the case. TWRP is not such bulletproof then CWM in my case..
regards
xdajog

This is great! Thank you all for the continuing support for our Glide!
Sometimes ancient is better when it was made with at least some support from the manufacturer. I'm still running GB based OsiMood as I haven't found a better alternative (because of Samsung's non-existant support for our great devs).

Yeah today I shot a used Cappy. That will be much easier for development when not needing to use my productive device. Will be here in 2 weeks..
Sent from my SGH-I927 using XDA Free mobile app

THat Rom can install in Roger?
Sorry My English Not good

joedeng said:
THat Rom can install in Roger?
Click to expand...
Click to collapse
yes it will work on Rogers variant, too. But I cannot recommend to use sediROM when you do not have good enough english skills to understand what you need to do in case of trouble.. You need to know how you can rescue your system in case of error or problems.
I wrote a very basic troubleshooting guide in the original post of this thread.
If you still want to try write me a PM and I provide you the download link to the current testing version (v1.0.18) of sediROM.
regards
xdajog

xdajog said:
yes it will work on Rogers variant, too. But I cannot recommend to use sediROM when you do not have good enough english skills to understand what you need to do in case of trouble.. You need to know how you can rescue your system in case of error or problems.
I wrote a very basic troubleshooting guide in the original post of this thread.
If you still want to try write me a PM and I provide you the download link to the current testing version (v1.0.18) of sediROM.
regards
xdajog
Click to expand...
Click to collapse
I do not generally write good English but I can understand. That the rom of your development from LiteRom v0.9 rom right? On the status bar has percent battery and 14 toggle it? If the trial is still okay, right? just as there were some errors when spending alone is not
p/s Finally i will try it, you get me your link, i will test it ^^

joedeng said:
I do not generally write good English but I can understand.
Click to expand...
Click to collapse
ok just wanted to be sure that you know what you're doing
That the rom of your development from LiteRom v0.9 rom right?
Click to expand...
Click to collapse
Yes it is based on LiteROM v0.9 as stated in the OP. (Well atm I'm currently re-thinking this and testing a complete new build on stock ICS instead of LiteROM).
On the status bar has percent battery and 14 toggle it?
Click to expand...
Click to collapse
yes to both
p/s Finally i will try it, you get me your link, i will test it ^^
Click to expand...
Click to collapse
You have a PM

Hey i have already install your rom. It awsome, but you can add some more app. Example click Volume Up or Down wake phone. Get some launcher LG, Samsung, Sony...More theme. recent app, status bar add slide brightness......

Today i have test, it can not share file via bluetooth...Stock ROm can do it. But Your Rom can not share file via Bluetooth....

joedeng said:
Today i have test, it can not share file via bluetooth...Stock ROm can do it. But Your Rom can not share file via Bluetooth....
Click to expand...
Click to collapse
From your device to another one or
from another one to your one or
in both direction?

Call for enhancements for sediROM v2
My idea for the upcoming version v2 is:
Keep as close as possible to Stock, fix known issues, remove bloatware and enhance it by features coming from apps - and not by re-compiling sensitive things like framework etc. The only reason for touching system components would be if that would fix something but not to add features into it. An example is the Quick settings bar which is not workin as expected in LiteROM. There are apps out there (e.g. a well configured Widgetsoid bar or one of the others) who can do the same but they do not touch system files. the sames goes to Bluetooth which seems to not working (as joedeng reported) like expected but it do work in Stock.
One another very important thing to mention:
I do not want to be a full-feature-blown-containing-everything-what-is-available-ROM!
upcoming v2 features/enhancements need to fulfill at least one of those:
Fixing a (real) bug or serious problem
Performance optimization
Battery optimization
System optimization or stability
So I hope you got the idea
So as I'm currently developing both directions it would be possible to hear your thoughts about that way.
This is your chance to be part of sediROM v2
So: If you have features you want to have or if know about issues within ICS STOCK Rom let me know!

Send me your link v2 in my box...Whay u don't post link down in top? I think your rom it good...

[FIX] FED-Patcher v7 (ForceEncrypt Disable Patcher)

Hello everybody,
I created a tool for the nexus 9 that gets rid of the ForceEncrypt flag in a generic way (meaning it should work no matter what rom you are on). It does that by patching the currently installed boot.img.
Background
The Android CDD (Compatibility Definition Document) suggests that all devices SHOULD enable full disk-encryption (FDE) by default. Even though I support every step towards more security I have to criticize this approach. FDE comes at a price. Encryption takes time because some component has to de- and encrypt the stuff on the disk at some point and in the case of the nexus 9 (aka flounder) it's the CPU's task. Even though the nexus 9's CPU has 2 pretty fast cores you can still easily feel the difference between FDE in the on- or off-state. The I/O is faster and boot-times take only half as long. (I did not do any measurements)
There is an ongoing discussion about this topic in cyanogenmod's gerrit. Although it's a fun read it is pretty clear that this exchange of views is not going anywhere near a useful outcome.
Because performance is important to me and my tablet does not need the extra security I created the FED-Patcher (ForceEncrypt Disable Patcher)
How does it work?
FED-Patcher is a simple flashable ZIP that is supposed to be run in a recovery that has busybox integrated (like TWRP or CWM). This is what it does:
Checks if your device is compatible
Dumps the currently installed boot.img.
Unpacks the dump of your currently installed boot.img. The unpacking process is done via a self-compiled, statically linked version of unmkbootimg.
It patches the filesystem tables which include the force-encrypt flags. This process will change "forceencrypt" to "encryptable".
Then it patches the filesystem tables to not use dm-verity. This is done by removing the "verify" mount-parameter.
Creates a new boot.img. The unpacking process is done via a self-compiled, statically linked version of mkbootimg.
Flashes the modified boot.img
Supported devices
HTC Nexus 9 WiFi (flounder)
HTC Nexus 9 LTE (flounder_lte)
Motorola Nexus 6 (shamu)
Version History
v1 - Initial version with HTC Nexus 9 WiFi (flounder) support
v2 - Added Motorola Nexus 6 (shamu) support
v3 - Added support for HTC Nexus 9 LTE (flounder_lte)
v4 - Added support for signed boot-images
v5 - Changed error handling to compensate for missing fstab files. Some roms seem not to ship with the complete set of boot-files from AOSP.
v6 - FED-Patcher will enforce the same structure for the patched boot.img that the original boot.img had. Additionally, the kernel commandline will also be taken over. This should fix pretty much every case where devices would not boot after patching.
v7 - FED-Patcher will now disable dm-verity in fstab to get rid of the red error sign on marshmallow roms.
What do I need to make this work?
A supported device (Your nexus 9)
An unlocked bootloader
An already installed ROM with forceencrypt flag. (like cyanogenmod CM12.1)
A recovery that includes busybox (TWRP, CWM)
How do I use it?
Make a thorough, conservative backup of your data if there is any on your device
Go into your recovery (TWRP, CWM)
Flash fed_patcher-signed.zip
If your device is already encrypted (You booted your ROM at least once) you need to do a full wipe to get rid of the encryption. This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before. If you don't do a backup and want to restore your data... well... Call obama.
How do I know if it worked?
Go into your "Settings"-App. In "Security", if it offers you to encrypt your device it is unencrypted. If it says something like "Device is encrypted" it indeed is encrypted.
IMPORTANT: If you update your ROM you have to run FED-Patcher again because ROM-updates also update the boot-partition which effectively removes my patch. So, if you are on CM12.1 for example and you used my patch and do an update to a newer nightly you have to run FED-Patcher again. If you don't do so Android will encrypt your device at the first boot.
Is it dangerous?
Well, I implemented tons of checks that prevent pretty much anything bad from happening. But, of course, we're dealing with the boot-partition here. Even though I tested FED-Patcher quite a lot there is still room for crap hitting the fan.
Screenshot
Scroll down to the attached thumbnails.
Credits
* pbatard for making (un)mkbootimg (dunno if he is on xda)
* @rovo89 for his xposed framework - I used some of his ideas by reading the source of his xposed installer flashable ZIP for FED-Patcher.

Thanks for creating this! In theory, would this work for the Nexus 6 as well? It would seem like it's a similar process.

itlnstln said:
Thanks for creating this! In theory, would this work for the Nexus 6 as well? It would seem like it's a similar process.
Click to expand...
Click to collapse
Hey there,
yes, it would probably work because the process itself is pretty generic. The only real difference between devices is the device-path for the boot-partition as well as the path(s) for the fstab-file(s) inside the boot.img. Nothing that cannot be done - but I don't have a device for testing. If you feel adventurous I can do a nexus6 (shamu) version for you for testing. I will double check so it should not eff up your device .
EDIT: Not to forget, the nexus 9 is a 64bit device. mkbootimg as well as unmkbootimg are compiled for 64bit. I have to rebuild those two programs for 32bit to make them work for 32bit devices.

If you have time for a N6 build, that would be great. If not, it's not a big deal since there seems to be more support for that device.

itlnstln said:
If you have time for a N6 build, that would be great. If not, it's not a big deal since there seems to be more support for that device.
Click to expand...
Click to collapse
Well, it's pretty much done. Do you want to test a version that does not actually flash anything but do everything else - just to see if it works correctly?

Absolutely!

itlnstln said:
Absolutely!
Click to expand...
Click to collapse
Alright, here you go!
If no error occurs there will be the already modified boot.img file in your temp-directory of your nexus 6. You can send me this file to be completely sure that everything went according to plan. Here is the adb-command:
Code:
adb pull /tmp/fed_patcher/boot-new.img
If all goes well I will upload the new version with nexus 6 (shamu) support tomorrow.
Good night!

gladiac said:
Alright, here you go!
If no error occurs there will be the already modified boot.img file in your temp-directory of your nexus 6. You can send me this file to be completely sure that everything went according to plan. Here is the adb-command:
Code:
adb pull /tmp/fed_patcher/boot-new.img
If all goes well I will upload the new version with nexus 6 (shamu) support tomorrow.
Good night!
Click to expand...
Click to collapse
Thanks! It seemed to work OK. Here's the boot image.

itlnstln said:
Thanks! It seemed to work OK. Here's the boot image.
Click to expand...
Click to collapse
Thanks for your help! I just updated the flashable ZIP in the first post. Enjoy

gladiac said:
Thanks for your help! I just updated the flashable ZIP in the first post. Enjoy
Click to expand...
Click to collapse
You're the best! Thanks!

I noticed in op it says "4 pretty fast cores". This puppy only has 2 cores. Just throwing it out there for readers that don't know. I'm sure it was just a minor oversight.
Sent from my Nexus 9

madbat99 said:
I noticed in op it says "4 pretty fast cores". This puppy only has 2 cores. Just throwing it out there for readers that don't know. I'm sure it was just a minor oversight.
Sent from my Nexus 9
Click to expand...
Click to collapse
Hi,
you are right, thanks. I just fixed the text in the op.

Hey everybody,
I will enable support for the Nexus 9 LTE (flounder_lte) this afternoon in FED-Pather v3. If you want other devices to be supported please tell me. Is there a list of android devices that have forced encryption?

So this works great, leaving device unencrypted. But anyone having issues with apps crashing? Most especially Google Play Services?

femmyade2001 said:
So this works great, leaving device unencrypted. But anyone having issues with apps crashing? Most especially Google Play Services?
Click to expand...
Click to collapse
This problem is new to me. My patch only modifies the boot-image so that it does not enforce encryption. It is merely a flag in fstab that gets changed and should not have anything to do with crashing apps. Anyway, do you have a logcat?

Hey everybody,
v3 is here with HTC Nexus 9 LTE (flounder_lte) support!
Enjoy

I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.

itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Hi, sorry to hear that. I will have a look into the boot.img that gets shipped with LMY48M. Not sure what is going on here.

itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Alright - unmkbootimg fails because the boot.img that google ships has 256 Bytes of extra data (it is probably signed or something) at the beginning. If you strip that off it works correctly:
Code:
dd if=boot.img of=boot-stripped.img bs=256 skip=1
Well, this was unexpected. But nothing that cannot be dealt with. I will make my flashable ZIP search for the offset of the boot.img-signature inside the dumped boot.img and strip of the preceding data. The rest of the process should work as usual.

itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Hi @itlnstln,
I just made a new version which should do the trick. I tested the new functionality to the best of my knowledge. If the script fails for some reason it wont flash anything - so the probability for actual damage is very low. Do you feel adventurous xD?
Please tell me if it worked for you or not.

Android 7.0 & /etc/hosts

/etc/hosts blacklist entries seem to be ignored with Android 7.0 (e.g. adding 127.0.0.1 amazon.com still allows me to reach amazon.com). Is anyone else experiencing something similar or familiar with any gotchas around Android 7.0 and modifying /system/etc/hosts?
I'm running official Nexus 5X Android 7.0 build number NRD90R. I have an engineering build of android that I boot from as follows to modify my /system/etc/hosts file:
adb reboot-bootloader
fastboot boot my-recovery.img
<mount from phone menu>
adb remount
adb push my-hosts system/etc/hosts
adb shell
chmod 644 system/etc/hosts
exit
<reboot from phone menu>
I've been using this process after every OTA update since Android 6.0, and it's been working. I also noticed that I'm not getting the red warning on boot any more (the one you get after you modify anything on the system partition), just the yellow warning (the one you get from having phone unlocked). Maybe I did something wrong ¯\_(ツ)_/¯ but I could sure use a sanity check.

Could be related to java cache, after a modification to hosts file you should reboot to let the cache reload. Try it.

The OS is not booted when editing hosts since it's being edited from a recovery image with the system mounted into it. The last step is to reboot. I did reboot the phone again for good measure and it's still not working. If it is a cache related thing, it lives through reboot. I suspect it's not though as I was seeing ads in news websites that I do not frequent.
Any other thoughts?

Are you using chrome? Did you disable data saver option in chrome?
Sent from my SHIELD Tablet K1 using Tapatalk

Seems to be related to: http://forum.xda-developers.com/nex...oid-nougat-t3445647/post68737720#post68737720 . Basically the files that one would modify by mounting /system are no longer used, afaict.
When I boot a live image, mount the system partition, and make a modification (i.e. /system/etc/hosts), that change is persisted through a reboot back to the live image and remount. However, it's not loaded by the OS when it boots. Instead both /etc/hosts and /system/etc/hosts are unmodified. Odd, and why is there even anything mounted at /system? I'm not sure if there are multiple system partitions or what's going on. I would love to find some information about Android 7.0 that explains.

crashenx said:
Seems to be related to: http://forum.xda-developers.com/nex...oid-nougat-t3445647/post68737720#post68737720 . Basically the files that one would modify by mounting /system are no longer used, afaict.
When I boot a live image, mount the system partition, and make a modification (i.e. /system/etc/hosts), that change is persisted through a reboot back to the live image and remount. However, it's not loaded by the OS when it boots. Instead both /etc/hosts and /system/etc/hosts are unmodified. Odd, and why is there even anything mounted at /system? I'm not sure if there are multiple system partitions or what's going on. I would love to find some information about Android 7.0 that explains.
Click to expand...
Click to collapse
I responded to your post in the other thread. This is repost.
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.

sfhub said:
I responded to your post in the other thread. This is repost.
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.
Click to expand...
Click to collapse
That's good info and makes total sense. Thanks! Pretty neat actually, just a bummer for me.
Yeah so SuperSU path is not really one I want to pursue. I could learn how to update the dm-verity shas used for verification. That'd probably be the most secure, but it's gonna be a PITA I bet. I imagine I'd need to compile my own image similar to how I made my live image and update a few things. Might have to deal with encryption which is probably an even bigger headache. Also, I bet it would break OTA and have to reflash to update, though that's true now.
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
I really appreciate you pointing us in the right direction.

crashenx said:
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
Click to expand...
Click to collapse
I don't use adaway but I believe there are 2 ways to install it with Android N. First is to install SuperSU (or otherwise disable dm-verity) and have it update as it always has. 2nd way is systemless where it piggybacks on some init scripts SuperSU has created to mount "over" the existing hosts file. Basically like symlinking but using a mount point on top of the existing file.

sfhub said:
I don't use adaway but I believe there are 2 ways to install it with Android N. First is to install SuperSU (or otherwise disable dm-verity) and have it update as it always has. 2nd way is systemless where it piggybacks on some init scripts SuperSU has created to mount "over" the existing hosts file. Basically like symlinking but using a mount point on top of the existing file.
Click to expand...
Click to collapse
I'll probably try to go the route of updating init scripts to mount over the existing host file but without using SuperSU or AdAway.

[RECOVERY][Android 10/11][Stock/SODP][XZ2/C/P/3] TWRP 3.4.0-0 [UNofficial]

The Sony Open Devices Project is always happy about volunteers (coding, testing, etc)
Also mainlining your favorite snapdragon powered xperia device into the mainline kernel is possible and we will be glad to help you!
Official site
Unofficial site
Code:
#include <std_disclaimer.h>
/*
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*
*/
Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
FAQ:
Just wiping your phone in TWRP lead into an encrypted & not readable userdata in the stock system.
You need to open advanced wiping and check the entries data and internal storage.
Of course clear the dalvik, too.
If you backed up system and/or vendor partitions and you want to restore them, make sure that TWRP setting "Use rm -rf instead of formatting" is set!.
If after the usage of NewFlasher or the OTA Updater or something else, which installs stock firmware parts you get stuck into the TWRP or SONY Logo, you need again to disable the verification with the vbmeta.img file and its parameters in fastboot.
fastboot & adb
https://developer.sony.com/develop/open-devices/get-started/flash-tool/useful-key-combinations/
https://wiki.lineageos.org/adb_fastboot_guide.html
https://developer.android.com/studio/releases/platform-tools
Weird problems not easily to reproduce by other users require that you make sure, that you
Use the newest platform tools (adb & fastboot)
Downloaded the newest firmware via Xperifirm from XDA and installed the newest firmware via Newflasher from XDA
Newflasher from XDA
Xperifirm from XDA
Removing the stock bloat apps via titanium backup may result in a boot loop. Use a file explorer to remove them, disable them or try to use my unfinished bloat removal script at github.
Your phone reboots into recovery, instead of system? Maybe it crashed too often due to a wrong installation or whatever?
In TWRP:
Code:
cat /dev/block/bootdevice/by-name/misc
shows you the reason.
TWRP -> [WIPE] -> [Advanced Wipe] -> Tick only the misc -> [Swipe to Wipe]
Known Bugs:
The "fastboot boot twrp.img" doesn't work, if you use the hardware buttons to open the blue fastboot bootloader mode. Only use adb, twrp or the android system to reboot into blue fastboot bootloader mode or flash the twrp.img, boot the device, reboot into bootloader and flash the original boot.img back, before booting into twrp.
You can also "fastboot reboot bootloader" in the blue fastboot mode.
This is a bootloader bug, maybe it gets fixed with the stock Q bootloader.
If "fastboot boot twrp.img" results into a blackscreen and reboot of the phone, take a look if you modified the DTBO partition.
It requires a special TWRP for every modified kernel/dtbo until I find some way to unify the twrp kernel with the DTBO (if the bootloader supports it).
Bugtracker:
TWRP Bugtracker -> If you think the problem is in TWRP
My Bugtracker -> If you think the problem is in my implementation
Bugreport:
A bugreport needs your device name, dmesg, the /tmp/recovery.log and a way to reproduce the issue.
If possible use
Code:
logcat -b all
instead of just a dmesg.
If ADB is not working to provide logs
VOLUP+POWER for 1 Seconds -> Forced crash to create a pstore
Boot the normal system.
Give me the files in
Code:
/sys/fs/pstore/
If the TWRP is stuck at the TWRP logo, the chances are high, that the decryption didn't succeed.
To rescue a not responding phone:
VOLUP+POWER for 3 Seconds -> RESTART with one Vibration.
VOLUP+POWER for 20 Seconds -> SHUTDOWN with 3 Vibrations.
VOLUP+POWER+CAMERA for 30 Seconds -> HARDWARE SHUTDOWN by discharging a capacitor.
Thank you very much for your help, code contribution & testing! (Random order):
@dees_troy and his team of volunteers for the TWRP code
@dhacke thank your for providing a download server
Shame on me if I forgot someone after searching through the thread and my PM's!
And many thanks to the few donators!
A telegram group for technical SODP stuff:
https://t.me/xda_tv
XDA:DevDB Information
TWRP, ROM for the Xperia XZ2
Contributors
MartinX3, Sony
Source Code: https://github.com/MartinX3-AndroidDevelopment
ROM OS Version: Android 10
ROM Kernel: Linux 4.x
ROM Firmware Required: Newest recommended
Based On: AOSP
Version Information
Status: Stable
Current Stable Version: 3.4.0-0
Stable Release Date: 2020-06-13
Created 2020-03-29
Last Updated 2020-06-20

Download & Installation
Download:
https://androidfilehost.com/?w=devices&uid=11410963190603893035
https://www.dhsfileserver.de/ftp/martinx3/ Thank you @dhacke for the second download server
Installation:
Update to newest stock firmware before unlocking!!!
Unzip the *.gz files with https://7-zip.org/ or Linux.
Enter fastboot via software, not hardware buttons. See "Known Bugs".
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
fastboot boot twrp.img
Advanced menu -> "Install recovery ramdisk" -> Choose twrp.img
Reboot into installed TWRP
Want Root? -> Magisk
(Only if your phone doesn't boot to system anymore) Advanced menu -> "Fix recovery bootloop"
(Optional; Security degradation; Only if you know what you're doing) Switch SELinux to permissive (with my permissive.zip)

News
02.03.2021
Reuploaded the SODP TWRP with a workaround for Android 11 compatibility.
Click to expand...
Click to collapse
15.06.2020
reuploaded the stock twrp for the xz2 premium with a completely fixed touch.
Click to expand...
Click to collapse
14.06.2020
reuploaded the stock twrp with a later touch kernel modules initialization.
Hopefully fixing the randomly happening not working touch.
Click to expand...
Click to collapse
13.06.2020
thanks to the fixes in 3.4.0 we got now a twrp with the following enhancements for stock and sodp:
- this twrp will work with future 10.0 roms, you don't need a new build matching the security patch level of your rom.
- you can install this twrp again with the buildin ramdisk patcher. Please follow the installation instructions.
Click to expand...
Click to collapse
11.06.2020
switch to twrp 3.4.0
sodp twrp 2020-06 security patch level
stock twrp 2020-05 security patch level for firmware 52.1.a.2.1
now both twrp should work without a rom being installed (empty system/vendor/oem partitions) and still be able to decrypt your userdata.
Also the stock twrp touch should now always work instead of playing russian roulette.
Click to expand...
Click to collapse
11.05.2020
reuploaded sodp twrp for 2020-05 security patch level.
It didn't boot with the newest aosp.
Click to expand...
Click to collapse
07.05.2020
sodp twrp for 2020-05 security patch level.
Click to expand...
Click to collapse
14.04.2020
removed stock twrp for firmware 52.1.a.0.672 until sony releases the kernel sources of the new security patch level.
Otherwise the keymaster won't decrypt the userdata for twrp and twrp gets stuck on the twrp logo.
Click to expand...
Click to collapse
13.04.2020
stock twrp for firmware 52.1.a.0.672
sodp twrp for 2020-04 security patch level
hopefully fixed the touch problems of the stock twrp
fixed the forced read only partition mountings of system, vendor, odm
Click to expand...
Click to collapse
31.03.2020
stock twrp for firmware 52.1.a.0.618
Click to expand...
Click to collapse
30.03.2020
sodp twrp for 2020-03 security patch level
installing in ramdisk (to make it persistent) is impossible at the moment, because it is a 9.0 twrp which makes its ramdisk incompatible to the rom.
Of course monthly twrp releases in sync with the current patch level need to be released or i would need to remove the userdata decryption completely.
The stock twrp will follow, after it became ready.
Click to expand...
Click to collapse

30.03.2020
SODP TWRP for 2020-03 security patch level
Installing in Ramdisk (to make it persistent) is impossible at the moment, because it is a 9.0 TWRP which makes its ramdisk incompatible to the ROM.
Of course monthly TWRP releases in sync with the current patch level need to be released or I would need to remove the userdata decryption completely.
The Stock TWRP will follow, after it became ready.
Click to expand...
Click to collapse
PS: AndroidFileHost blocked me for doing too many actions at the same time.
Maybe I can upload it there tomorrow.
Done

can't wait for possibility to install in ramdisk
but now there is a working recovery :highfive:

31.03.2020
Stock TWRP for firmware 52.1.A.0.618
Click to expand...
Click to collapse

xz3 twrp
MartinX3 said:
31.03.2020
Click to expand...
Click to collapse
xz3 twrp won't boot, sodp version is good but there's no install on ramdisk?

hafiidh said:
xz3 twrp won't boot, sodp version is good but there's no install on ramdisk?
Click to expand...
Click to collapse
You mean SODP TWRP works, but not the stock TWRP on your XZ3?
You are stuck on sony logo?
Or on TWRP logo?
I need a bugreport with "logcat -b all" via adb.
Install ramdisk doesn't work at the moment, because it is a TWRP 9.0 hack, since TWRP 10.0 is ready.
But I wrote it in the news
Edit:
Reworked the thread a bit for more clarification

First! Wonderful job!
---EDIT------
Everything works fine! So nice!

@MartinX3 Great job as always bro! :good:
I ran it on my XZ2 (stock 52.1.A.0.618).
Phone has booted to the twrp screen (till the unlock pattern), but the touch is not working (log).
I didn't start from scratch (fresh install), for the record.
Tia!

serajr said:
@MartinX3 Great job as always bro! :good:
I ran it on my XZ2 (stock 52.1.A.0.618).
Phone has booted to the twrp screen (till the unlock pattern), but the touch is not working (log).
I didn't start from scratch (fresh install), for the record.
Tia!
Click to expand...
Click to collapse
Thank you
Are you sure the touch doesn't work?
I tested this release on the same firmware on my XZ2 in stock.
This confuses me now.
You booted stock .618 before and you tried to deactivate & activate the display?
Here it worked right out of the box.
And if it happens again, could you execute "start preptouch"
And if that not works, could you execute "/sbin/preptouch.sh"?

Sjll said:
First! Wonderful job!
---EDIT------
Everything works fine! So nice!
Click to expand...
Click to collapse
Thank you

MartinX3 said:
[...] Are you sure the touch doesn't work?
And if it happens again, could you execute "start preptouch"
And if that not works, could you execute "/sbin/preptouch.sh"?
Click to expand...
Click to collapse
I am. I have tried at least three times so far. Tried turning off and on the screen, but the slide to unlock didn't work, too.
"start preptouch", no response, no working touch
"/sbin/preptouch.sh"...
Code:
insmod: failed to load /sbin/clearpad_rmi_dev.ko: File exists
insmod: failed to load /sbin/clearpad_core.ko: File exists
insmod: failed to load /sbin/clearpad_i2c.ko: File exists
akari:/sbin # ls -l
Tia again

serajr said:
I am. I have tried at least three times so far. Tried turning off and on the screen, but the slide to unlock didn't work, too.
"start preptouch", no response, no working touch
"/sbin/preptouch.sh"...
Code:
insmod: failed to load /sbin/clearpad_rmi_dev.ko: File exists
insmod: failed to load /sbin/clearpad_core.ko: File exists
insmod: failed to load /sbin/clearpad_i2c.ko: File exists
akari:/sbin # ls -l
Tia again
Click to expand...
Click to collapse
And the service menu of android should also say that you use the clearpad driver.
And I assume the 9.0 stock twrp did always touch fine?
The script say that the kernel modules for the touch driver got loaded and I assume the sys path in the script file got executed too, after loading the .ko files.
And you have a normal European firmware?
That's now a mystery for me why it works for me and others, but not in your phone
Especially if you have the clearpad touch hardware

MartinX3 said:
And the service menu of android should also say that you use the clearpad driver.
And I assume the 9.0 stock twrp did always touch fine?
The script say that the kernel modules for the touch driver got loaded and I assume the sys path in the script file got executed too, after loading the .ko files.
And you have a normal European firmware?
That's now a mystery for me why it works for me and others, but not in your phone
Especially if you have the clearpad touch hardware
Click to expand...
Click to collapse
I got the touch working after copying the three .ko libs to the ramdisk /sbin folder, and a small editing (below) in the permissive.sh (also removed "$touch_id" == "3" from preptouch.sh).
Code:
setenforce 0
insmod /sbin/clearpad_rmi_dev.ko
insmod /sbin/clearpad_core.ko
insmod /sbin/clearpad_i2c.ko
echo 1 > /sys/devices/virtual/input/clearpad/post_probe_start
I know this is an awful workaround, but maybe this give you some hint (or sets you more confusing yet )
I'm with the sony stock customized_br fw, as always!

serajr said:
I got the touch working after copying the three .ko libs to the ramdisk /sbin folder, and a small editing (below) in the permissive.sh (also removed "$touch_id" == "3" from preptouch.sh).
Code:
setenforce 0
insmod /sbin/clearpad_rmi_dev.ko
insmod /sbin/clearpad_core.ko
insmod /sbin/clearpad_i2c.ko
echo 1 > /sys/devices/virtual/input/clearpad/post_probe_start
I know this is an awful workaround, but maybe this give you some hint (or sets you more confusing yet )
I'm with the sony stock customized_br fw, as always!
Click to expand...
Click to collapse
Ah you have a XZ2C, not a XZ2?
Because the removed ID 3 is for the XZ2 with clearpad touch.
But the script did already copy the .ko files into your /sbin before and executed the same code, you did now manually.
And according to your logs the setenforce 0 was already executed earlier.
So you just did the same the script did.
Well, yes you confuse me more
Could you try to just execute "echo 1 > /sys/devices/virtual/input/clearpad/post_probe_start" if the touch doesn't work again?
I wonder if the initialization is too early on your device.
Then I could try to delay the preptouch service to a later stage of the device boot.

MartinX3 said:
Ah you have a XZ2C, not a XZ2?
Because the removed ID 3 is for the XZ2 with clearpad touch.
But the script did already copy the .ko files into your /sbin before and executed the same code, you did now manually.
And according to your logs the setenforce 0 was already executed earlier.
So you just did the same the script did.
Well, yes you confuse me more
Could you try to just execute "echo 1 > /sys/devices/virtual/input/clearpad/post_probe_start" if the touch doesn't work again?
I wonder if the initialization is too early on your device.
Then I could try to delay the preptouch service to a later stage of the device boot.
Click to expand...
Click to collapse
I have a regular XZ2 (H8216), and its touch_id is 3 (customized_br fw), so I removed the Id 3.
"Could you try to just execute..." I've already tried that, with no success.
"Then I could try to delay the preptouch..." Cool... As you could notice, it worked here with that awful way I did it, so why not?
:good:

serajr said:
I have a regular XZ2 (H8216), and its touch_id is 3 (customized_br fw), so I removed the Id 3.
"Could you try to just execute..." I've already tried that, with no success.
"Then I could try to delay the preptouch..." Cool... As you could notice, it worked here with that awful way I did it, so why not?
:good:
Click to expand...
Click to collapse
But you tried it also yourself later.
You executed the script again without success at a later stage.
And adding it to the permissive.sh is like executing the script, just earlier.
I assume `cat /sys/devices/dsi_panel_driver/panel_id` gives you the "3" as result?

MartinX3 said:
But you tried it also yourself later.
You executed the script again without success at a later stage.
And adding it to the permissive.sh is like executing the script, just earlier.
I assume `cat /sys/devices/dsi_panel_driver/panel_id` gives you the "3" as result?
Click to expand...
Click to collapse
I ran the scripts/codes manually in the trwp root shell (with the no working touch screen).
Yep, running the script earlier (permissive.sh) did the trick (*.ko files in the ramdisk).
And 3 is the output of the panel_id (that's why I removed the 3 from the preptouch.sh).
Edit: I've noticed this...
The permissions of the libs copied from vendor to sbin (preptouch), as you could see here
Code:
-rw------- 1 root root 1070630 1972-01-22 17:46 clearpad_core.ko
-rw------- 1 root root 251702 1972-01-22 17:46 clearpad_i2c.ko
-rw------- 1 root root 296934 1972-01-22 17:46 clearpad_rmi_dev.ko
Patched twrp
Code:
-rwxrwxrwx 1 root root 1070902 2020-04-02 21:48 clearpad_core.ko
-rwxrwxrwx 1 root root 251830 2020-04-02 21:48 clearpad_i2c.ko
-rwxrwxrwx 1 root root 297054 2020-04-02 21:48 clearpad_rmi_dev.ko
Edit 2: chmod on copied files did the trick (preptouch.sh) - but sometimes still not working (need to boot twice, three times...):
Code:
#XZ2 "3" XZ2C "4" Clearpad
if [[ "$touch_id" == "3" ]] || [[ "$touch_id" == "4" ]]; then
cp /v/lib/modules/clearpad_rmi_dev.ko /sbin/
cp /v/lib/modules/clearpad_core.ko /sbin/
cp /v/lib/modules/clearpad_i2c.ko /sbin/
[B]chmod 777 /sbin/clearpad_rmi_dev.ko
chmod 777 /sbin/clearpad_core.ko
chmod 777 /sbin/clearpad_i2c.ko[/B]
insmod /sbin/clearpad_rmi_dev.ko
insmod /sbin/clearpad_core.ko
insmod /sbin/clearpad_i2c.ko
echo 1 > /sys/devices/virtual/input/clearpad/post_probe_start
fi
Maybe you find out a more elegant way to handle with that!
Edit 3:
I also got it permanently installed on kernel (combo keys does work, too), it's a bit tricky I gotta say, but it works.
You know, twrp's ramdisk.cpio kernel hack (old install procedure).

Hi Martin,
just wanted to let you know that your latest version for Sony stock (0.618 fw) does also not work for me (touch does not respond). Even 'fastboot reboot bootloader' before 'fastboot boot twrp-xz2.img' doesn't change anything.
Device:
Xperia XZ2 (H8216) running Android 10 stock (52.1.A.0.618)
Customized CH
Clearpad Touch version: 3