yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] osm0sis:
Haha nah, I picked up most of what I know in the same way, hanging out in kernel threads, talking to devs and tinkering. Also searching and reading a lot. There's still lots (and lots!) of ROM, kernel and app dev stuff I don't know much (or anything!) about, but I know it'll keep making more sense the longer I hang out on xda. :)
[Android Software/Hacking General [Developers Only]] _that:
Yes, searching and reading is important. I like your threads because I can always learn something from them.
[Android Software/Hacking General [Developers Only]] skulldreamz:
Spoken like a true champ! And to anyone that feels overwhelmed at times, I totally understand. Something that I started doing about 6 months ago was everyday just look up 1 thing for example the syntax of a command or a applet, something small and start a log in a notepad in like Google keep or whatever so you can always go back and benefit from the research you put it in case you forget. Just a idea
[Android Software/Hacking General [Developers Only]] edu4rd0zs:
Definitely won't stop. I want to learn and understand more and ultimately compile a ROM and kernel, then share it with the community. I bet it feels good to have it shared all across the world :cool:
[Android Software/Hacking General [Developers Only]] veez21:
That's something that should be learned. I started here in xda about 5 months ago and i can now understand/make some things likely init.d scripts, update-binary (edify) and other things thanks to the main devs here in xda. [MENTION=631273]Chainfire[/MENTION] [MENTION=4544860]osm0sis[/MENTION] [MENTION=5514152]Paget96[/MENTION]. [emoji106]

Sent by a Cool Guy using XDA-Developers mobile app
[Android Software/Hacking General [Developers Only]] osm0sis:
Haha thank you, but really now! :o

Chainfire is definitely a 'main' dev and in a whole league of his own, I just know a thing or two about shell script and automation. ;)
[Android Software/Hacking General [Developers Only]] mrrocketdog:
[MENTION=631273]Chainfire[/MENTION] shmainfire ; what , like he made a puzzle app or something :)

just kiddin. settle down :)

hey i can now copy/paste , use some fastboot commands , use TE to reboot AND appreciate all the knowledge , time (volunteered , no-less) & effort that all of you @ devs provide.:highcowboy:

ty all. (old guy trying to learn new tricks)

"err on the side of kindness"
[Android Software/Hacking General [Developers Only]] ephexxis:
i use clipper sync for this cause writing is for the proles
[Android Software/Hacking General [Developers Only]] osm0sis:
I got my GN fired up again last night and tested this out; it totally worked when I manually put back the old .xml and rebooted after a forced rebuild! All apps retain their permissions. Awesome idea! :D

Now just to figure out the best time/way in the process to automatically put it back... Waiting for it to reappear might not be the best way since I think it writes to it multiple times during a dexopt, but maybe if we just wait for bootcompleted? First I'll try just at the end of the script if it detects a backup. I'm going to see about extending the script to work on multiple users' runtime-permissions files as well.
[Android Software/Hacking General [Developers Only]] mikeoswego:
That's good to know that restoring the backup doesn't break things! Perhaps making a backup would be an interim step; it could be manually restored (or a script run from terminal) instead of trying to walk through all the apps that need permissions.

I'm running from /su/su.d and read somewhere that SuperSU v2.76 stops the boot process until all su.d scripts complete; if that is correct, it will complicate this a bit.
[Android Software/Hacking General [Developers Only]] str8str:
Is the kernel cleaver script the same as wiping system before flashing a new kernel? Everyone is saying to reflash your Rom before changing kernels now which is a pain so will this do the same?

?
[Android Software/Hacking General [Developers Only]] rignfool:
No...

The init scripts in the kernel..

init.rc

init.shamu.rc

etc..

Are all part of the zimage... Which is half your kernel...

They are modified by the AnyKernel2 script...
[Android Software/Hacking General [Developers Only]] hinxnz:
I think you mean zImage is the kernel and they're part of ramdisk which is basically half of your boot.img :)
[MENTION=5201751]str8str[/MENTION] if system is not modified by custom kernel then you only need to flash the boot.img from your ROM.zip
[Android Software/Hacking General [Developers Only]] :
[MENTION=4544860]osm0sis[/MENTION]

I saw Busybox 1.25 was release so I updated your installer to 1.25 over 1.24-2. I've attached it to this post, if you'd like I will remove it. It's been tested :good:
[Android Software/Hacking General [Developers Only]] rignfool:
^^^^

