yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] osm0sis:
gappsintegrator.log would be a start, and if there's any way to grab the stdout and stderr from the script when it's running in "EXKM script manager" that would most definitely help. Are you using my zip and zipalign binaries? Isn't the 6P officially on Nougat? Why Marshmallow?

There's still lots of room for improvement on it since there are near-infinite configurations and devices on which it hasn't been tested: more apps might need to go into the workaround lists.. perhaps more safety checks or app-specific workarounds need to be added.. perhaps the fallback integration method should be removed in favor of forcing people to use zip and zipalign; just a few possibilities off the top of my head.

Hopefully the script is a bit more readable now with v10, so people can submit updates/fixes on GitHub. I think this concept could go a long way - it's pretty fleshed out for a badass hack - but it's a hack nonetheless and most likely impossible for me to iron out all the issues for all devices by myself with only my Nexus 7 (Google Stock Marshmallow) and Galaxy Nexus (CyanogenMod 13) to test on, where it's running perfectly I might add!
[Android Software/Hacking General [Developers Only]] Maxr1998:
I enabled the script once again, and now got into a harsh bootloop. Restoring a /system nandroid and wiping dalvik didn't help. Logcat said that it crashed because it couldn't connect to VoiceInteractionService (Google app, maybe?), and it seems it's because of some permission errors. There were a lot of others errors/crashes, so I can't definitely say.

I looked through the logs, and there seemed to be no errors. I could try to capture the output later, but I have to go to school now (glad I have another phone!). Will also post logcat then. I believe don't have zip and zipalign, if they're not part of your busybox. I actually could even flash Android O, but I stayed on M because I need Xposed.

I will investigate further and keep you updated.
[Android Software/Hacking General [Developers Only]] osm0sis:
So you still haven't posted your /sdcard/gapps-integrator.log, but if you aren't sure then I'm quite sure it'll have some warnings about your system lacking zip and zipalign, so it'll use the fallback method instead.

You'll need to restore data as well as system to get a working device again if/when things go wrong. Glad you've got a backup device. :o:)

Definitely use zip and zipalign on your next test - they're available here: https://basketbuild.com/devs/osm0sis/binaries

Thanks for looking into it. It could be that while the fallback method works on custom ROMs it doesn't on stock, or at least not anymore, so I should probably remove the fallback method on at least Marshmallow+, since it's adding a hack to a bigger hack and so isn't really worth supporting when adding a couple binaries ensures correct APK handling and also saves you space.

Edit: Those are arm binaries, but they're static so they should also work on arm64 devices. Maybe test to ensure the binaries execute first before trying the script again. :fingers-crossed:
[Android Software/Hacking General [Developers Only]] Maxr1998:
Just extracted my gapps-integrator.log. Also, here's the part of the logcat showing the crash.

I'm not actually sure, my data backup is already a few more days old than I'd like to have it, can't I somehow fix that permissions error? Is there any script granting all permissions to my Gapps in package manager? Also, can I still zipalign now? Since all Gapps are integrated now, a new run of the integrator script won't do anything at all, right?
[Android Software/Hacking General [Developers Only]] osm0sis:
Correct, unfortunately they were all "integrated". And I'm guessing the issue is with Google Play services since the error talks about voice integration.

Flash the last stock Marshmallow system.img, wipe Dalvik cache, and delete /data/system/users/0/runtime-permissions.xml then reboot - best bet for Android trying to sort it out on its own.
[Android Software/Hacking General [Developers Only]] Maxr1998:
Tried the two latter items, didn't work. I am really wondering now whether I should just backup, wipe and start clean on Android O Preview..

Or I first try to update Play Services, I just can't get the pm install command to do anything (it just freezes).

EDIT: I got it to boot after deleting Google App package data from the packages.xml, but still lots of apps crashed after boot and also a lot of my data went down the river, e.g. 15 GB of music in the Google Play Music app. Since I had to set up the device in a new state anyway, I completeley wiped it and I am now restoring my backup on Android O Preview..
[Android Software/Hacking General [Developers Only]] czecx:
This is my log from Nexus 5X running Nougat 7.1.1.

