FORUMS
Remove All Ads from XDA

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

13,664 posts
Thanks Meter: 30,145
 
By osm0sis, Recognized Developer / Recognized Contributor on 18th April 2013, 12:37 AM
Post Reply Email Thread
23rd August 2017, 02:52 AM |#1431  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,145
 
Donate to Me
More
Quote:
Originally Posted by vibrantliker

I don't see it to uninstall it. Does it show up in app drawer?

.. It's not an app. Rename the zip to Busybox.Uninstaller-signed.zip and flash it again in recovery.

Read the OP blurbs and follow the links therein to be fully aware of what you're flashing and all the included features.
 
 
24th August 2017, 12:57 PM |#1432  
Senior Member
Flag Colchester
Thanks Meter: 1,642
 
Donate to Me
More
@osm0sis Btw, busybox has been updated to 1.27.2
24th August 2017, 01:28 PM |#1433  
Jenanga's Avatar
Senior Member
Flag Cologne
Thanks Meter: 155
 
More
Quote:
Originally Posted by DEVILOPS 007

@osm0sis Btw, busybox has been updated to 1.27.2

Btw osm0sis knows that

Sent from my hero2lte using XDA Labs
24th August 2017, 07:56 PM |#1434  
Senior Member
Thanks Meter: 110
 
More
Deleted
24th August 2017, 08:08 PM |#1435  
vibrantliker's Avatar
Senior Member
Flag Boston
Thanks Meter: 529
 
More
Quote:
Originally Posted by user2k10

And now he's been reminded 🙂

Sent from my SM-N910F using XDA Labs

Is there a .zip or apk for it?
25th August 2017, 04:04 AM |#1436  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,145
 
Donate to Me
More
I've got a Chrome extension that checks daily for changes on the busybox and nano websites and shows me the diff, so yeah, no reminders necessary.

I just worked 4 12-hour days in a row, so we'll see how far I get this weekend on things. No point in doing 1.27.2 without proper BINDSBIN SuperSU support.
The Following 24 Users Say Thank You to osm0sis For This Useful Post: [ View ]
25th August 2017, 08:41 PM |#1437  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,145
 
Donate to Me
More
Here's a fun little trick to get a fully functional Pixel Launcher on a stock Nexus 5X with BINDSBIN SuperSU.

1) Sideload the latest available extracted Pixel Launcher from here: https://www.apkmirror.com/apk/google...ixel-launcher/ - press Home and set it to default.
2) Copy the .apk and oat directory from /data/app/com.google.android.apps.nexuslauncher-1 to /sbin/supersu/app/GoogleHome (make this directory first) renaming things from base.* (.apk and .odex) to GoogleHome.*, then fix the ownership and permissions to match system: `chown -R root:root /sbin/supersu/app; chmod -R 755 /sbin/supersu/app; chmod 644 /sbin/supersu/app/GoogleHome/GoogleHome.apk /sbin/supersu/app/GoogleHome/oat/arm64/GoogleHome.odex`
3) Create a su.d script to do the magic: `echo 'mount -o bind /sbin/supersu/app/GoogleHome /system/app/GoogleHome;' > /sbin/supersu/su.d/000pixellauncher; chmod 755 /sbin/supersu/su.d/000pixellauncher`

Reboot and voila. Pixel Launcher replaces Google Now Launcher in the live system parition via bind mount.

Of course Magisk could handle this pretty easily as well, but I'm not going to start distributing Google app APKs in Magisk modules.


Also, to follow up on the idea of having the renamed busybox zip functionality work to uninstall when flashed in Magisk Manager, this isn't possible because Manager renames the zip to only install.zip when it copies it to a temp directory for processing. Just use Magisk Manager itself to uninstall, being the more obvious choice of method.
The Following 9 Users Say Thank You to osm0sis For This Useful Post: [ View ]
26th August 2017, 02:24 AM |#1438  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,145
 
Donate to Me
More
Adding Magisk Manager, BINDSBIN SuperSU and Pixel /system/system support to my zips took a few additions to my usual setup.