What he said...
[Android Software/Hacking General [Developers Only]] osm0sis:
No please remove your attachment, I've explained a few times why I'm waiting for the stable release (1.25.1).
[Android Software/Hacking General [Developers Only]] :
Removed :good:
[Android Software/Hacking General [Developers Only]] str8str:
OK them after flashing boot IMG flash new kernel? Or flash cleaner zip first? I'm referring to the emergency kernel zip I'm op
[Android Software/Hacking General [Developers Only]] hinxnz:
Yes flash your new custom kernel straight after the boot.img, no need to reboot in between.

I had a look at that zip and it moves your init.d scripts so they don't execute and also removes preferences from many kernel tuning apps. If you use a kernel tuning app and unsure how to reset everything, then maybe it a good idea to flash it so you can experience the kernel as the dev intended, otherwise it's not necessary.

I think the zip is intended for just say if you muck some setting up causing a bootloop or something, it will remove the settings and allow you to boot again, hence the name of it.
[Android Software/Hacking General [Developers Only]] mikeoswego:
I've submitted a new pull request on the gappsintegrator github.

Added in backup up of user(s) runtime-permissions files and then restore after boot is complete with a forced reboot for those apps needing force rebuild. (Only does the backup for the first app needing force rebuild since the files would have been deleted for any following app(s) requiring force rebuild.)

Found that some apps when updated would have a one line <updated-package> entry in packages.xml (Maps and GMS) instead of multiple lines as the script expected and put in a fix for that (only in the Marshmallow section, if KitKat/Lollipop can have the same situation, that fix should be copied to those sections as well.)

On my device, the time is in 1970 when the script starts, moved the log time stamp to the end where $logbuff is written out since it has the correct time by then.

Found that Google Play Games is an app requiring force rebuild.

For safety, I put in a limit of 4 apps per session to be integrated just so things will be quiet when the device starts to optimize.

Added a line to go ahead and delete the /data/app copy of the app during the session where packages.xml has already been updated to point at the /system/app copy (only in the Marshmallow section, left the lines touching integrated and looking for that on the next session as a backup for the deletion.)