Maybe it will help you.
[Android Software/Hacking General [Developers Only]] osm0sis:
You probably had similar results to Maxr? Nougat support is still untested, so I'd say you definitely shouldn't try it without zip and zipalign installed.
[Android Software/Hacking General [Developers Only]] II_DiE_4:
Dunno if its just on my phone but flashing busybox with newest Magisk, breaks wget.

It throws wget: bad address . Removing the busybox from Magisk's manager fix it.
[Android Software/Hacking General [Developers Only]] osm0sis:
Output of `which wget` when broken and working please.
[Android Software/Hacking General [Developers Only]] II_DiE_4:
Working: /system/bin/wget (didnt flash any busybox and didnt activate the internal magisk one either)

Not working: /system/bin/wget (Just flashed yours busybox and didnt activate the internal one)

Working also: /system/bin/wget (Removed yours and activated internal Magisk one). But using "busybox wget" still shows bad address

which busybox: /system/xbin and shows 1.26.2.YDS

device: shamu

And tried on different AOSP and LOS based Roms (since i had the time :) )
[Android Software/Hacking General [Developers Only]] osm0sis:
Well, sounds like wget is just plain broken (at least on Android) in v1.26.2 if it doesn't work with mine or YDS. I can reproduce it with a SuperSU systemless installation as well. I'll take a look to see if there are any patches upstream, and/or see if I can track it back to when it worked.

Doesn't explain why which still shows bin with mine installed since even with Magisk it should get pushed to xbin. Can you give me `ls /magisk/busybox-ndk/system` and `which busybox` with mine installed (and Magisk internal disabled)?
[Android Software/Hacking General [Developers Only]] II_DiE_4:
Yes sure.

Its bin and /system/bin/busybox. It also say it when you install it thats in /magisk/busybox-ndk/system/bin

Using magisk 12 BTW. And I think that's where the problem is. Something changed in this version . using your busybox with older magisk works. Just tested
[Android Software/Hacking General [Developers Only]] osm0sis:
There's a newer template in v12 for one. Hmm, I'll look into it. Thanks. For the broader issue, I can so far verify that YDS is also effected and it's the dns lookup/resolver in general, e.g. ping reports the same error.
[Android Software/Hacking General [Developers Only]] marcdw:
Searched the thread but didn't see anything about this.

Been running crDroid for some time. Latest version, 2.5, now includes Magisk. By habit I flashed BusyBox after the ROM. Output shows it installing to /magisk/busybox/system/bin.

The deal is, ROM will not boot when flashing busybox. It sticks at the LG logo. Won't go any further. Reproduced this several times over a couple of nights. I've also flashed busybox after the fact (ROM up and running) but still get stuck at the logo.

Not sure what the deal is. I figure the only log I can get is from the recovery.

LG G3 D851

MultiROM-TWRP 3.0.2

crDroidAndroid v2.5

Magisk 11.6 (also 12.0)

BusyBox 1.26.2-ALL

LG G3 D851, PAC-MAN LP ROM, MultiROM, Tapatalk 4.9.5
[Android Software/Hacking General [Developers Only]] osm0sis:
Yup, noted this myself the other day from the wget error report. The SuperSU su.img cleanup/target logic that switches someone from a /su/bin (bad) installation to a /su/xbin (good) installation is conflicting with a Magisk install.

I'm attempting to come up with a code fix for wget/ping/nslookup, etc. dns resolution (a long-standing Android busybox issue), then I'll release a new build with the installer fix.

One oddity in your report is that it shouldn't be in /magisk/busybox, my Magisk installs are to /magisk/busybox-ndk. Not sure what's up there, but I'd make sure to only use my official, latest zips in the future.

