FORUMS
Remove All Ads from XDA

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

13,672 posts
Thanks Meter: 30,198
 
By osm0sis, Recognized Developer / Recognized Contributor on 18th April 2013, 12:37 AM
Post Reply Email Thread
14th July 2019, 10:07 PM |#2431  
ogisha's Avatar
Senior Member
Thanks Meter: 291
 
More
Quote:
Originally Posted by jcmm11

Try this. Get a copy of flashfire from the play store. Development stopped at the beginning of 2018 or so, but it should work for your purposes.

One catch - there's a time bomb built into the app so in order to get it to work you'll have to set the system date on your tablet to sometime before March 2018.

If you decide you want to keep the app just for the old device you can buy the pro version, which will disable the time bomb.

I tried FlashFire before and it did not work.
Thank you.

---------- Post added at 10:07 PM ---------- Previous post was at 10:02 PM ----------

Quote:
Originally Posted by osm0sis

Busybox is also just a binary after all, so you could download the x86 build from my Magisk module GitHub repo to your device then use your SuperSU su root shell to

`cp -f /sdcard/Download/busybox-x86 /system/xbin/busybox`

then

`chmod 755 /system/xbin/busybox`

and

`busybox --install -s /system/xbin`

Boom, done.

Nice catch.
I guess the last command will create all necessary links, but will it remove the old ones and remove any leftovers?
Thank you very much.
 
 
14th July 2019, 10:39 PM |#2432  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,198
 
Donate to Me
More
Quote:
Originally Posted by ogisha

I tried FlashFire before and it did not work.
Thank you.

---------- Post added at 10:07 PM ---------- Previous post was at 10:02 PM ----------


Nice catch.
I guess the last command will create all necessary links, but will it remove the old ones and remove any leftovers?
Thank you very much.

No, but /system/xbin shouldn't have much in it before busybox, and my builds only really gain applets, never lose them, so it should be fine.
The Following User Says Thank You to osm0sis For This Useful Post: [ View ]
15th July 2019, 08:55 PM |#2433  
ogisha's Avatar
Senior Member
Thanks Meter: 291
 
More
Quote:
Originally Posted by osm0sis

No, but /system/xbin shouldn't have much in it before busybox, and my builds only really gain applets, never lose them, so it should be fine.

I tried and it worked.

Thank you.
The Following User Says Thank You to ogisha For This Useful Post: [ View ] Gift ogisha Ad-Free
19th July 2019, 08:55 PM |#2434  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,198
 
Donate to Me
More
Here's a bit of fun.

For any wondering how those kernel manager apps were flashing AK2/3 zips and other flashable zips here's the script version of the implementation I wrote that we were using in FKM.

Note this can't just be run as-is because you need to switch into the `su -mm` root shell at the top, so it's more for use copy/pasting into `adb shell`.

auto_flash_ak3.sh:
Code:
#!/system/bin/sh
# app unzips busybox and update-binary from target zip ($Z) to app dir ($F)
# app may also either unzip a premade empty ext4 .img or generate a new one

## setup for testing:
su -mm;

F=/data/data/com.franco.kernel/files;
Z=/sdcard/franco.kernel_updater/fk-r*.zip; Z="$(echo $Z | cut -d\  -f1)";

unzip -p $Z tools*/busybox > $F/busybox;
unzip -p $Z META-INF/com/google/android/update-binary > $F/update-binary;
/system/bin/make_ext4fs -b 4096 -l 400M $F/ak3-tmp.img || /system/bin/mke2fs -b 4096 -t ext4 $F/ak3-tmp.img 400M || exit 1;
##

chmod 755 $F/busybox;
$F/busybox chmod 755 $F/update-binary;
$F/busybox chown root:root $F/busybox $F/ak3-tmp.img $F/update-binary;

# work around Android passing the app what is actually a non-absolute path
F=$($F/busybox readlink -f $F);

# AK3 allows the zip to be flashed from anywhere so avoids any need to remount /
if $F/busybox grep -q AnyKernel3 $F/update-binary; then
  # work around more restrictive upstream SELinux policies for Magisk <19306
  magiskpolicy --live "allow kernel app_data_file file write";
  TMP=$F/tmp;
else
  # work around SAR Magisk 19303-19305 rootfs context bug
  magiskpolicy --live "allow rootfs labeledfs filesystem associate";
  TMP=/tmp;
  $F/busybox mount -o rw,remount -t auto /;
fi;