(You may have already been notified of the pull request, sorry that was a little messy; I'm really done now!)
[Android Software/Hacking General [Developers Only]] KaMyKaSii:
[MENTION=4544860]osm0sis[/MENTION] if it is not asking too much you could create a zip that wipe all /data except for the internal memory and user apps? Similar to FlashFire wipe function, allowing TWRP users migrate from rom without the need to backup apps before every time
[Android Software/Hacking General [Developers Only]] _that:
This should really be a TWRP native feature.
[Android Software/Hacking General [Developers Only]] pkelly517:
It is.

TWRP->Wipe->Advanced Wipe
[Android Software/Hacking General [Developers Only]] KaMyKaSii:
Hearing _that from you makes me full of hope for a future update

It is not. Except for internal memory, or you wipe all /data or nothing
[Android Software/Hacking General [Developers Only]] shoey63:
Do you have the the time (or inclination) to code it, and submit it to Omnirom gerrit?
[Android Software/Hacking General [Developers Only]] osm0sis:
Uploaded ADB Screenshot for GN v1.2 to the OP. It now has proper support for both possible pixel formats - depending on which recovery (ie. CWM or TWRP) you're running - and determines the recovery type on-the-fly (thanks for the idea PhilZ). Now hopefully this will also work on the several derivative recoveries out there (including PhilZ-CWM). Let me know if you run into any problems. :) Original version had 53 downloads. :good:

Edit: I just confirmed the CWM pixel format does work with PhilZ-CWM, and that it is (luckily) correctly determined as CWM even though PhilZ also supports the TWRP backup format (so both strings I look for are in there). Should be fine unless PhilZ drastically changes his code in the future, since I just go with whichever is found first. I also did some research and sometime later this year the 4ext recovery may finally come out of closed testing pre-alpha for the GN. I'll cross that bridge when we come to it. ;) :D
[Android Software/Hacking General [Developers Only]] osm0sis:
In the interest of setting the lmk minfree values as soon as possible, I wanted to see why it requires a delay on boot, so...

# lmk tweaks
rm /sdcard/test.txt;
echo "begin" >> /sdcard/test.txt;
lmk=4096,8192,12288,16384,40960,65536;
bootlmk=`cat /sys/module/lowmemorykiller/parameters/minfree`;
while sleep 1; do
cat /sys/module/lowmemorykiller/parameters/minfree >> /sdcard/test.txt;
currlmk=`cat /sys/module/lowmemorykiller/parameters/minfree`
if [ $currlmk != $bootlmk -a $currlmk != $lmk ]; then
echo $lmk > /sys/module/lowmemorykiller/parameters/minfree;
elif [ $currlmk == $lmk ]; then
echo "done" >> /sdcard/test.txt;
exit;
fi;
done&

The resulting output is this:

begin
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
1536,2048,4096,16384
8099,10132,12165,14213,16245,20295
4096,8192,12288,16384,40960,65536
done

LMK apparently has a value on boot that is later changed to the device default, and you can't change it before that or it'll get overridden by the device default when that happens. The time required seems to vary by device.

So I here's the new version (in the latest 925vm), without all the crazy logging and simplified:

# lmk tweaks
minfree=4096,8192,12288,16384,40960,65536;
lmk=/sys/module/lowmemorykiller/parameters/minfree;
minboot=`cat $lmk`;
while sleep 1; do
if [ `cat $lmk` != $minboot ]; then
[ `cat $lmk` != $minfree ] && echo $minfree > $lmk || exit;
fi;
done&

Should be perfect unless there's an Android device out there that boots directly to the normal minfree values. That certainly isn't the case with the GN or N7, they both have that 1536,2048,4096,16384 interim value. Hopefully this is a universal Android thing, since this is a reasonably clean workaround at the moment because of it.
[Android Software/Hacking General [Developers Only]] Midomad:
I don't see 975experimental anymore it's included in 925vm?

Envoyé depuis mon Galaxy Nexus avec Tapatalk
[Android Software/Hacking General [Developers Only]] Empty Hand:
I don't know if it's a placebo, but I just added your experimental script and it feels like my phone is on speed!
[Android Software/Hacking General [Developers Only]] demlv:
ADB reports device offline

Probably OT, but I've always had good luck with you guys, and I noticed this problem when trying to update the backup of my 'SD Card' using osm0sis' adbsync script, which I have run successfully numerous times in the past -- so I'll ask here anyway.

Just noticed earlier today that I cannot communicate with my phone via ADB. GNex shows the standard CM ADB notification, but my PC reports "long_device_serial_no. offline" no matter what I try. Researched it for a couple of hours. Tried different USB ports, cables, killing and restarting adb server and probably a few other things I read about, but still no joy.

Any ideas?

EDIT: Updated literally EVERYTHING in the SDK, rebooted both the PC and the phone, reconnected, typed "adb devices" and I got the prompt on the phone allowing the connection. All is well again.
[Android Software/Hacking General [Developers Only]] osm0sis:
I know on stock JB4.2.2 there's a bug with adbd along those lines when you're trying to use USB Debugging to connect (and also one where "adb wait-for-device" just hangs). Typing su in Terminal Emulator, granting root and then "adb kill-server" and "adb start-server" generally fix it. You might need to run those commands on the PC side as well.

Can't really speak to CM or what they've got going on, but the simplest solution is to reboot to custom recovery since that work around isn't required there. CWM is how I've always operated. :)
[Android Software/Hacking General [Developers Only]] osm0sis:
Just updated my Notification Toggle Holo Stock icon pack with a few new ones j4velin added support for recently (Home and Haptic Feedback). :good:
[Android Software/Hacking General [Developers Only]] MaLiXs:
Hey osmosis can you point me where i cam find the init script for color setting please

Send from my Pure Franco GNex
[Android Software/Hacking General [Developers Only]] osm0sis:
Check the scripts post of the OPs.. ;)
[Android Software/Hacking General [Developers Only]] MaLiXs:
Oh sorry.. Didn't take the time to read the op...

But now I would like to know what it acl set value?

Also for omapdss, Is this corresponds to omap gama interface? If I'm correct what i should write in th script tho have the same value than in fku (1.2)

Send from my Pure Franco GNex
[Android Software/Hacking General [Developers Only]] osm0sis:
Content Adaptive Brightness (acl) is a simple Boolean. 0=off, 1=on. 1 is default.

OMAP Gamma Contrast (omapdss) has a scale difference from f.Ku but it's pretty well documented. 5=1.0, 6=1.2 ... 10=2.0. 5 or 0 (disabled), are the same and default. For fun, you can also try 1-4 (which many apps don't allow) to experiment with lowered contrast, but this generally looks washed out and dusky.
[Android Software/Hacking General [Developers Only]] MaLiXs:
Im us pitch black theme.. With gama like that i got a blue tha i really like..

Send from my Pure Franco GNex
[Android Software/Hacking General [Developers Only]] osm0sis:
Heads up, the Franco's Dev Team Google Group is now open for public viewing since we've pretty much wrapped up and finalized all of our research and testing. Finalist 925vm init.d script was posted to my Dev-Host on Wednesday. Testers welcome. :)
[Android Software/Hacking General [Developers Only]] bigknowz:
Capturing getprio output

delete
[Android Software/Hacking General [Developers Only]] osm0sis:
I see you deleted this so I guess maybe you worked it out, but I want to mention that you could grab the part you want by piping it to cut like "getprio 123 | cut -d: -f2", changing the -f number should determine the field it shows since they're all separated by a :. :good:
[Android Software/Hacking General [Developers Only]] bigknowz:
Capturing getprio output

Thanks for replying to my delete, that is true dedication. And thanks for the script. I had some syntax errors, but figured it out. Using getprio to renice my music player because opening Kindle causes music to stop.
[Android Software/Hacking General [Developers Only]] MaLiXs:
I share here my color init script of my own favor of ak kernel color

http://goo.gl/bqEHd

Send from my Pure Franco GNex
[Android Software/Hacking General [Developers Only]] osm0sis:
I've noticed something really bizarre about the lmkwhitelist/975exp on the GN vs. N7. On the N7 it all (niceness, oom_adj value and reduced oom_adj file permissions) gets set correctly and you can come back and check it later with several days of uptime and it'll still all be set correctly. On the GN this isn't the case. Niceness sticks fine but both the oom_adj value and permissions get changed back by something, sometime within the first hour of uptime. Also sometimes for systemui the oom_adj file perms don't set correctly, but the value and niceness apply and stick fine.

I wrote a little init.d script to show the pid, class, niceness, oom_adj value and oom_adj file perms every second, so I still don't know the "why", but here's the approximate "when" of the weirdness of the launcher oom_adj getting reset:

1 second(s):

[no systemui]

[no launcher]

26 second(s):

962: com.android.systemui: 0: 0: -rw-r--r--

[no launcher]

27 second(s):

962: com.android.systemui: -18: -17: ---x------

[no launcher]

28 second(s):

962: com.android.systemui: -18: -17: ---x------

1232: com.android.launcher: 0: 0: -rw-r--r--

54 second(s):

962: com.android.systemui: -18: -17: ---x------

1232: com.android.launcher: -18: -17: ---x------

871 second(s):

962: com.android.systemui: -18: -17: ---x------

1232: com.android.launcher: -18: -17: -rw-r--r--

880 second(s):

962: com.android.systemui: -18: -17: ---x------

1232: com.android.launcher: -18: 6: -rw-r--r--

You can see there's the gap from the sleep 60, but since the sleep is happening before init.d from within fkbootscript.sh it ends up at 54 seconds from where the init.d script recording all this started counting. Then the weird thing happens at 871 seconds (14m31s): the oom_adj file permissions get reset, and then 9 seconds after that (14m40s) the value as well. :confused:

I'll mention [MENTION=4615478]boype[/MENTION] since I know he uses a version of the lmkwhitelist in Fancy Kernel as well. Anybody have any ideas?
[Android Software/Hacking General [Developers Only]] dirtyreturn:
Edit+Edit+ Sorry, xda site is acting pretty weird for me atleast. [MENTION=4544860]osm0sis[/MENTION] Your init.d pack was designed with franco kernel in mind, right? Say I'm *testing* another kernel. Will the values of certain parts of the scripts have any ill effect on values or ... not present? The scripts will only tune/enhance the values already present? Could you give a less technical explanation if you don't mind doing so?
[Android Software/Hacking General [Developers Only]] _that:
I don't want to promise anything, but I've noted it on my personal "ideas for new features" list.
[Android Software/Hacking General [Developers Only]] Maxr1998:
After reading his post multiple times, I got the understanding that he wants to wipe data except internal storage AND apps (not the backup of the apps), means /data/ excluding /data/media/0/ and /data/app/..
[Android Software/Hacking General [Developers Only]] osm0sis:
It suggests /data/data should be saved as well but differentiating between system apps and user apps and only saving user app data?

That'd be a great advanced features for TWRP. :D

I don't have a lot of free time at the moment. I've got a few big good things on my todo I'm barely finding enough to pick away at (checking out mike's gappsintegrator updates, etc. - hoping to do so on my days off Sunday or Wednesday). For now, until it maybe becomes a built-in TWRP feature, you could take a stab at it using my Complete Shell Script Zip Reference thread. :)
[Android Software/Hacking General [Developers Only]] KaMyKaSii:
Exactly. The Flashfire already does this but if you are already in TWRP and without installed system ...