For one, the updater-script is required to have the first 7 characters be #MAGISK or Manager will reject it:
Code:
#MAGISK# Dummy file; update-binary is a shell script.
Then in update-binary there's magisk_merge.img creation and the BOOTMODE output redirection to contend with:
Code:
test -e /data/adb/magisk && adb=adb;
ps | grep zygote | grep -v grep >/dev/null && BOOTMODE=true || BOOTMODE=false;
$BOOTMODE || ps -A 2>/dev/null | grep zygote | grep -v grep >/dev/null && BOOTMODE=true;
if $BOOTMODE; then
  OUTFD=/proc/self/fd/0;
  dev=/dev;
  devtmp=/dev/tmp;
  if [ ! -f /data/$adb/magisk_merge.img ]; then
    (/system/bin/make_ext4fs -b 4096 -l 64M /data/$adb/magisk_merge.img || /system/bin/mke2fs -b 4096 -t ext4 /data/$adb/magisk_merge.img 64M) >/dev/null;
  fi;
fi;
Code:
ui_print() { $BOOTMODE && echo "$1" || echo -e "ui_print $1\nui_print" >> $OUTFD; }
After that it's all pretty similar except you need to have magisk.img, magisk_merge.img and, for BINDSBIN SuperSU, supersu_is_here added for detection, specify a module name for Magisk (must match what's in the also-required module.prop), and then some generalization is possible using variables:
Code:
modname=module-name;

# Magisk clean flash support
if [ -e /data/$adb/magisk -a ! -e /data/$adb/magisk.img ]; then
  /system/bin/make_ext4fs -b 4096 -l 64M /data/$adb/magisk.img || /system/bin/mke2fs -b 4096 -t ext4 /data/$adb/magisk.img 64M;
fi;

suimg=$(ls /data/$adb/magisk_merge.img || ls /data/su.img || ls /cache/su.img || ls /data/$adb/magisk.img || ls /cache/magisk.img) 2>/dev/null;
mnt=$devtmp/$(basename $suimg .img);
if [ "$suimg" ]; then
  umount $mnt;
  test ! -e $mnt && mkdir -p $mnt;
  mount -t ext4 -o rw,noatime $suimg $mnt;
  for i in 0 1 2 3 4 5 6 7; do
    test "$(mount | grep " $mnt ")" && break;
    loop=/dev/block/loop$i;
    if [ ! -f "$loop" -o ! -b "$loop" ]; then
      mknod $loop b 7 $i;
    fi;
    losetup $loop $suimg && mount -t ext4 -o loop,noatime $loop $mnt;
  done;
  case $mnt in
    */magisk*) magisk=/$modname/system;;
  esac;
  test -d $mnt$magisk/xbin -o "$magisk" && target=$mnt$magisk/xbin || target=$mnt/bin;
else
  # SuperSU BINDSBIN support
  mnt=$(dirname `find /data -name supersu_is_here | head -n1`);
  if [ -e "$mnt" ]; then
    target=$mnt/xbin;
  else
    mount -o rw,remount /system;
    mount /system;
    test -f /system/system/build.prop && root=/system;
    target=$root/system/xbin;
  fi;
fi;
Extraction has to take place in /dev when booted for Magisk Manager so we generalize there as well:
Code:
mkdir -p $dev/tmp/$modname;
cd $dev/tmp/$modname;
unzip -o "$ZIPFILE";
And a bit more final setup for the Magisk module:
Code:
if [ "$magisk" ]; then
  cp -f module.prop "$mnt/$modname/";
  touch "$mnt/$modname/auto_mount";
  chcon -hR 'u:object_r:system_file:s0' "$mnt/$modname";
  if $BOOTMODE && [ "$suimg" == "/data/$adb/magisk_merge.img" ]; then
    mkdir -p "/magisk/$modname";
    touch "/magisk/$modname/update";
    cp -f module.prop "/magisk/$modname/";
  fi;
fi;
Cleanup is nice too:
Code:
umount $mnt;
test "$loop" && losetup -d $loop;

