Database Develop

[Kernel]Vivid ICS(v007)OC~1.73GHz/UV/ZRAM/Intellidemand/DualCore/PowerSaving[Jun-07]

NOTICE: This is COMPATIBLE with ALL Vivid Rooted Stock and Custom ROMs
For frequency control use fauxclock from Google Play
Just a statement regarding kernel source: The Kernel Source is of course covered under GPL version 2. Free software does NOT mean no work or time was spent working on it. I have donated a large sum of my free time to hack this kernel. If you use my modified kernel source in parts or in its entirety, I kindly ask you mention its origins and to send me a github pull request or PM whenever you find bugs or think you can help improve my kernel hack further. This way the entire community will truly benefit from the spirit of open source. Thank you
​
Hi XDA members and fellow Vivid users:
This is my tenth kernel hack. I want to thank Erasmux, and several others I cannot recall for inspiring me to venture into this unfamiliar territory for me.
What is a Kernel? The Kernel is the Foundation in which everything else builds upon in any software system.
[Car Analogy]: Kernel is like the Engine, Electrical system and the Transmission to a car. The Library, Framework and the Apps [AKA ROM] are the body frame and the rest of the Car.
​
THIS KERNEL is BASED ON HTC Source Code. So it is COMPATIBLE ONLY WITH HTC ICS Vivid Builds.
Please DO NOT use any task killers, they DO NOT improve performance nor battery life. They INTERFERE with your phone's stability (more crashes) and App compatibilities (Forced Close).
CleanCache (via ZCache backend)
ZCACHE is a new technology I introduced to HTC Kernel. ZCACHE is a compressed cache similar to ZRAM but the similarity ends there. ZCache is meant to provide as many "cleancache" pages (non-dirty or untouched "virgin" memory) to apps that request for new memory. CleanCache is very easy to allocate and no additional penalty are required to hand them out, so having more CleanCache pages will improve performance. Under heavy memory pressure, often times the kernel will NOT have enough CleanCache pages, so the kernel has to do EXTRA work to reclaim dirty cache pages and clean them for the new apps that's requesting for them. The described process creates a performance hit for the kernel and the app, so the idea is to use compression to create more CleanCache pages available for use. Of course there's a penalty to pay for using compression, but the trade-off between compression penalty and the penalty for reclaiming dirty cache pages and allocating them after cleaning is smaller for compression, so in the end, CleanCache should add more performance.
ZRAM (aka CompCache aka RAMZSwap)
ZRAM is an updated version formally known as CompCache and RAMZSwap. It was originally designed for 2.6.38.xx kernels, I have backported to our 2.6.35.xx kernel. ZRAM allows real-time compression of memory objects in RAM thus reducing memory pressure for the Linux kernel and can keep more apps in memory longer (more apps in RAM == better performance, less fetching from slower MMC or SDCard). Compression, however, is not Free. Some CPU cycles are required to do the compress/decompression, so there's a slight penalty for it. The original CompCache / RAMZSwap required a user space binary to control its behavior which adds additional penalty to performance, but the new version ZRAM eliminated the need for a separate dedicated daemon, thus reducing the overhead and increased performance from the old CompCache by 20%. Therefore, with the newer implementation of ZRAM interface, the performance penalty is almost negligible.
Joe's RCU (Optimized for Small SMP systems)
Joe Korty has created an RCU for small SMP systems (> 32 cores). His approach is to isolate all the Garbage Collection (GC, a slow time consuming but necessary processing) to a single core, thus allowing other cores to ONLY work on real required processing. This will allow the additional cores to complete their assigned tasks as fast as possible (not bogged down by GC) then immediately go back to a suspended state (saving battery).
Fast No Hz RCU (Optimized for SMP operations)
Fast NoHz is an optimized version of the traditional Tree RCU. Many new kernels are using the Tickless NoHz design. This RCU is tailored and designed to work with the new NoHz kernel system.
SmartAssV2 Governor (Balanced)
This governor has a built-in "profile" similar to SetCPU, so screen off will use lower clock rate thus conserve more battery, but it also has a fast wake up feature so that user interaction will not see the lag when switching from Sleep to Wake state.... (So SetCPU Profiles are sorta redundant when using this governor, you can still use SetCPU to OC to higher than default Clock frequency).
Interactive Governor (Performance)
This governor is designed to put more priority to User Interface (UI aka Apps) tasks, therefore appears more responsive then the traditional OnDemand governor. So if you want the smoothest UI interaction, this governor is for you...
Brain F*ck Scheduler - (BFS)
This scheduler is designed to be simple and speedy tailor specifically for user interface type systems such as desktop/smart phone devices where user interaction is MORE important than serving 1 million web requests (CFS, the default scheduler) at the same time (think of nimble desktop workstations vs large corporate servers).
SLQB - (SLAB allocator with Queue)
This memory allocator is designed for small number of CPUs system (such as desktop or smart phone devices). This allocator is design to be simple and it is optimized for using order-0 pages as much as possible (order-0 pages are the simplest therefore quickest type of memory in a Linux system to allocate). Not all kernels are using SLQB including CM7 main line...
Fair Budget Queue (BFQ I/O scheduler)
This I/O scheduler is an improvement on top of Completely Fair Queue (CFQ). CFQ is fair in terms of time but not in terms of throughput / bandwidth, so BFQ make sure that both time and throughput / bandwidth are balanced across all requests.
Kernel Files:
******* Ice Cream Sandwich (Android 4.0.x) ******* (Linux 3.0.33)
[ CFS ] (Ultimate Edition) *** S-ON ***
The File ==> Vivid Kernel 007 (1.73 GHz, GPU @ 320MHz, ZRAM) <==
[ CFS ] (Ultimate Edition) *** S-OFF ***
The File ==> Vivid Kernel 007 (1.73 GHz, GPU @ 320MHz, ZRAM) <==
[ Optional: ]
Files to DISABLE Sweep2Wake:
http://forum.xda-developers.com/showpost.php?p=25538084&postcount=6616
[ For Kernel Devlopers ONLY: ]
The File ==> My Global VDD_TABLE for under volt patch <==
The File ==> KGSL Ring Buffer Power Management Patch for Cordy and Ninja Jump <==
Optional Under voltage: Version 0.1.4+ ONLY
Code:
[ to over volt ALL frequencies by 25000 uv (microvolts) ]
echo "+25000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
[ to under volt ALL frequencies by 25000 uv (microvolts) ]
echo "-25000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
[ to set a specific frequency (ie 1.18 GHz)
with a specific voltage (ie 1.0875 volts) ]
echo "1188000 1087500" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
CPU Frequency Voltage Table Example
Code:
192000: 812500
310500: 812500
384000: 812500
432000: 812500
486000: 837500
540000: 850000
594000: 862500
648000: 875000
702000: 900000
756000: 925000
810000: 937500
864000: 962500
918000: 962500
972000: 962500
1026000: 975000
1080000: 987500
1134000: 1000000
1188000: 1012500
1242000: 1025000
1296000: 1050000
1350000: 1075000
1404000: 1100000
1458000: 1112500
1512000: 1125000
1566000: 1150000
Optional: Stock Clock Frequencies for Dual CPUs
Code:
su
echo 192000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1188000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 1 > /sys/devices/system/cpu/cpu1/cpufreq/online
echo 192000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
echo 1188000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
Optional: ZRAM (Compressed RAM swap space )
Code:
su
mkswap /dev/block/zram0
swapon /dev/block/zram0
Low Voltage - Under Volt the processor, therefore uses Less Battery, but NOT ALL CHIPS can handle Under Volt.. If you experience instability, try the Stock Voltage Version.
Stock Voltage - Uses the voltage values from ORIGINAL HTC Kernel Source.
There are NO PERFORMANCE DIFFERENCE between the Under Volted and Stock Voltage versions!
Installation Instructions:
Here's a step by step instruction to install this kernel:
1. download the above file (via phone directly or to a PC)
2. copy the downloaded zip file to /sdcard/download/
3. Open ROM Manager and select "Reboot into Recovery" and select "OK"
4. Once in recovery, select "wipe cache partition", select "Yes", then select "advanced", then select "Wipe Dalvik Cache", then select "Yes" again. Once finished, click the back button to go back to the main recovery menu. On that menu, select "Install Zip From SDCad", then select "Choose zip from SDCard", then go to /sdcard/download and select the downloaded zip file and let it run its script.
5. Once the script is done, select "reboot system now"
Note: After FLASHING, the first reboot may take longer than usual, please be patient... After the first reboot, it may lag during initial load (let everything finish loading). Once everything is loaded and phone is ready for use, reboot the phone a 2nd time and the lag will be gone and everything should be silky smooth...
NEWS BULLETIN:
Ice Cream Sandwich Version 007 is out. More intelligent intellidemand! Completely free yourselves from mpdecision, thermald and now with intellidemand, complete CPU/Thermal Management by the kernel.
Please don't hesitate to talk among yourselves and help each other out... The XDA community is what inspired me to hack kernels for everyone since everyone here is nice and helpful to each other... Keep helping each other.... Famous proverb: It's better to give than to receive...
BUGS:
Not All CHIPS ARE CREATED EQUAL
TO DO:
version 1.x.x -- Haven't thought about it yet...
History:
[ Change Log ]
Standard Disclaimer: Not responsible for bricking your phone, voiding your warranty, or any other pain or suffering you may feel as result of using this kernel!!!
My Github Complying with GPL and XDA rulez
Follow me on
:
If you find this Kernel useful, feel free to hit the [Thanks] button below