Okay, I understand that to be pretty busy with the amount of scripts you have. And speaking of that, I have a file access problem both on external and internal memory, then used your script to fix permissions and gave it. He should not read the file "/system/lib64/libcutils.so"?

sdcard Fix Permissions Script
by osm0sis @ xda-developers

Mounting...
mount: mounting /dev/block/dm-0 on /data failed: Device or resource busy

Setting /data/media to media_rw and fixing...
I:Set overlay: 'lock'
I:TWFunc::Set_Brightness: Setting brightness control to 5
I:TWFunc::Set_Brightness: Setting brightness control to 0
ioctl(): blank: Invalid argument
ioctl(): blank: Invalid argument
I:TWFunc::Set_Brightness: Setting brightness control to 162
I:TWFunc::Set_Brightness: Setting brightness control to 5
I:TWFunc::Set_Brightness: Setting brightness control to 0
ioctl(): blank: Invalid argument
CANNOT LINK EXECUTABLE: "/system/lib/libcutils.so" is 32-bit instead of 64-bit
page record for 0x7f79dec010 was not found (block_size=32)
/tmp/updater: line 47: /system/toolbox: not found
CANNOT LINK EXECUTABLE: "/system/lib/libcutils.so" is 32-bit instead of 64-bit
page record for 0x7f9ca16010 was not found (block_size=32)

Setting TWRP directory perms...

Unmounting...

Done!
[Android Software/Hacking General [Developers Only]] osm0sis:
That's this function executing:

restore_con() {
for i in /system/bin/toybox /system/toolbox /system/bin/toolbox; do
LD_LIBRARY_PATH=/system/lib $i restorecon -R $*;
done;
restorecon -R $*;
}

So a couple of errors are generally expected when it's cycling through locations. As for the linking, [MENTION=631273]Chainfire[/MENTION] only links /system/lib also, presumably just to accommodate older recoveries, where newer ones (which all 64-bit devices should have) will have things working without needing to use the system one.

I could set the path with lib64 at the front in future updates, and that should work on both architectures, but currently the overall function should be working fine as well because of that final command.
[Android Software/Hacking General [Developers Only]] KaMyKaSii:
I think we had a misunderstanding. This log is from TWRP 3.0.2
[Android Software/Hacking General [Developers Only]] mikeoswego:
Your TWRP log was created while running the fix permissions script. In the section of the script that osm0sis posted in his reply, it looks in 3 different places for toybox / toolbox. Various phones have these in different places, so the script has to figure out where they are and when it looks in a place where they don't exist, TWRP will generate the not found error you are seeing. So it is normal to see some errors when running this script and others like it.

The last 3 lines of your log show that the script completed successfully.
[Android Software/Hacking General [Developers Only]] PiggyFlooper:
[MENTION=4544860]osm0sis[/MENTION]

I see you as being a master of scripting. Will you please teach me how to write a separate /sbin/sh script to be ran in recovery that senses the android version, such as equal to or above 5.0 (50) like this-

Call it sense.sh

in updater-script-->

run_program("tools/sense.sh");

#!/sbin/sh

android_version="?"

if [ "android_version" -lt 50 ]; then

cp /tmp/priv-app/NexusLauncherPrebuilt/Nexus LauncherPrebuilt.apk /system/priv-app/NexusLauncherPrebuilt.apk;

else

cp /tmp/priv-app/NexusLauncherPrebuilt/Nexus LauncherPrebuilt.apk /system/priv-app/NexusLauncherPrebuilt/NexusLauncherPrebuilt.apk;

fi;

Please help me to figure out how to write this so it will get android version
[Android Software/Hacking General [Developers Only]] _that:
Take this line from an apprentice of scripting: ;)

apilevel=$(awk -F '=' '/^ro.build.version.sdk/ { print $2 }' /system/build.prop)

Make sure that /system is mounted before.

The list of SDK versions is here -> https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels
[Android Software/Hacking General [Developers Only]] osm0sis:
Yup, [MENTION=4878287]_that[/MENTION] is right on. Only thing different I'd suggest would be using grep and cut to find the prop value since CM Recovery doesn't have awk. :)

I've always used the following:

file_getprop() { grep "^$2" "$1" | cut -d= -f2; }

Then you can invoke it as follows:

apilevel=$(file_getprop /system/build.prop ro.build.version.sdk)