yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
Several possible factors:

Device launched w/ A8.1, so Legacy Ramdisk boot-type, fine for traditional zip installer from recovery installation...

This changed when you updated to A10 however; device is now converted to modern 2SI 'SAR'... Zip installation from recovery is NOT recommended for SAR/2SI devices...

Zip/recovery installation patches only boot.img and won't patch extra partitions done by App patch/flash method for SAR/2SI on a per device basis...

Also magiskinit injection method for 2SI as well as magiskinit sepolicy injection mechanism are refactored in 25.0+. These changes may not play well with zip-installed Magisk, or it may be the fact that AVB flag stripping is no longer done since it is no longer needed. (- It was done only to support old patch fstab magiskinit method, now replaced by patch the original init.)...

BTW, did you see or select "Patch vbmeta in boot image" option in App, or use fastboot patch the vbmeta partition command: fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img? PW
[Magisk] pndwal:
Chris4711 said @Displax's new(ish) USNF_mod works... Play Protect issue was hadn't cleared Play Store (or Play Services) data... has 'Certified' showing now after waiting 'a while' however... PW
[Magisk] KaKi87:
I'm sorry I didn't realize that.

I've been so used to generic steps (boot recovery -> flash recovery -> reboot recovery -> wipe all -> flash firmware -> flash ROM -> flash GApps -> flash dm-verity disabler -> boot system -> boot recovery -> flash Magisk -> flash *Posed) that I didn't bother checking if steps have changed.

Therefore, neither.

Honestly I think it's too bad that we can't just flash ZIPs anymore, that was so easy.

Anyway, thank you for your response.
[Magisk] pndwal:
For everyone, a bit of

Insight into Custom Recovery installation method Depreciation:​