$F/busybox umount $TMP 2>/dev/null;
$F/busybox rm -rf $TMP $F/bbin 2>/dev/null;
$F/busybox mkdir -p $TMP $F/bbin;
$F/busybox --install -s $F/bbin;

$F/busybox mount -t ext4 -o rw,noatime $F/ak3-tmp.img $TMP;
if [ $? != 0 ]; then
  i=0;
  while [ $i -lt 16 ]; do
    loop=/dev/block/loop$i;
    $F/busybox mknod $loop b 7 $i;
    $F/busybox losetup $loop $F/ak3-tmp.img;
    $F/busybox losetup $loop | $F/busybox grep -q ak3-tmp.img && break;
    i=$((i + 1));
  done;
  $F/busybox mount -t ext4 -o loop,noatime $loop $TMP;
fi;
$F/busybox mount | $F/busybox grep -q " $TMP " || exit 1;

# update-binary <RECOVERY_API_VERSION> <OUTFD> <ZIPFILE>
PATH="$F/bbin:$PATH" home=$TMP/anykernel $F/busybox ash $F/update-binary 3 1 "$Z";
RC=$?;

$F/busybox umount $TMP;
test "$loop" && $F/busybox losetup -d $loop;
$F/busybox rm -rf $TMP $F/bbin;
$F/busybox mount -o ro,remount -t auto /;
$F/busybox rm -f $F/ak3-tmp.img $F/update-binary $F/busybox;

return $RC;
Apps will be switching to a new implementation using the new not-yet-officially-released switchroot binary from @topjohnwu, but for the demonstration of AK3's ability to be flashed from anywhere this is still handy and I wanted to show people how it could/should be done.

There's also a debate of whether the loop mounted ext4 .img is better than using a tmpfs mount instead (e.g. `mount -t tmpfs -o size=400M,noatime tmpfs $TMP`), but that depends on whether your devices might have a bottleneck on free space on /data to hold the ext4 .img vs. free RAM to hold the tmpfs. I went with ext4 .img since that should help on low-end devices (provided they have the space). switchroot uses tmpfs; AIK-mobile will continue to use ext4 .img since people need to be able to pick up where they left off.

Big thanks to @MSF Jarvis for working with me for awhile to figure out that the Pixel 2 XL on Android Q now fills up a lot of its /dev/block/loop* nodes (with only the info of "8192" ), and also goes up to loop15 instead of the loop7 previous devices/OS versions have, leading to the above while loop to fix it which will also make it into the next AIK-mobile.
The Following 20 Users Say Thank You to osm0sis For This Useful Post: [ View ]
22nd July 2019, 01:36 AM |#2435  
Junior Member
Thanks Meter: 9
 
More
Quote:
Originally Posted by osm0sis

Busybox Installer:

This is probably a dumb question, I am out of my depth, but re: the busybox magisk module. Is there anything I can do to get Tasker to recognize it? When I use BusyBox from the play store, I can use Tasker's run shell action kill -9 `pgrep <packagename>` to kill foreground apps with no problem but with the Magisk module it's resulting in an error. Tried a BusyBox checker and it says it's working fine, so I assume I'm missing something?
22nd July 2019, 02:16 AM |#2436  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,198
 
Donate to Me
More
Quote:
Originally Posted by D412

This is probably a dumb question, I am out of my depth, but re: the busybox magisk module. Is there anything I can do to get Tasker to recognize it? When I use BusyBox from the play store, I can use Tasker's run shell action kill -9 `pgrep <packagename>` to kill foreground apps with no problem but with the Magisk module it's resulting in an error. Tried a BusyBox checker and it says it's working fine, so I assume I'm missing something?

busybox is available in all shells (root and user) because of how Magisk works, so that's gotta be some issue with how Tasker invokes the shell, maybe with a weird broken $PATH or something.
22nd July 2019, 02:20 AM |#2437  
Recognized Contributor
Thanks Meter: 3,167
 
More
Quote:
Originally Posted by D412

This is probably a dumb question, I am out of my depth, but re: the busybox magisk module. Is there anything I can do to get Tasker to recognize it? When I use BusyBox from the play store, I can use Tasker's run shell action kill -9 `pgrep <packagename>` to kill foreground apps with no problem but with the Magisk module it's resulting in an error. Tried a BusyBox checker and it says it's working fine, so I assume I'm missing something?

First of all both kill and pgrep are found natively in Android - you don't need busybox to get those commands. And since the way you appear to be using them here is pretty basic there shouldn't be any functional difference between the busybox and toybox (native Android) versions.

Next - what, exactly, is the error. And what, exactly are the full contents of the Tasker task.