Awesome!! Can't wait to try it!
Sent from my HTC PH39100 using XDA

Thank you so much.. faux123~

Faux your a god.

Sweet....
Anyone install yet and have feedback to report?

Boot Loop
No go for me.
It gave me a reason to update to the new AT&T RUU.
May try again after clean install.

Going to flash stock rooted cwm then maybe this will report back.

ismoore said:
Anyone install yet and have feedback to report?
Click to expand...
Click to collapse
Well it's fast in quadrant scores. I got like a 3560 and in that test CPU scores are significantly higher. Antutu benchmark scores with no overclock are the same as stock. All else felt the same. I'm running this kernel with WC's 3.6 Vivid ROM. Still appreciate the contribution faux! I have run your kernels on other phones and they are always the best!

Now why would Window XP forget my android 1.0 drivers for hboot? can't flash anything in hboot now...

Great, thanks for the info. May try this tonight when I get home. Thanks for your efforts faux.
brwnohno said:
Well it's fast in quadrant scores. I got like a 3560 and in that test CPU scores are significantly higher. Antutu benchmark scores with no overclock are the same as stock. All else felt the same. I'm running this kernel with WC's 3.6 Vivid ROM. Still appreciate the contribution faux! I have run your kernels on other phones and they are always the best!
Click to expand...
Click to collapse

My wifi isn't working, it just says "turning on...". Other than that, it works great

**** mines bootlooping its get the att and loops what should i dooo? I got the latest cwm, and hboot, stock rooted rom. Is it because I let it try to boot right after I flashed the boot.img and didn't flash cwm strait after?

haloXgod117 said:
My wifi isn't working, it just says "turning on...". Other than that, it works great
Click to expand...
Click to collapse
Brand New said:
**** mines bootlooping its get the att and loops what should i dooo? I got the latest cwm, and hboot, stock rooted rom. Is it because I let it try to boot right after I flashed the boot.img and didn't flash cwm strait after?
Click to expand...
Click to collapse
You shouldn't be flashing via cwm. I've included a script for pc tethered flashing. Just run flash.bat on pc with USB cable connected to the phone. You may need to run it twice if it failed to load the modules.
Sent from my HTC Sensation 4G using Tapatalk

faux123 said:
You shouldn't be flashing via cwm. I've included a script for pc tethered flashing. Just run flash.bat on pc with USB cable connected to the phone. You may need to run it twice if it failed to load the modules.
Sent from my HTC Sensation 4G using Tapatalk
Click to expand...
Click to collapse
So I could of flashed this on stock ICS? I didn't think you could OC with a non-rooted phone And I was bootlooping on the stock rooted rom not because of the your kernal I believe
iff this will help
Code:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
D:\Documents and Settings\Noah>cd D:\Documents and Settings\Noah\Desktop\New Fol
der
D:\Documents and Settings\Noah\Desktop\New Folder>flash.bat
D:\Documents and Settings\Noah\Desktop\New Folder>adb kill-server
D:\Documents and Settings\Noah\Desktop\New Folder>adb remount
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
error: device not found
D:\Documents and Settings\Noah\Desktop\New Folder>adb push Modules/system /syste
m
error: device not found
D:\Documents and Settings\Noah\Desktop\New Folder>adb shell mv /system/bin/mpdec
ision /system/bin/mpdecision_dis
error: device not found
D:\Documents and Settings\Noah\Desktop\New Folder>adb shell mv /system/bin/therm
ald /system/bin/thermald_dis
error: device not found
D:\Documents and Settings\Noah\Desktop\New Folder>adb reboot bootloader
error: device not found
D:\Documents and Settings\Noah\Desktop\New Folder>fastboot flash boot Kernel-Her
e/boot.img
sending 'boot' (4348 KB)... OKAY [ 0.875s]
writing 'boot'... OKAY [ 4.984s]
finished. total time: 5.859s
D:\Documents and Settings\Noah\Desktop\New Folder>fastboot reboot
rebooting...
finished. total time: 0.188s
D:\Documents and Settings\Noah\Desktop\New Folder>pause
Press any key to continue . . .
D:\Documents and Settings\Noah\Desktop\New Folder>

can you make a aosp kernal

Nevermind Faux I figured it out! I just need to flash the boot.img that came with the stock rooted rom, then yours! I can't wait to test my battery now, games fly to!! Thanks for your support!!

SetCPU voltage tables are still nonfunctional, just like every other kernel I've tried.
come at me bro said:
can you make a aosp kernal
Click to expand...
Click to collapse
It would be easier to do so if we had a booting AOSP build right now, I think.

Having no issues here. Kernel is definitely smoother and faster than stock. Running fine on WC ROM. Hitting about 3350 on quadrant afer 5 consecutive runs. I haven't made and changes with setcpu, I'm assuming 1.5MHz from initial flash.
Sent from my HTC PH39100 using xda premium

Aus_Azn said:
SetCPU voltage tables are still nonfunctional, just like every other kernel I've tried.
It would be easier to do so if we had a booting AOSP build right now, I think.
Click to expand...
Click to collapse
thecubed's build boots but just barely and someone is working on a build right now I believe, so one day we might have working rom

Brand New said:
thecubed's build boots but just barely and someone is working on a build right now I believe, so one day we might have working rom
Click to expand...
Click to collapse
it boot loops with the proper builds , the one that boots is hacked up to hell

[MOD] SGS3 TweakAIO init script v1.0.1