Yup... Method was fine for old legacy ramdisk booting devices, but does rely on custom recovery compatibility, and John ended up fielding the TWRP issues; plenty from official TWRP builds not to mention broken unofficial ones... Then Dees Troy needed to attend to real life and Team Win simply couldn't adapt to Google's ever changing system architecture, boot methods etc fast enough and lagged way behind Magisk. (See John's Android Booting Shenanigans)...

This precipitated the move to an installation solution that doesn't rely on other custom development, but wasn't the only practical consideration; 'Manager' and now 'App' patching w/ fastboot (etc) flashing meant owners of

https://xdaforums.com/t/magisk-the-magic-mask-for-android.3473445/post-72587983

and users can also preserve stock recovery to apply OTAs etc... Thus 'Magisk Manual Injection' was born...

Next, support was added for patching Samsung AP firmware which recovery/zip installation couldn't achieve. Then with Project Treble came efforts to

https://xdaforums.com/t/magisk-the-magic-mask-for-android.3473445/post-74961572

... and then 'recovery mode' support for many A-only legacy SAR devices (A9 / 2018) w/ ramdisk only in recovery partition (again not supported by recovery/zip installation)... And it is now noted:

...

Note that even (old) legacy ramdisk boot-type devices are to be considered 'modern' once running Android 10+ as they are automatically converted to current 2SI "SAR" boot-type!...

👀 PW
[Magisk] KaKi87:
What about the OrangeFox recovery that apparently has "Inbuilt patches, like Magisk" ? Does that one takes the issues you reported in consideration ?
[Magisk] zgfg:
I've seen that in OF and SHRP on Xiaomi but never dared to test - for me patch and flash is just fine (I started to use back in 2017, on Huawei where TWRP did not support decryptiin of Internal storage for Oreo) and got accustomed to

Btw, then I keep the version(s) of previously patched boot images, and if something goes wrong (there were cases with Canary releases), I simply flash back the boot img, patched by previous Magisk version

Or, instead of flashing, I can first test with one-time booting:

fastboot boot <patched-boot.ing>

Also, to disable/uninstall modules from TWRP, you can manually add files names disable or uninstall into their folders (hence I don't use that features in OF or SHRP)
[Magisk] pndwal:
For John / Magisk, the issue is that any custom recovery introduces potential incompatibilities and issues beyond his control... The answer for him is simple: Officially support stock methods (ie methods not requiring 3rd party custom mods) of Magisk Installation...

Orange-Fox methods may well work fine; they're just not officially supported.

Nb. Magisk is also clearly focussing more and more on supporting and improving compatibility for stock implementations (ROMS) incl. stock recoveries. I wouldn't be surprised if official Treble GSI ROMs from Google already have higher priority than traditional custom ROMs...

😝 PW
[Magisk] Titan077:
I have a little bit of a weird question. Me and others are currently working on rooting an obscure android and we have an interesting situation. Basically, this phone is extremely locked down and app installation is completely blocked. We have managed to patch the boot.img of the phone but since app installation is blocked we cannot install magisk manager and therefore there's no way to grant superuser access to shell. If we do get su access we can move on to allowing app installation. So is there any way to patch the boot.img in a way which allow automatic su access to shell without requesting access from magisk manager. Can we somehow modify the magisk app to patch the image in such a way? Or something to modify in the boot image once it's already patched?
[Magisk] J.Michael:
You can patch the boot.img but you can't install an app?

When you patch the boot.img, does that include the ability to patch what ends up as "/data/app" (or some such name)?

I think if you put an apk in the right directory, it is "installed". I think that's what the zip files flashed through TWRP do to preload apps.
[Magisk] Titan077:
Yes, we can patch the boot.img with other methods (either from a different device or this amazing GitHub project).

We can patch whatever magisk patches by default. I don't think that inclueds /data/app.
[Magisk] KaKi87:
Oh, too bad, I never use stock ROMs.
[Magisk] pndwal:
Who's suddenly getting Basic Integrity failures?... (I'm not! 😝)...

But seriously, I'd like to know what's going on... PW
[Magisk] zgfg:
Maybe people with GApps?

Maybe with MHCP?

It's strange - I could understand that GPay might start failing but how/why even Basic Integrity in the API checker (installed from Playstore) may start failing?!
[Magisk] pndwal:
Seems clear GPay/Wallet is failing since it uses PI and requires deviceIntegrity, (may still be using old S/N CTS Profile match for some parts also as hadn't migrated to PI exclusively last time I checked...) so it's just symptomatic of Basic Integrity failing for some...

Question (for me) is Why now?... PW
[Magisk] J.Michael:
I'm still not clear on what you are doing when you "patch". If you are modifying the initram (ramdisk?), you could add a directory full of apks. If you can patch the init script, or just know where to add another script, can't you find a place after "/data" has been mounted and copy apks to whatever the magic spot is?

If you can patch the "/system" filesystem, you can copy apks to "/system/app-priv", but not all apps can run as system apps, and you probably don't want to grant special privileges to most apps.

Are you able to use adb? Can you use the package manager? I've seen references to some command like "adb install" or "adb shell pm install".
[Magisk] Titan077:
I see I'm not being so clear, so let me try to explain. This phone is locked down to all app installation so "adb install" and "adb shell pm install" do not work. There is an error thrown when attempting that. There is a system property in the build. prop that has to be set to "true"in order to allow app installation but since you need root access to set it, it cannot be set. We have managed to pull the boot.img from an ota update zip and we've patched it with the magisk app (on a similar device) and booted from it successfully but when trying to run "su" in adb shell it throws "permission denied" because magisk mananger is not installed on the device to grant su permission to shell. You seem to have an idea of how to patch the image in a way where I can add a script to copy apks to /data but I have no idea how to do that- I am just patching the image from the magisk app the standard way. If you can explain to me how to do what you are suggesting it would be a huge help. Its exactly what I'm looking for and once magisk manager is installed I can grant su permission to shell and proceed with setting the correct property to allow app installation on the device. Thanks in advance for any ideas which might help!
[Magisk] zgfg:
Supposedly, you have no TWRP (custom recovery) to replace build prop

I was also thinking about (again, TWRP would be needed), pulling of Magisk.db and editing its policies tab, but after analyzing my magisk database I do not see root flag for the shell there (only for UIDs of the 'real' apps). I don't see where is the root grant for shell stored
[Magisk] Titan077:
Correct. As of now we have no TWRP for this device. I am working on producing one but I do not have a lot of experience with that.
[Magisk] zzz2002:
Why can't you tell us which device you are working on?
[Magisk] Titan077:
It would be my pleasure. Alcatel TCL Flip 2 (T408DL). It's just an obscure device and a flip phone. I didn't think that many people would have come across it.
[Magisk] zgfg:
There is ROM Kitchen prog for PC (Win, Linux).

You could cook in Magisk.apk
[Magisk] Titan077:
Thanks! Can you send me the link? Right now I don't have the system.img only the boot.img but its good to know about such a program
[Magisk] zgfg:
Simply google for Android Kitchen and/or ROM Kitchen.

I've never used (cannot give you the best link) but seems there is also a thread on XDA

Eg

https://xdaforums.com/t/tool-windows-kitchen-crb-v3-0-0-beta15.3947779/
[Magisk] Kalanyr:
I find myself in an awkward situation (I use magisk alpha), where somethings gone wrong with the update process, the stub app can't apply the update and reinstalls full magisk, but the stub has kept su authority, is there a command I can use (possibly during boot) to revert su authority to the full app so I can fix things ?

(I'm on Android 12 on a One Plus 8 at the moment so I can't use TWRP to fully uninstall magisk as I'd normally do in this situation.)

ETA - Just did some further checking, and since I had already authorized it, I actually have su access from the adb shell by using su, if that helps.
[Magisk] pndwal:
This often occurs... Many always take 'Restore the Magisk app' before taking any Magisk App update for this reason... or simply be prepared to uninstall stub when when things foul up... If you can't find stub, look in device settings, apps for 'Settings' (default name) or for whatever custom name you gave it...

Issue is dual apps competing for Magisk/root... Once stub is removed full app should behave properly again, and you can take 'Hide the Magisk app' again if desired...

Nb. Magisk configuration, modules etc are safe and won't be affected even if you uninstall both apps as these are stored in /data/adb rather than in app data... PW
[Magisk] Kalanyr:
Thanks. That was surprisingly simple. Just removing the stub app and closing and restarting the full app worked perfectly.
[Magisk] HippoMan:
I'm posting the following query here because this group is dedicated to the use of Magisk, and because there are numerous people here who are using Magisk on a number of different devices. If it turns out that this message is deemed to be off topic for this forum, I apologize in advance, and I would appreciate a pointer as to where I could post this where it will be accepted as being on topic. Thank you in advance.

My phone seems to finally be dying, and it looks like I will need to get a new device. I would like recommendations for devices upon which one or more people have had good luck in being able to utilize the following features in a reliable manner. This can help me decide which device to purchase next. Here are the Magisk-related features which are essential to me:

(1) A recent version of Android.

(2) Reliably able to obtain and maintain root via Magisk (and possibly other related utilities) with a minimum of confusion, and a minimum of convoluted and possibly contradictory instructions, and with a low probability (ideally, a zero probablity) of boot loops and other issues as long as instructions are properly and carefully followed.

(3) The bare minimum number of apps (ideally with this number being zero) that are crippled because of their ability to detect root or modding. In other words, effective root/modding hiding. In worst case, I can live without banking apps, but I want to make sure that few, if any other apps would be crippled due to their ability to detect root and modding.

(4) The abilty to run LSPosed or some other Xposed version.

Of course, there are many devices, and I'm sure that some devices are easier to root and mod under the above stipulations than other devices. I'm looking for recommendations from people who have already had reliable success in obtaining what I'm asking for, and for them to let me know which devices they are using and with which Android versions, which versions of Magisk, and which other related utilities, so I can then make an informed decision as to which device I will purchase.

Feel free to respond to me via private message, if you deem this discussion to be uninteresting to the majority of people here.

Thank you in advance for any suggestions.

PS: I'm looking for all four of the stipulations that I mentioned above. Not some lesser fraction.
[Magisk] ipdev:
Short answer..

Pixel.

[Personally..

3aXL (bonito) or 5a (barbet).

Both have official Lineage support.]

Better thread to ask your question.

**What phone should I buy next?** -- Not sure what device to buy? Ask here!

Cheers. :cowboy:

B.
[Magisk] HippoMan:
Thank you very much! And I especially appreciate your pointing me to that other thread.
[Magisk] TheShanMan:
I'm using the systemless debloater module to degoogle and debloat a device (and several other magisk modules to assist in that endeavor). I'd really like to be able to do a factory reset to clear the device of any data/artifacts from the debloated apps, but of course a factory reset wipes out magisk modules, so I'm in a catch 22.

Is there any way to do a factory reset and then restore the magisk modules prior to booting back up via twrp or adb while in recovery mode?

adb only seems to support the magisk command while android is running, but is the magisk binary accessible with an absolute path in recovery mode?

Or would it be as simple as making a zip of the /data/adb directory and installing it in twrp (since magisk isn't lost on factory reset, but the app would still need installing)?

Or is there some other way I could get myself out of that catch 22?
[Magisk] J.Michael:
I don't think you will accomplish anything useful by doing a factory reset.

"systemless" debloating is just hiding the apps, it isn't really freeing up any disk space. Why bother chasing whatever scraps of "/data" the apps leave behind?

What state do you expect to be in if you ever boot without Magisk? The apps will all be "back", but they won't find their data?
[Magisk] zgfg:
You can do some cleaning like this:

- Wipe (from TWRP or by root explorer like MiXPlorer)

/data/dalwik-cache

/data/system/package_cache

-In MiXPlorer, go to three dots, Tools and clean by App Remnants

-Install SD Maid:

[APP][1.6+] SD Maid - System cleaning tool

Description: Ive started working on a tool to clean up after apps (inspired by this thread). Nobody is perfect and android neither. Apps you have already deleted sometimes leave data behind. The system constantly creates logs, crash reports...

xdaforums.com

SD Maid 1 - System Cleaner - Apps on Google Play

A maid for your Android, to keep it clean & tidy.

play.google.com

And clean by CorpsFinder option
[Magisk] LedgendaryEpics:
Pixel either 4 or 5
[Magisk] HippoMan:
Thank you!!

I responded in private chat.
[Magisk] Allmarshall:
I have an important doubt that have caused me a little fear.

Currently I have installed on my Poco X3 the Magisk 25.2, but I am using version 12.5 of MIUI and Android 11. A short time I received notification that I can update the MIUI to stable version 13, which I believe I include android version 12.

If I upgrade miui to 13 and Android to 12, will I face some kind of problem?

Already making it clear that I have no pretensions to modify my system or anything like that, I just have root for the sake of some apps like Lucky Patcher, Game Guardian, wifi saved password apps, etc. Just basic use.
[Magisk] zgfg:
I have two Xiaomi phones, one with MIUI 12.5 / A11 (end of line, not upgradeable anymore) and another MIUI 13 / A12.

Regarding to Magisk/root, there is no substantial difference, I run V4A, Vanced, AdAway, systemless debloating, etc on both

However, there are differences between MIUI 12, 12.5 and 13 - but those differences are there, no matter if you root or not. Nevertheless, root can help you to overcome some restrictions introduced by new MIUI
[Magisk] Allmarshall:
I had read somewhere (I don't remember where) that there were some difficulties in magisk's relationship with the new MIUI/Android. That was my fear of me updating and ending up bricking up the system or something.

I really just make basic use of Root itself. AdAway, Vanced, GG, LP, wifi apps... I hardly do anything beyond that. At most some Root File Explorer.

So I can update without fear of errors ?
[Magisk] 73sydney:
I'm on a train, so squinting at a small screen, but are you saying you patched the boot images in the same session?
[Magisk] badabing2003:
I'm not sure what you mean by same session.

It you mean that i was patching in parallel two simultaneous runs, no not at all.
[Magisk] zgfg:
You see what I wrote about my use. On Xiaomi.eu forum (MIUI 13) you can read also several users running Magisk

Don't judge by some newbie who probably doesn't know how to do things

Be aware that real problem might be TWRP - generally TWRP does not support decryption on A12, hence those who 'never heard' that Magisk can be installed by patching and flashing boot img (instead of flashing zip through TWRP), might have difficulties. But patching and flashing is described in Magisk GitHub documentation (as recommended method!!), in tones of posts here, etc.

Besides, there is another thread (Magisk, Zygisk) here on XDA devoted to Magisk 24/25 with very good instruction on the first page

After all, there are alternative, non-official versions of TWRP or Orange Fox that might be found for a particular device - but that's out of scope for the Magisk thread (again, Magisk does not require TWRP, neither for installation of Magisk, not for the installation of modules)
[Magisk] Allmarshall:
Thank you very much! Reading this has already reassured me a lot. I did the update just now and I will continue with my normal use, as always, and see if there will appear any errors with time, although I am no longer too worried about it as before.
[Magisk] TaZeR369:
You could use the adb package manager to uninstall the apps for you instead of hiding them with the debloater.

Open up a adb shell and try the following command:

# adb shell pm uninstall --user 0 org.package.name.here

You can also list all packages currently installed with:

# adb shell pm list packages -f

Not exactly sure if that will survive a factory reset though, but its easy to do after and frees you up from using a magisk module for it. Maybe there is some way to ensure it sticks if you play around with the commands a bit.

ADB Package Manager commands list here
[Magisk] zgfg:
There is a substantial difference in systemless debloating vs debating by adb

In the second case you can still see that app is installed but not enabled for user 0 (default user):

- thus "pm uninstall --user 0..."

- and if you want to reinstall, you don't need to have APK file you just command "cmd package install-existing..." and system will actually just re-enable that existing app for user 0 and the app will work again without rebooting

Or consider the following:

Your ROM comes with preinsatalled system YouTube (recent version).

But you want to install Vanced root YT (or Music)

System does not allow you to install BCS it would be downgrading of the system YT app

You 'debloat' by adb, and you again try to install root Vanced YT - it will still fail because the system (recent/newer) version of the app is still installed, it's just 'hidden' for user 0

Only if you hard (not possible on the new read-only SAR devices) or systemlessly debloat (and reboot), then that system recent YT app will be no more initiated and you will be free to install Vanced root YT that is actually a patch of an older YT version

And there are more examples like that - I put YT BCS that's the case I need it for
[Magisk] TheShanMan:
Yeah didn't really want to go the magisk route, and initially debloated via adb, but when I got all done, I put in a sim card to test phone calling and it didn't work because, as research then revealed, any change to the system partition breaks VoLTE for some reason on this particular phone. VoLTE is required in the US now, at least for the AT&T network. So magisk to the rescue! I found through 2 or 3 existing modules, and 1 I wrote myself, I was able to do everything via magisk that I had previously done directly to the system partition. Phone calls work with this approach. :)

Thanks for the suggestion regardless!
[Magisk] fred_gaou:
Strange things.

I followed the magisk installation process.

adb shell ls -l /dev/block/by-name showed me I had vbmeta_a and vbmeta_b. Hence, after flashing the patched boot.img, I ran the command fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img and it returned the error fastboot: error: cannot load 'vbmeta_b.img': No such file or directory

I decided to ignore it and reboot. Everything seems to work fine. My system is rooted despite the vbmeta not set.
[Magisk] J.Michael:
Since you knew you had two vbmeta partitions, I would have thought you would try to disable verity et al. on only the one corresponding to your Magisk installation.

The error message makes it sound like "flash vbmeta something.img" means "flash vbmeta_a something_a.img" AND "flash vbmeta_b something_b.img". There's a 50% chance you actually set vbmeta_a. I'm surprised it didn't complain about not finding "vbmeta_a.img" -- did you have a file by that name?
[Magisk] shoey63:
Magisk disables vbmeta in the boot image itself these days. No need to run --disable-verity --disable-verification commands in fastboot anymore.
[Magisk] J.Michael:
You're going to have to check your copy of boot_patch.sh.

Have you manually confirmed the SHA1 hashes of these files?

Is there any chance that one time you had Magisk patch an already patched file?
[Magisk] Erfirya:
how do i fix this? does it have to do with me enabling the denylist
[Magisk] pndwal:
Yup; instructions don't say to do that... In fact Magisk is designed to keep AVB and it's flags intact in most cases where seperate vbmeta partition(s) exist now...

As indicated, fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img is only an option; it's for some limited use custom configurations, eg may be needed if running some custom kernels, especially older ones... It may also still be needed for a few stock kernels...

As a rule, don't enable Magisk options or use optional ADB commands unless you have a particular need / know what they do...

Further, Johns optional instructions assume a certain level of understanding; it seems fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img is meant as a generic example for those finding separate vbmeta partition(s)...

Use fastboot flash vbmeta_x --disable-verity --disable-verification vbmeta.img where x is set to required slot (per partitions found by adb shell ls -l /dev/block/by-name), and vbmeta.img assumes ROM image used is named accordingly... PW