[TOOLS][ZIPS][SCRIPTS] osm0sis' Odds and Ends [Multiple Devices/Platforms]

[veez21]

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

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. @Chainfire @osm0sis @Paget96. [emoji106]

Sent by a Cool Guy using XDA-Developers mobile app

 

[osm0sis]

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. @Chainfire @osm0sis @Paget96. [emoji106]

Haha thank you, but really now!

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.

 

[mrrocketdog]

@Chainfire 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"

 

[ephexxis]

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

i use clipper sync for this cause writing is for the proles

Sent from my ASUS_Z00A using XDA Labs

 

[osm0sis]

Thanks, excellent info! So. maybe find all the runtime-permissions.xml files, make backup(s), delete them, wait around for it/them to reappear, restore the backup(s) and force reboot would do the trick. I'll work on that.

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!

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.

 

[mikeoswego]

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!

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.

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.

 

[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?
?

 

[rignfool]

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?
?

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...

 

[hinxnz]

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...

I think you mean zImage is the kernel and they're part of ramdisk which is basically half of your boot.img
@str8str if system is not modified by custom kernel then you only need to flash the boot.img from your ROM.zip

 

[LarappsOfDongle]

@osm0sis

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:

 

[rignfool]

I think you mean zImage is the kernel and they're part of ramdisk which is basically half of your boot.img
@str8str if system is not modified by custom kernel then you only need to flash the boot.img from your ROM.zip

^^^^

What he said...

 

[osm0sis]

@osm0sis

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:

No please remove your attachment, I've explained a few times why I'm waiting for the stable release (1.25.1).

 

[LarappsOfDongle]

No please remove your attachment, I've explained a few times why I'm waiting for the stable release (1.25.1).

Removed :good:

 

[str8str]

I think you mean zImage is the kernel and they're part of ramdisk which is basically half of your boot.img
@str8str if system is not modified by custom kernel then you only need to flash the boot.img from your ROM.zip

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

 

[hinxnz]

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

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.

 

[mikeoswego]

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!

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.

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!)

 

[KaMyKaSii]

@osm0sis 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

 

[_that]

@osm0sis 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

This should really be a TWRP native feature.

 

[pkelly517]

This should really be a TWRP native feature.

It is.
TWRP->Wipe->Advanced Wipe

Sent from my Pixel C using Tapatalk

 

[KaMyKaSii]

This should really be a TWRP native feature.

Hearing _that from you makes me full of hope for a future update

It is.
TWRP->Wipe->Advanced Wipe

It is not. Except for internal memory, or you wipe all /data or nothing