Tweak All In One (AIO) init script for Samsung Galaxy S3
Hi guys!
Here is my all in one init script ported to SGS3, what can do every necessary system adjustment for better battery life/peformance.
This script is working with every ROM, ICS, JB, CM9-10!
This script will not made any changes in the system partition, dont delete any of your data, but of course its not fully noob protected.
Dont made any change in the init scipt in the /system/etc/init.d/S99TweakAIO file!
But you can edit the config file free: /data/tweakaio/tweakaio.conf
Installation:
- Just install the attached file from the CWM.
Explanation:
After the first reboot the init script will create a directory structure under the /data/tweakaio folder.
The tweakaio.conf located in this folder too. In the logs directory you will find the script output logs.
The tweakaio.conf explanation (default settings):
Reset Settings=off
If you set this to on, at the next reboot the script will reset the own config file
Script Enabled=on
Enable/Disable script. If this is set to 'off' the script will not run at the init process
Logger Enabled=on
Enable/Disable the system logger.
LMK Tweaks Enabled=on
Low Memory Killer Tweaks main toggle
LMK Mode=aggr
Lowmemory killer modes are: def, std, opt, str, aggr, extr, ult
The def is the most lighter the ultimate is the most harder. If you need a lot of free RAM and you dont want to use heavy multitask you can safely choose the 'extr' setting.
Network Tweaks Enabled=on
TCP/IP networking advanced tweaks. This will increase TCP throughput and save more battery life too.
Memory Management Tweaks Enabled=on
Advanced virtual memory management
KSM Enabled=on
Enable/Disable kernel samepage merging (if its supported)
Cache Drop Interval Time (in hour)=4
Periodically drop unused cache and collect the garbage from the mapped memory area (usually free RAM)
Mount Tweaks Enabled=on
Remount system/data/cache partition with (flash memory) optimized mount flags
SQLite3 Defrag Enabled=off
If its enabled every sqlite database will be defrag after every reboot
Dalvik Cache Cleaner Enabled=off
If its enabled collect unused/garbage dalvik-cache records and eliminate them after every reboot
Move Dalvik-Cache to Cache partition=off
If its enabled this will automatically move present dalvik-cache to the cache partition. This can free up space in the data partition.
Fully automatic, applyed after a full cache/dalvik wipe too. Just set and forget
Every option need to be 'on' or 'off' except the drop cache interval what is need to be a number (calculated in hour) and the LMK mode what is need to be a plain text described above
The config file is a simple text file, you can edit with your favourite file editor, but dont made any changes before the '='
You can follow what has been done in the /data/tweakaio/logs/tweakaio.log file
The dalvik cache mover has a separate log file called /data/tweakaio/logs/dalvik_mover.log
If you have any issue let me know, with the connected tweaklogs part!

Update 2012.09.06.:
- Optimized minfree values
- Added read ahead speed tweak
Update:
- Provided a config editor app, download from the first post attachment

Hy vadanko, thx for your work... I will try tomorrow
Best regards
Craxx
Gesendet von meinem GT-I9300 mit Tapatalk 2

Nice work mister.
After installation the files will added, and not replaced, in default unit.d folder, so we must delete any other unit.d inside as i understand.
Are there any build.prop tweaks (lines) thet we must delete after installation?
Is it compatible with stock kernel too?
Thanks.

eliashadow said:
Nice work mister.
After installation the files will added, and not replaced, in default unit.d folder, so we must delete any other unit.d inside as i understand.
Are there any build.prop tweaks (lines) thet we must delete after installation?
Is it compatible with stock kernel too?
Thanks.
Click to expand...
Click to collapse
If you have any other init script what is adjusting memory management or sysctl values, then you can delete this files, but not necessary.
About the build.prop this script doesn't affect the build.prop, so do not change anything.
If you using memory cleaner/optimizer app like autokiller memory optimizer, or any memory booster app you need to stop all of this app, this script will handle everything.

Very nice work.especially like sqlite and dalvik cleaner/mover option.
Thanx m8

Well, the Apk on DHL8 just FC
Sent from my GT-I9300 using xda app-developers app

Hy vadonka,
Can't test until now because I have no init.d support with kernel phenomenal or perseus...
Hope it will be solved today and then i test...
Gesendet von meinem GT-I9300 mit Tapatalk 2