Workaround for now would be to mount /magisk in recovery (I think someone has a MagiskMount zip out already based on my SUmount zip, so I won't reinvent the wheel there), then `mv -f

/magisk/busybox-ndk/system/bin /magisk/busybox-ndk/system/xbin`
[Android Software/Hacking General [Developers Only]] nicesoni_ash:
Hi,

I am using an s3 (4.2) cm based rom. I am interested in ur sd card adbsync backup script. I tried to download the required files from your provided links, but first one has a dead link for that zip and second has too many files and confusing. Can you please provide a zip of urs somewhere with all needed exes included. Thanks.

_____________

Sent from my GT-I9300 powered by 7000mAh ZeroLemon Battery

Fueled by Temasek Rom & Kernel
[Android Software/Hacking General [Developers Only]] osm0sis:
Yeah I'm thinking about getting around to that now that adbsync has changed threads. Just gotta find the time to test the new version to see if I can safely remove some of the workarounds I had in place/clean it up. :good:
[Android Software/Hacking General [Developers Only]] osm0sis:
That's an interesting idea. I've never bothered signing my zips since custom recoveries don't require it. I know PhilZ has managed to get his temp recovery zip to run on stock Samsung GS2 recovery so, while efrant is likely correct, I'll look into it a bit more and see if I can figure something out before I release the new version next week. :)
[Android Software/Hacking General [Developers Only]] osm0sis:
Must be some flaw in the Samsung recovery that PhilZ is exploiting, since I even tried piggybacking mine into an OTA zip and it just fails "whole file verification" after passing the initial file verification.

My guess is Samsung's GS2 one doesn't check whole-file or something. Anyway, as efrant thought, no-can-do for stock recovery, so I'm uploading my unsigned combined Nexus BootUnlocker to the OP now and will edit the OP as I go. :good:

It detects what device you're using and if it's a GN, N4 or N10 proceeds to determine the lockstate and un/lock it. It displays the device name and bootloader version to help prevent user-errors and also does this if it's an unsupported device. If it detects a N7 2012 (also unsupported) it displays a link to my N7 BootUnlocker Script zip thread which is the only similar option available for that device.

Download stats for the previous separate versions:

GN - 94

N4 - 54

N10 - 34
[Android Software/Hacking General [Developers Only]] chrone:
thanks for trying it out, dude! :) downloading right now. hehe :good:
[Android Software/Hacking General [Developers Only]] russellvone:
Edit: wrong thread.
[Android Software/Hacking General [Developers Only]] WastedJoker:
The cwm perm fix - it mentions /data/media sdcard path - does this differ from HTC one sdcard path?
[Android Software/Hacking General [Developers Only]] osm0sis:
I don't own a HTC One; you tell me? ;)
[Android Software/Hacking General [Developers Only]] WastedJoker:
Well I just don't know what controls the path - it seems like it changes!
[Android Software/Hacking General [Developers Only]] osm0sis:
Reboot to recovery and adb shell while connected, at the root prompt type: ls -al /

See where your /sdcard symlink points. You might have to make sure it's the internal sd if you also have an external. :)
[Android Software/Hacking General [Developers Only]] demlv:
osm0sis,

Just wanted to say thanks for working with Renate to get the ADBsync sdcard backup script to a final, stable state. I used the prior version with differing levels of success for about 6 months. I finally decided to ditch Pulse because of the problems it caused with backups, but I only used that app a couple of times a year anyway. The newest version of the backup script is working perfectly for me.
[Android Software/Hacking General [Developers Only]] osm0sis:
Glad to help. :)

Pulse seems to have resolved that problem as well, but their old files on the sdcard in Android/data/ which were causing the problems need to be cleared out manually. :good:
[Android Software/Hacking General [Developers Only]] angusc:
Hi osm0sis,

THnx for this work and script. If i already have a complete copy of my SDCard on my PC can i just copy that in to the "sdcard" folder within your package folder "ADBSync sdcard backup" folder, then run the BAT file to have the script update the folder? Or do i have to start a completely new sync using the BAT file for best results?
[Android Software/Hacking General [Developers Only]] osm0sis:
It may or may not work since adbsync's all based on file date and time modified. Either way it'll update or overwrite and you'll be good for the next time. Worth a shot! :)
[Android Software/Hacking General [Developers Only]] angusc:
Thanx, but i moved the original over to my External HDD and now started a fresh back up using your script. But it stops in the android folder, I assume due to too long? file name........I'm now trying to add the android directory to the ini file and if i understand what you said, then that folder should then be backed up as a .zip file with all content inside
[Android Software/Hacking General [Developers Only]] osm0sis:
Bingo! :)
[Android Software/Hacking General [Developers Only]] GoldElocks:
Has anybody used any of Osmosis' tweaks/scripts on their N7 2013? I have used his on both my gnex and N7 grouper with excellent results but was wondering if anybody has seen performance enhancements on deb/flo. I haven't been able to see any concrete differences using the tweaks but have not done any extensive testing nor do I have quantitative data to back that up.

Sent from my N7 Flo
[Android Software/Hacking General [Developers Only]] osm0sis:
Why don't you try and let us know? The Franco's Dev Team init.d scripts were designed with all devices in mind. [MENTION=4828198]malaroth[/MENTION], the founding member of the tuning collective has even been using them on his new SGS4 with great results.
[Android Software/Hacking General [Developers Only]] marcdw:
[MENTION=4544860]osm0sis[/MENTION], I was following that wget issue and testing also. Had already written down my BusyBox installation path after seeing mention of where it should go.

Using your latest zips, from February. Straight from the OP. Haven't seen anything newer.

I'll redownload for good measure and test again where things install to.

LG G3 D851, Nimax Slim Fit v7.0 ROM, microG (NoGapps), MultiROM, Tapatalk 4.9.5
[Android Software/Hacking General [Developers Only]] osm0sis:
Definitely says magisk=/busybox-ndk/system, so no way it could go anywhere else.. :confused:
[Android Software/Hacking General [Developers Only]] marcdw:
I know, right? That's why it seemed so strange when the other path was reported.

After work I'll flash the same ROM and BusyBox, see if it reports the same, then manually check to see where it really went.

LG G3 D851, Nimax Slim Fit v7.0 ROM, microG (NoGapps), MultiROM, Tapatalk 4.9.5
[Android Software/Hacking General [Developers Only]] marcdw:
You know when one forgets a piece of info? Well, I forgot to mention my environment which may play a part.

MultiROM. About half a dozen ROMs, all secondaries on ext4 partition on SD card. No ROMs in internal memory.

Anyhind, flashed crDroid 2.5 again followed by BusyBox. Installs to /magisk/busybox/system/bin.

Then checked via Aroma and TWRP's file manager. No such path exists under the ROM's location. I did find an empty /magisk directory in my internal memory.

I'll have to peruse a recovery log to see what was going on.

Hmm, I have to verify if ROM's mount point was used or not. It should've but I didn't think of that 'til I saw "Mounting..." in the screenshot just now.

LG G3 D851, OctOS Nougat ROM, MultiROM, Tapatalk 4.9.5
[Android Software/Hacking General [Developers Only]] osm0sis:
You couldn't see in /magisk at the time because it wasn't​ mounted.

There were unofficial zips where someone took mine and modified them for Magisk support, and I think in my first attempt (the broken one without module.prop) at support it may have been in just /magisk/busybox as well, but there is zero way possible for that with the curren version, so again I have to suggest you delete every version of the zip you've got lying around and get the one from the OP again.

It contains the following:

test "$mnt" == "/magisk" && magisk=/busybox-ndk/system;
test -d $mnt$magisk/xbin && target=$mnt$magisk/xbin || target=$mnt$magisk/bin;

ui_print "Using path: $target";
mkdir -p $target;
cp -f busybox-$arch $target/busybox;
chown 0:0 "$target/busybox";
chmod 755 "$target/busybox";
if [ "$magisk" ]; then
cp -f module.prop /magisk/busybox-ndk/;
touch /magisk/busybox-ndk/auto_mount;
fi;

And there's really no other way that can go but to put it in /magisk/busybox-ndk/ - it's there or it wouldn't install to /magisk at all due to the $magisk.. :confused:

hammerhead:/ $ magisk=/busybox-ndk/system
hammerhead:/ $ echo $magisk
/busybox-ndk/system
hammerhead:/ $
[Android Software/Hacking General [Developers Only]] marcdw:
Roger that. Will check it out after work. Thanks.

LG G3 D851, PAC-MAN LP ROM, MultiROM, Tapatalk 4.9.5
[Android Software/Hacking General [Developers Only]] osm0sis:
Thanks for the log! Finally nails what the (dumb ;)) issue was.

In my busybox zip I've got this note written:

"# try to find the actual fd (pipe with parent updater likely started as 'update-binary 3 fd zipfile')"

While in flashafterupdate I've got the command as:

"$tmpzipdir/$metadir/update-binary" "$tmpzipdir/$metadir/updater-script" 1 "$i";

So.. as the error suggests, wrong order. Move the 1 to between the update-binary and updater-script path arguments and hopefully all those zips I just arbitrarily thought didn't work will work now! :silly: :cyclops:

Maybe change it to a 3? Not sure exactly what that'll do, maybe in your TWRP expertise you can say what number should be there to accommodate all script and regular zips.

I've got a few days off starting tomorrow, so I'll get a properly fixed version uploaded soon. :good:

Edit: hmm, wait that doesn't make sense either.. the fd should be 2nd.. does it depend on the update-binary?
[Android Software/Hacking General [Developers Only]] _that:
bootable/recovery/install.cpp contains a comment about the updater command line:

// When executing the update binary contained in the package, the
// arguments passed are:
//
// - the version number for this interface
//
// - an fd to which the program can write in order to update the
// progress bar. The program can write single-line commands:
//
----8<---- (snip)
//
// - the name of the package zip file.
//
// - an optional argument "retry" if this update is a retry of a failed
// update attempt.

The first argument, RECOVERY_API_VERSION, has been 3 for a long time now.
[Android Software/Hacking General [Developers Only]] osm0sis:
Ah, so we don't need the updater-script path at all.. it should be "3 1 <zipfile>" where 1 is just a dummy fd, might be better to use an fd that couldn't be real like "3 dummy <zipfile>". Guess it always just gets updater-script from its pwd?
[Android Software/Hacking General [Developers Only]] _that:
1 is not a dummy fd, it's stdout. And "dummy" isn't an integer so it'll get converted to 0, which is stdin - most likely not what you want.

The script path is hardcoded to "META-INF/com/google/android/updater-script" inside the zip.
[Android Software/Hacking General [Developers Only]] osm0sis:
Thanks, as always, for the insight! :)

I'll have a fixed version up in the next couple days incorporating all that.
[Android Software/Hacking General [Developers Only]] marcdw:
Got around to testing again. Downloaded BusyBox from the OP again. Flashed crDroid 2.5 and busybox. Correct path is used (/magisk/busybox-ndk/...) but the main issue is still there.

ROM will not boot. Sticks at LG logo. Since it was time to update Tesla I tried on that, too. Also stuck.

This time around, after flashing BB, I get those failed to get trampoline messages. Used to get those back when flashing after systemless SU.

MultiROM, gotta love it. ?

LG G3 D851, LiquidSmooth v4.1 ROM, MultiROM, Tapatalk 4.9.5
[Android Software/Hacking General [Developers Only]] osm0sis:
Okay good. But yes, still installing to /system/bin within Magisk as I mentioned, I'll have this fixed in my next version.

In the meantime you can mount Magisk in recovery (search for Magisk Mount zip a user created) and move the busybox-ndk bin to xbin then it'll work as intended. :good:
[Android Software/Hacking General [Developers Only]] osm0sis:
On the wget/ping/nslookup front, oh man.. quite the rabbit hole. Lots of conflicting information about glibc bugs and limitations​ that shouldn't really pertain to bionic/NDK at all, especially where uClibc busybox builds are also affected and uClibc should have none of those issues. Main thing is they all end up with the "bad address" error, so it's hard to get down to anything useful in a search, but I think I have.

Basically, despite no NDK build warnings (infamous on glibc) it seems static binaries compile but can't use getaddrinfo(), which for a dynamic binary will route access to /dev/socket/dnsproxyd to handle all requests, so it all goes to hell for dns resolution in most busybox net utilities from there (libbb/xconnect.c#L285).

nslookup on the other hand has dietlibc's resolver via one of the patches I maintain to allow the custom command-line nameserver, so you'd think it'd be more hopeful, but this has a different problem. It cleverly attempts to use __system_property_get to grab the dns from the net.dns1, net.dns2, etc. properties, but that also fails; either because the previously cited "static binary stuffs", or because Google removed __system_property_get from the API, maybe - I've read some conflicting information there.. :eek:

For now I'm going to hardcode Google's nameserver 8.8.8.8 into dietlibc's resolver to use only when it comes up empty from the property search, and then hack xconnect's functions to use dietlibc's resolver instead of bionic's as well. That should get things working, until I can investigate some more monster hacks that could at least restore dietlibc's resolver to getting the system dns property correctly as intended.. the larger getaddrinfo() vs. static compile sounds like too broad of an NDK/Android issue for me to want to delve into any further.

I'll be the only static busybox in town that can handle hostnames without external files, so... :cowboy: :p