And, just to confirm things, what's the output of the following commands:
type pgrep
type kill
ls -l $(which pgrep)
ls -l $(which kill)
The Following User Says Thank You to jcmm11 For This Useful Post: [ View ] Gift jcmm11 Ad-Free
22nd July 2019, 02:41 AM |#2438  
Junior Member
Thanks Meter: 9
 
More
Quote:
Originally Posted by osm0sis

busybox is available in all shells (root and user) because of how Magisk works, so that's gotta be some issue with how Tasker invokes the shell, maybe with a weird broken $PATH or something.

Thanks for the reply

Quote:
Originally Posted by jcmm11

First of all both kill and pgrep are found natively in Android - you don't need busybox to get those commands. And since the way you appear to be using them here is pretty basic there shouldn't be any functional difference between the busybox and toybox (native Android) versions.

Next - what, exactly, is the error. And what, exactly are the full contents of the Tasker task.

And, just to confirm things, what's the output of the following commands:
type pgrep
type kill
ls -l $(which pgrep)
ls -l $(which kill)

The problem is that with BusyBox from the playstore installed, the identical task runs fine. Executes as expected, kills the app. Uninstall it, I get an error. Installed Magisk Module, I get an error. The task is super simple, attached to a nav gesture

1) App Info (returns %app_package variable)
2) Run shell kill -9 `pgrep %app_package`

I also tried it with an actual package name instead of a variable, but same problem, here is the result with the returned variable

The error is:
Code:
21.24.27/Variables doreplresult: |kill -9 `pgrep %app_package`| -> |kill -9 `pgrep net.dinglisch.android.taskerm`|
21.24.27/Variables doreplresult: |kill -9 `pgrep %app_package`| -> |kill -9 `pgrep net.dinglisch.android.taskerm`|
21.24.27/E Run Shell:  -> 
21.24.27/E Run Shell:  -> 
21.24.27/E Run Shell:  -> 
21.24.27/Shell runBackground kill -9 `pgrep net.dinglisch.android.taskerm` root: true timeout: -1
21.24.27/Shell start process-thread ID 437
21.24.27/E add wait type Shell1 time 2147483647
21.24.27/E add wait type Shell1 done
21.24.27/E add wait task
21.24.28/E Error: 1
type pgrep --- pgrep is a tracked alias for /system/bin/pgrep
type kill --- kill is a shell builtin
ls -l $(which pgrep) --- lrwxrwxrwx 1 root root 6 2019-07-21 20:43 /system/bin/pgrep -> toybox
ls -l $(which kill) --- lrwxrwxrwx 1 root root 6 2019-07-21 20:43 /system/bin/kill -> toybox

Appreciate any help
23rd July 2019, 07:34 AM |#2439  
ianmacd's Avatar
Senior Member
Flag Amsterdam
Thanks Meter: 2,970
 
More
Quote:
Originally Posted by osm0sis

Here's a bit of fun.

A tangential question about coding style: Why do you terminate every line with a superfluous semi-colon? This is unimportant, but I haven't seen this particular idiosyncrasy before, so I'm curious.
The Following User Says Thank You to ianmacd For This Useful Post: [ View ] Gift ianmacd Ad-Free
23rd July 2019, 08:19 AM |#2440  
Senior Member
Flag Sydney
Thanks Meter: 1,824
 
More
Quote:
Originally Posted by ianmacd

A tangential question about coding style: Why do you terminate every line with a superfluous semi-colon? This is unimportant, but I haven't seen this particular idiosyncrasy before, so I'm curious.

for me, I find that If you get everything else in the line correct, then it is superfluous, however, if you do make a typo (which happens often) it highlights the mistake quicker as opposed to continuing to the net line waiting for more input. Also, adding the semi-colon to the end enables multiple lines on the same line. frivolous example
Code:
cd ~/android; ls -l; cd ~/;
The Following 2 Users Say Thank You to DiamondJohn For This Useful Post: [ View ] Gift DiamondJohn Ad-Free
23rd July 2019, 08:29 AM |#2441  
guest4711's Avatar
Senior Member
Flag Београд (Beograd/Belgrade/Griechisch Weißenburg/Alba Graeca; Alba Bulgarica)
Thanks Meter: 2,170
 
More
Quote:
Originally Posted by ianmacd

A tangential question about coding style: Why do you terminate every line with a superfluous semi-colon? This is unimportant, but I haven't seen this particular idiosyncrasy before, so I'm curious.

It's a hommage to Pascal (and Modula2) where a statement is terminated by a semicolon.
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