The sgs3 TweakAIO apk f/c when i tried to open it.
Im on LH9.
And also there in no sgs3Tweak config in my data (that's why the app f/c???).
Thanks.

Hi Vadonka, How can this script can save more battery because i already using undervolt kernel GalaXsih 4.0 kernel..Isit will work in this kernel or will have some conflict or either suitable for stock kernel

vadonka said:
Update:
- Provided a config editor app, download from the first post attachment
Click to expand...
Click to collapse
Tried it "old fashion" (editing tweakaio.conf by hand), worked pretty fine that way. Now there's an app ! Sweet ! It works fine on LH1 base (CodecROM 7.7), and the app confirm changes applied by hand to tweakaio.conf are working.
Thanks !

eliashadow said:
The sgs3 TweakAIO apk f/c when i tried to open it.
Im on LH9.
And also there in no sgs3Tweak config in my data (that's why the app f/c???).
Thanks.
Click to expand...
Click to collapse
I had the same issue, but I solved it by creating a folder in /system/etc named init.d, then I flashed the script in cwm again, and voila'! It worked.
Sent from Hell with help from XDA

if the /data/tweakaio/tweakaio.conf file is not exsist or have 0 byte size or the permission is not 0777 then the app will FC. in some ROM also FC if this file is exsist but i dont know why yet this is not my app one of my friend wroted for my O2X init script. im just redesigned a little. im trying to figure out why FC on some ROM.
if the tweakaio.conf file is not exsist the init script will create at the next reboot automatically. at least it should be create

jothi2lingam said:
Hi Vadonka, How can this script can save more battery because i already using undervolt kernel GalaXsih 4.0 kernel..Isit will work in this kernel or will have some conflict or either suitable for stock kernel
Click to expand...
Click to collapse
well not only the undervolt can save battery
for example this parameters...:
dirty expire centisecs
dirty writeback centisecs
dirty ratio
dirty background ratio
plus the VM related parameters, timeouts, etc...
all of them together affected the battery life.

Huppen said:
I had the same issue, but I solved it by creating a folder in /system/etc named init.d, then I flashed the script in cwm again, and voila'! It worked.
Sent from Hell with help from XDA
Click to expand...
Click to collapse
vadonka said:
if the /data/tweakaio/tweakaio.conf file is not exsist or have 0 byte size or the permission is not 0777 then the app will FC. in some ROM also FC if this file is exsist but i dont know why yet this is not my app one of my friend wroted for my O2X init script. im just redesigned a little. im trying to figure out why FC on some ROM.
if the tweakaio.conf file is not exsist the init script will create at the next reboot automatically. at least it should be create
Click to expand...
Click to collapse
The file in init.d is ok.The problem for me is that i havent the config which i can manage the TweakAIO in /data.
So thats the reason that the app f.c, as i thought...
I hope to find the solution mister vadonka...
Revolution rom based on LH9.
edit: Im using wannam repack stock kernel.There is a script in init.d that it cant deleted (it recreated in every boot).
The script is:
Code:
#!/system/bin/sh
# WanamLite tweaks
sysctl -p
/system/bin/setprop pm.sleep_mode 1
/system/bin/setprop ro.ril.disable.power.collapse 0
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold ]; then
echo "80" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold
fi
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate ]; then
echo "60000" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate
fi
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor ]; then
echo "2" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor
fi
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/down_differential ]; then
echo "10" > /sys/devices/system/cpu/cpufreq/pegasusq/down_differential
fi
Its ok to have this and yours both???

@eliashadow
The only way i could delete s script in wanamlite roms was using rom toolbox.
But first i had to run from scripter a script to mount system as R/W.
I know it should had been mounted automatically but try it this way
Sent from my GT-I9300 using xda premium

eliashadow said:
The file in init.d is ok.The problem for me is that i havent the config which i can manage the TweakAIO in /data.
So thats the reason that the app f.c, as i thought...
I hope to find the solution mister vadonka...
Revolution rom based on LH9.
edit: Im using wannam repack stock kernel.There is a script in init.d that it cant deleted (it recreated in every boot).
The script is:
Code:
#!/system/bin/sh
# WanamLite tweaks
sysctl -p
/system/bin/setprop pm.sleep_mode 1
/system/bin/setprop ro.ril.disable.power.collapse 0
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold ]; then
echo "80" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold
fi
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate ]; then
echo "60000" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate
fi
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor ]; then
echo "2" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor
fi
if [ -e /sys/devices/system/cpu/cpufreq/pegasusq/down_differential ]; then
echo "10" > /sys/devices/system/cpu/cpufreq/pegasusq/down_differential
fi
Its ok to have this and yours both???
Click to expand...
Click to collapse
this script is manage the cpu governor. you can leave this for sure. it doesnt interfered with my script.
Sent from my GT-I9300 using Tapatalk 2

mariosraptor said:
@eliashadow
The only way i could delete s script in wanamlite roms was using rom toolbox.
But first i had to run from scripter a script to mount system as R/W.
I know it should had been mounted automatically but try it this way
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
Thanks but it didn't work for me too.The script recreated again after rebooting.
Edit:thanks mr vadonka.Now I'm ok.
Sent from my GT-I9300 using Tapatalk 2

eliashadow said:
Thanks but it didn't work for me too.The script recreated again after rebooting.
Edit:thanks mr vadonka.Now I'm ok.
Sent from my GT-I9300 using Tapatalk 2
Click to expand...
Click to collapse
Really weird
But as long as the script does not run, if there was a chance of conflict between the two scripts now is eliminated by renaming it.
Edit: if you rename it and reboot, do you then have 2 files ( the renamed one and the correct).
I flashed wanam's kernel but cannot recreate. It gets deleted correctly.
Sent from my GT-I9300 using xda premium

mariosraptor said:
Really weird
But as long as the script does not run, if there was a chance of conflict between the two scripts now is eliminated by renaming it.
Edit: if you rename it and reboot, do you then have 2 files ( the renamed one and the correct).
I flashed wanam's kernel but cannot recreate. It gets deleted correctly.
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
I edited it inside and changed the lines, not the name of the script.
But if the dev here said that is ok, everything is ok
Sent from my GT-I9300 using Tapatalk 2

[April 2, 2016][MOD][FIX]MaxOpt R2 1.0.6 UPDATED CODE BASE

NEW EASY INSTALLER, RECOVERY ZIP
Total overhaul of code.
*HELP WANTED, PM FOR RELEVANT DETAILS*
This software package was originally just made for my personal use to rectify the issue of my phone not entering deep sleep when idle and me not having access to a charger for the majority of the day while also improving multitasking because being my phone is also my build environment/office environment, I am frequently jumping around various apps that I'd prefer to keep open.
Things this package accomplishes on your phone (very simple and brief summary):
*Forces entry into deep sleep as soon as the screen is off (if enabled, on by default). It also has audio detection so you can listen to music with the screen off without unwanted deep sleep entry.
*Improves multitasking, no more apps having to reload/redraw when you switch back to them.
*Automatic odexing of all apps, including new installs (if enabled, pre-lollipop ROM's).
*Easy management of swap.
*CPU management. You can set your own values to be locked (no other app can change them) or let its device manager automatically set CPU frequencies and the governor you specify.
*Dynamic Max CPU Freq: When enabled (on by default) it will automatically scale the max CPU frequency value depending on the CPU load. This can help with governors that favor the high end of the frequency table too much by allowing you to save battery but have the CPU power available when needed, without having to adjust anything manually whenever you go from doing something processor demanding to having your phone sit idle.
*Fixes issues with several kernels where the touch screen is unresponsive after waking the device. No more inconvenient force reboots.
*Enables all idle and suspend states available (they are disabled by default quite often) and can help get your device into the lower C-States.
*Fixes broken links to firmware files caused by buggy init scripts on some ROM's.
New/Other features:
*New recovery flashable installer
*Force system wide GPU rendering and faster framerate.
*Fixes Dt2w and Sw2w lock screen freeze bug.
*Now compatible with KSM.
*Faster app loading and responsiveness. Key android services are given priority status for I/O and CPU resources.
*Multitask over 20+ apps simultaneously without any redraws and low-latency app switching (provided you have the swap space)
Tip: I use the large amount of unused space on /system to increase the size of that MaxOpt managed swapfile.
*Fixed the crash on boot issue between MaxOpt and some kernels.
Default MaxOpt config:
•Swap on, default MaxOpt generated swapfile size is 64 MB, with one made on /data, one on /cache, and one on /system if mounted rw.
•Auto-odexing off.
•Hotplugging compatibility on.
•User CPU settings off, auto-device manager on.
•Deep Sleep immediately on screen off enabled.
•KSM off (you must have a kernel that supports it to enable this option and have it work).
•Kernel settings on.
•Everything is forced to be drawn by the GPU.
All of the above listed features are user optional/tuneable.
For those who wish to only use MaxOpt for fixing the lock screen freeze bug associated with some kernels/DT2W/S2W use the following link: http://forum.xda-developers.com/showthread.php?t=3061589
If you would like to just use individual components or adjust program settings from a terminal app, here is an example usage and description of their individual functions as well as other useful documentation (VERY OLD DOC, NEEDS LOTS OF UPDATES):https://docs.google.com/file/d/0B_hgNZE_j5sVbEN4ZUtkS2p0bW8/edit?usp=docslist_api
Terminal Emulator is what I would recommend for use with managing MaxOpts' settings.
System Requirements (not entirely sure due to lack of public testing):
Busybox
A terminal app
A kernel that can best be utilized by these programs.
Please make a nandroid backup before using.
And here is the MaxOpt installer ( R2 1.0.6 ):
* https://drive.google.com/file/d/0B_hgNZE_j5sVaGdxV0FfODdxbVU/view?usp=docslist_api
Changelog:
R2 v1.0.6- Adjustments to write buffering and multitasking memory performance.
R2 v1.0.5a- Fixed a bug present in both this project and MaxLife where data wasn't validated thoroughly enough before using it.
R2 v1.0.5- Added a new completely experimental new user tuneable (on/off, default off) that changes runtime memory allocation values. Only activate it if you have a large amount of swap.
R2 v1.0.0- Totally rebuilt the project, installable with a recovery flashable zip now, kernel image installer is no longer compatible and is scrapped.
For those still getting crashes:
The issue still appears to be related to the device radio when it happens, so, after a crash could you please force reboot your device and try to disable mobile data when it boots before it crashes again and please post a copy of /proc/last_kmesg. Thank you.
Screenshots of battery screen showing time spent in sleep:
https://docs.google.com/file/d/0B_hgNZE_j5sVSjRUU0ZlX0UwUWc/edit?usp=docslist_api
https://docs.google.com/file/d/0B_hgNZE_j5sVSmNjYThkUzAtNGM/edit?usp=docslist_api
https://docs.google.com/file/d/0B_hgNZE_j5sVcWxJd0JyV09nMDA/edit?usp=docslist_api
Please thank if my software has helped you and please leave logs and descriptions of problems if my software did not work for you.

Wow, this looks amazing. Very nice work.
I Will be playing with this for the next few days.
Sent from my Moto G using Tapatalk

Damn this looks complicated as hell haha. Good job OP

Very nice job

Thank you very much everyone. Glad for the positive feedback, this is my first public software release. I daylight in a machine shop, so this was far from my field of expertise and a long learning experience for me

I tried it on faux kernel 014m.
But my phone bootlooped
I have faux clock app.
Is it causing the problem?
Thanks

One possible problem could be the boot image it made was over 10 MB depending on the size of the input one. If that wasn't the issue, did you disable signature checking? Also this is currently not ART compatible. It is also important that you run the installer from a partition that supports octal permissions, so the emulated sdcard is a no go.
Edit: it may be worth trying disabling the faux clock app too. I don't have that kernel or app to try for myself but this mod does affect CPU settings so it could be a conflict. If none of those work, I may have to look into updating my installer with an alternate method for incompatible kernels.

elrod16 said:
One possible problem could be the boot image it made was over 10 MB depending on the size of the input one. If that wasn't the issue, did you disable signature checking? Also this is currently not ART compatible. It is also important that you run the installer from a partition that supports octal permissions, so the emulated sdcard is a no go.
Edit: it may be worth trying disabling the faux clock app too. I don't have that kernel or app to try for myself but this mod does affect CPU settings so it could be a conflict. If none of those work, I may have to look into updating my installer with an alternate method for incompatible kernels.
Click to expand...
Click to collapse
I followed steps as below:
I put that 2 files in the data partition.
Then boot.img of faux.
I set permission 755 for both files and boot.img
Then from terminal I executed the command.
I got new_image.img
I repack the zip using this new boot image and flashed it in recovery.
Then I reboot.
Phone booted and stuck on "optimizing apps 1 of 98"
Then again same.
Also I had 700mb of free memory when I tried this.
When I again booted using faux kernel I had 450mb of free memory.
Can you guess what's going wrong?

Did you disable APK signature checking?

elrod16 said:
Did you disable APK signature checking?
Click to expand...
Click to collapse
Sorry I forgot that.
Where exactly should I put those 2 files.
Was I doing right to put them in data partition?
And after first boot can I enable signature verification?
Do I need to disable it before every boot?

Unfortunately for now it needs to be off whenever an app is upgraded or added, but can be enabled after the reboot that that happens on, and yeah, /data works

Even after disabling signature verification it doesn't work on faux boot.img
Am I doing right?

For whatever reason it sounds like the dexy binary isn't playing well with your phone, I'll make a new installer with the option of disabling it for incompatible setups for the time being, but the other ones should still work. I'll keep ya posted.

My rom is stock 4.4.4
I will try again with disabled optimization.

kedar512 said:
My rom is stock 4.4.4
I will try again with disabled optimization.
Click to expand...
Click to collapse
OK, hopefully that should be the only part of this package not working for ya. Keep me posted, I'll continue trying to figure this out if it persists.

elrod16 said:
OK, hopefully that should be the only part of this package not working for ya. Keep me posted, I'll continue trying to figure this out if it persists.
Click to expand...
Click to collapse
No luck bro
Same problem.Stuck at optimization.
Should I try it on Xperience kernel?
Its not working with faux.

kedar512 said:
No luck bro
Same problem.Stuck at optimization.
Should I try it on Xperience kernel?
Its not working with faux.
Click to expand...
Click to collapse
I would say yeah, try it with it and see if it makes a difference

Also did you try the new build with a clean restore? (Before any of the failed install attempts) Try not wiping the cache/dalvik-cache after install and flash.

I tried again but this time booted upto lock screen and rebooted.
I tried with new build.

after placing ./maxopt boot.img appears running with dexy enabled.
That means it's already working? If yes, have to do anything else?
Every time you turn the meter will have to repeat the procedure?
Sorry my bad english

[Q] Init.d Support & SELinux

I am sure this will soon be moved into general ware it will sit among questions not related to compiling or Rom building but I am in hope it is her long enough to be read and maybe addressed.
I rely a bit on init.d support for my Rom's especially CM12. I do this so changes can be made without changing the code or default.xml as much as possible in adition to Google Apps I would like not included. My basic philosophy is if it can be installed via Play Store than I would like the first boot only to include the Google Core files and Play Store so for example if you look at the below github link will see the changes I needed in CM11 to replace the default launcher with the Now Launcher, Replace Stock Camera with Google Camera and the same for the Calendar but would like the users to decide if they would like to include whatever apps they would like as oposed to needing to remove the APK. Anyhow in short I use init.d to avoid making as little changes to code or default.xml as possible as well as what gapps package is used. Many include incompatible libs as a few for my CM based incarnation need to be replaced using either the Stock lib or libs taken from data/app that are more current so the script on first boot after flashing gapps will move files from a staging directory and place or replace ware needed and then remove the staging directory.
CM11
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/app-update
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/cleanup
CM12
https://github.com/Starship-Android/android_device_starship-common/blob/cm-12.0/app-update
https://github.com/Starship-Android/android_device_starship-common/blob/cm-12.0/cleanup
So far have done a decent amount of Google work and have learned my problem with both AOSP and CM is that SELinux is blocking init.d but have not found anything on how to address steps on fixing for what I use it for. The above links are just a small part but give enough of an idea of what I am trying to accomplish via init.d.
Any help would be appreciated. Until now I had fought a bit with SELinux once introduced to apply to the Kernel for the device I was developing at the time HTC EVo V 4g & EVO 3D but since then is still unfamiliar territory as I have not needed to learn much about it other than implementing into a Kernel when cm-10.2 was released. Both Devices had not been updated past ICS by HTC. I am thinking that maybe I need to add or change permissions in one of the rc files in the boot.img but honestly not sure as mentioned I have found plenty of mentions that SELinux is what is causing my init.d problems but have not seen anything on a solution or even just a link to an explanation of what specific changes had been made regarding SELinux or a further more detailed explanation specific to what in SELinux is responsable so can try to understand enough to figure out myself how to make the necessary changes .
Otherwise like my previous thread on What needs to be done differently developing with AOSP for developers who have gained all their experience bringing Cyanogen to new devices and other Sources who are now trying to develop AOSP Rom's for Nexus devices think this is a topic that would help developers save time and research but will probably be moved to general Q&A. Is off topic but with other Devices if questions or topics required basic knowledge of compiling source, Kernel changes or github would see the opposite in the threads being moved into developer discussions and not for example move a thread discussing say compiling the AOSP Kernel in line compiling both Rom and Kernel together or code changes needed in the build repository / Directory to stop custom recovery from being replaced with Stock recovery when users flash a custom Rom and reverting from Block based update zips to using the old school non Block based update zips. So far though I have posted these topics here as you don’t see members with such knowledge looking through the general Q&A section. Maybe I just inadvertently made an enemy of an admin as was surprised almost besides myself when a previous thread in the middle of discussing what changes would be needed for in line AOSP Kernel compiling in line like CM does compiling the Kernel along with the Rom and doing away with pre built Kernels. Needless to say the discussion was moved and died in general Q&A so if this is actually read I am asking that this thread remain in Developer Discussion long enough for an answer or at least a link to a resource covering the topic as a topic regarding the implementation of SELinux policy in a custom Rom will surely die in general Q&A, Thanks!

Are you OK with just disabling selinux? That's what I ended up doing. I recompiled the kernel with the option of using a boot command-line parameter to enable or disable as I see fit.

Gene Poole said:
Are you OK with just disabling selinux? That's what I ended up doing. I recompiled the kernel with the option of using a boot command-line parameter to enable or disable as I see fit.
Click to expand...
Click to collapse
When you have the option to disable or enable it, how do you set it to "disabled" afterwards?
I tried to compile a kernel+rom with selinux disabled many times but got only bootloops. With Kitkat it was working flawless.

L changed a partition entry adding a selinux policy to the mounting information. You need to change this entry int fstab.hammerhead to keep it from hanging on boot:
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337[COLOR="Red"],context=u:object_r:firmware_file:s0 [/COLOR] wait
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337 wait
Then your kernel should boot. You can add a command line entry to the boot image to turn it off or on.
Edit:
You may also have to comment out a line at the top of init.rc. I'm not sure, but mine is commented so I must have done it for some reason.
Code:
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
import /init.trace.rc
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Apply strict SELinux checking of PROT_EXEC on mmap/mprotect calls.
[COLOR="Red"]#write /sys/fs/selinux/checkreqprot 0[/COLOR]
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
setcon u:r:init:s0
# Set the security context of /adb_keys if present.
restorecon /adb_keys
start ueventd
# create mountpoints
mkdir /mnt 0775 root system

Thanks, will give it a shot!
Any downside on disabling it?

Well, obviously, anything that selinux might be protecting you from would be able to get through, but as developers, we're pretty pessimistic about what we run on our devices.

Gene Poole said:
Well, obviously, anything that selinux might be protecting you from would be able to get through, but as developers, we're pretty pessimistic about what we run on our devices.
Click to expand...
Click to collapse
So its only f*** the NSA for us then!
So i add this to boardconfig: androidboot.selinux=disabled
Then do those things you said. Would i need to put on kernel defconfig :
#CONFIG_SECURITY_SELINUX=is not set
Or will i have to add that "allow selinux disabled on boot"
Or is it enough to have that boardconfig parameter and your things.
Thank you very much mate!
Oh and yes im building a full rom with inline kernel

I think that should do it. I've got a pretty hacked up boot.img so I can't be sure what's in there for what.
I have the following setting in my kernel config:
Code:
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y

Ok thanks for all the Selinux help but may look like I’m not able to run init.d scripts because root is disabled by default. So bringing up a new topic about starting first boot with root access. I have been looking over the CM github for a commit that turns it off so I can either manually revert or rebase a clone.

Gene Poole said:
L changed a partition entry adding a selinux policy to the mounting information. You need to change this entry int fstab.hammerhead to keep it from hanging on boot:
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337[COLOR="Red"],context=u:object_r:firmware_file:s0 [/COLOR] wait
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337 wait
Then your kernel should boot. You can add a command line entry to the boot image to turn it off or on.
Edit:
You may also have to comment out a line at the top of init.rc. I'm not sure, but mine is commented so I must have done it for some reason.
Code:
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
import /init.trace.rc
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Apply strict SELinux checking of PROT_EXEC on mmap/mprotect calls.
[COLOR="Red"]#write /sys/fs/selinux/checkreqprot 0[/COLOR]
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
setcon u:r:init:s0
# Set the security context of /adb_keys if present.
restorecon /adb_keys
start ueventd
# create mountpoints
mkdir /mnt 0775 root system
Click to expand...
Click to collapse
Bumb to this method. Something is changed in Nougat, after editin all these stuff, i will loose data and cell connections..

[DEVS-ONLY] SuperSU developer discussion

THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.

Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary

garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.

NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary

spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance

@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done

Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)

Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?

Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9

garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)

garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.

Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards

dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.

No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.

dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.

[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #

dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!

I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those

@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.

nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.