cd /;
rm -rf /tmp/$modname /dev/tmp;
Naturally if you use File-Based Encryption your recovery will need to be able to support FBE to have detection of paths like /data/adb/su/supersu_is_here work, but for recoveries that don't (*cough* Nexus 5X) SuperSU does handily include a merge mode for anything under /data/supersu_install but since there's no way to detect whether a SuperSU installation is otherwise present without digging into the boot.img I didn't bother trying to leverage this feature to directly work around broken FBE in recovery.

The best way to work around it in those situations is to flash SuperSU first; it'll create /data/supersu_install/supersu_is_here and then all the above script will work. FlashFire also works as an alternative to recovery altogether.
The Following 16 Users Say Thank You to osm0sis For This Useful Post: [ View ]
26th August 2017, 03:16 AM |#1439  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,145
 
Donate to Me
More
Ugh, triple post. Worth it?

I work on these projects in my limited time off, so if you like the progress I'm making, or enjoy anything else I've done on xda, please do hit the donate link from my profile. Thanks for your support!

UPDATE-adb.Installer.v1.0.36-signed.zip;
UPDATE-Adreno.Systemless.Installer-signed.zip;
UPDATE-nano.Terminal.Editor.v2.8.6-signed.zip;
UPDATE-Nexus.Media.Installer-signed.zip:

- add BINDSBIN SuperSU support

UPDATE-Busybox.Installer.v1.27.2-ALL-signed.zip:
- update to latest busybox stable official source
- add BINDSBIN SuperSU support

See the related commits here: https://github.com/osm0sis/android-busybox-ndk

Edit: To the 6 users who downloaded the Nexus Media and Adreno zips so far, I've reuploaded them; I had a broken test version of the su.d script in there instead of the final, working one. All is well now.
The Following 42 Users Say Thank You to osm0sis For This Useful Post: [ View ]
26th August 2017, 01:16 PM |#1440  
Senior Member
Thanks Meter: 1,007
 
Donate to Me
More
Quote:
Originally Posted by osm0sis

Code:
ps | grep zygote | grep -v grep >/dev/null && BOOTMODE=true || BOOTMODE=false;
$BOOTMODE || ps -A 2>/dev/null | grep zygote | grep -v grep >/dev/null && BOOTMODE=true;

Hi,
I know shell scripts a bit but I find difficult to understand what these lines do.

Can you please explain them?
26th August 2017, 03:12 PM |#1441  
Recognized Contributor
Thanks Meter: 3,141
 
More
Quote:
Originally Posted by ale5000

Hi,
I know shell scripts a bit but I find difficult to understand what these lines do.

Can you please explain them?

Ultimately what they do is look to see if the zygote process is running. If yes set BOOTMODE to true. If no set it to false.

ps is the 'process status' command. It returns a list of running processes with information about them, for purposes here only the name is relevant.

Sidenote: the busybox version of ps (which is what runs within TWRP) is more full featured than the toybox version. One example - toybox version won't accept the '-A' parameter. I think the only thing it does accept is a pid.

For more information on ps check Google. Try 'ps command Linux' or 'ps man page'. For now just know it returns a list of processes, by default ones which belong to the user running the command.

So the output from ps is passed to grep which checks the output for 'zygote' (which is the "master" process when you boot), this output is then passed to fgrep again to remove any lines with 'grep' in them.

Next the return code from the grep is checked. If return code is 0 (&& test) set BOOTMODE to true. If not 0 (|| test) set to false.

The second line starts by testing the value of BOOTMODE. If it's false it runs the 'ps -A' command, tests further for zygote, sets to true if found.

As noted above this second line won't really do anything because 'ps -A' will throw an error in a booted system since toybox will reject it. But what I described is the intent.

Hope this helps. If you have a specific question about part of this then ask.
The Following 5 Users Say Thank You to jcmm11 For This Useful Post: [ View ] Gift jcmm11 Ad-Free
Post Reply Subscribe to Thread

Tags
automation, batch, flashable zip, script, tool

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes