yashsingh1/xdaforums huggingface dataset:
[Magisk] eXtremeDevil:
Hi, today I update from Canary 26301 to 26302 and I got a boot crash. The boot logo lasted more than usual and then it was like SystemUI could not boot. I'm using Android 10 / MIUI 12 and a Xiaomi 10 Pro, with xiaomi.eu ROM. I have CustoMIUIzer LSPosed module, maybe it has some incompatibility. I don't have the time to try or get logs, but I thought of posting here in case anyone has the same issue, or is a solution may be available somehow.

Thanks in advance.
[Magisk] Nergal di Cuthah:
Disable the lsposed module and reboot, likely it or another module you use is causing this due to incompatibility
[Magisk] Nergal di Cuthah:
Also probably shouldn't be using canary if that's the case. The point of canary is to test and log.
[Magisk] eXtremeDevil:
I'm only using Canary because of compatibility with Shamiko module. I don't want to disable LSPosed, I prefer to stay on 26301.
[Magisk] pndwal:
Latest tech details/notes on changes (not officially released yet) from a ZygiskNext contributing Dev:

https://t.me/real5ec1cff/61

👀 PW
[Magisk] ozymandias2:
I have an Moto Edge Plus 2023 that I rooted with Magisk following these directions a while back: https://androidbiits.com/root-motorola-edge-plus-2023-xt2301-1-easily/

I would like to apply OTA updates, but every time I try, I am given an error that the "Package Verification Has Failed". I'm sure this is not device specific, but what is the appropriate way to get updated? I have an unlocked bootloader, so I can re-root if needed, I just don't want to have my data wiped if I can help it (IIRC, this happened when I unlocked the bootloader, and not when I rooted, but I could be wrong).

Anyone have any advice on how to get started?
[Magisk] zgfg:
Re-rooting does not wipe/format Data.

Only unlocking/relocking Bootloader does

Hence, you can flash (same way as in your guide), original/unpatched boot.img and reboot to the System with no Magisk

Apply OTA and re-root again. All modules, DenyList, SuperUser list and so will preserve since you wouldn't uninstall Magisk or wouldn't wipe Data (unless your OTA will do)

But after OTA, you must patch the new, upgraded boot.img

Btw, in Magisk Delta you would have an option in Magisk app Settings to reboot with Magisk disabled (hence no need to flash non-patched boot.img) but unfortunately not available in the official Magisk

However, instead of flashing not-patched/original boot.img, you can just temporarily reboot into to perform OTA:

fastboot boot boot.img

Since OTA will (most likely) overwrite boot.img, you will have to re-root anyway
[Magisk] Nergal di Cuthah:
Wipe happens with bootloader unlock/lock, not updates.

Automatic Updates can't happen if you root they will always fail.

You can uninstall magisk from within the magisk app, then take update. Or (and i don't know how on moto) flash the ota and reroot
[Magisk] ozymandias2:
perfect, thanks! I will try this tonight.
[Magisk] pndwal:
Is the complete error "Package verification failed - the update package being downloaded is not compatible with the current software version on the device"?

Likely the update engine is halting the update after pre-update partition digest checks/block verification (ie found incompatible) and causing the message for that reason, not OTA package corruption...

Before most stock ROM OTAs you'll need to restore stock images for any that you've changed/patched since these OTAs are delta types (ie incremental/differential updates that combine small OTA package data with existing partition data to create the partition updates, so the previous partitions must all be unmodified/bit perfect for expected data to be combined with differential data for changed blocks), not full OTA updates... Many custom ROMs use full OTAs containing complete image data... These don't require stock images to create updates...

If you're sure you only have Magisk patch, simply restoring stock /boot partition should be enough... You could fastboot flash or simply take in-App Uninstall Magisk, Restore Images option... If you have custom recovery installed you may need to restore /recovery partition unless it's installed in /boot partition on an A/B device... If you've patched /vbmeta or other partitions you'll need to restore these...

Take a look at John Wu's notes on restoring images to satisfy block verifications before OTAs:

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md

If you have A/B vdevice you may be able to use "install to inactivate partition" method to preserve root after taking Restore Images option if you're lucky.

Nb. This method is broken for many late devices (especially Pixel) as Google seems to have introduced post update/reboot partition digest checks in addition to the pre update ones, and Magisk injection then causes digest check failure resulting in updated slot being marked by system as corrupt...

Hope it helps... 🤠 PW
[Magisk] phone_etix:
Latest official Magisk (26400) and shamiko (0.7.4 188) with USNF Displax v2.4.0 mod 2.0 and HMA 3.2-410 not passing device integrity on TB Checker and Wallet fails to work when it did just yesterday. Not sure what changed there... I'm out and about and can't look into this until later, but a cursory search suggests Displax fork no longer works on a13 so I guess there was an update to the Play framework
[Magisk] Fishawy:
Yep, Displax's mod started failing today for a lot of us. Google made some changes.

Check the latest mod of Play Integrity Fix released today (v12). This fixed the SafetyNet and Wallet issues.
[Magisk] Nergal di Cuthah:
Play integrity fix 12 to replace usnf. It'll work again
[Magisk] phone_etix:
Caught up on the thread now that I've had a moment to sit down - and yep PIF v12 seems to have done the trick (for now!! Screw news updates, I need a live feed of the latest play integrity mod releases lol).

Didnt even need to wipe and reinstall Wallet thank goodness as it's a bit of a biatch to transfer the transport pass here when you reinstall Wallet. $deity bless chiteroman. Gonna send a couple bux over.
[Magisk] Fishawy:
My exact gripe with anything Wallet-related, the transport pass. Mine is so stupid it doesn't carry over, nor can it be transferred as it's not linked to the physical card, so I have to configure a new one every time I wipe (and potentially lose money in the process).

That's why I'm anxious when it comes to SafetyNet and the potential wiping of Google Wallet data. Thankfully didn't have to do that today.
[Magisk] TraderJack:
Can someone explain what Momo might be seeing/complaining about?

It states under the "Detail" section:

"ART parameters are abnormal."

And under "Suspicious Traces":

"Restriction on non-SDK interfaces is not working"

Bootloader unlocked

Prior to the upgrade from TJW 25 to 26 it was also telling me it still detected Magisk, but it does not say that anymore.

I'm on A11 (P3XL) with:

Magisk 26.4

Shamiko 0.7.4

Zygisk -LSposed - 1.9.2

PIF 12.3

HMA 3.2-4.10

What is also interesting (maybe) is that I only need to add Momo to the Deny List. Also adding it to HMA does not seem to do anything additionally.

I'm not necessarily concerned about clearing the messages, but would definitely like to understand their meaning (outside the bootloader, which is clear).
[Magisk] zgfg:
For Restrictions on Non SDK Interfaces see:

Restrictions on non-SDK interfaces | Platform | Android Developers

developer.android.com

It means that your ROM allows gray and black listed Android SDK API

ART Parameters are due to LSPosed service sh (but should have been gone by the newer LSPosed, strange that you have it), and Unlocked BL is what it is (Momo does not take Play Integrity tests)
[Magisk] J.Michael:
I remember someone saying specifically "do not add Momo to HMA". I don't know why, and I don't remember who. I think it was within the last few months.
[Magisk] TraderJack:
I found that post and really quickly glanced at it and couldn't really understand how it relates (in terms of why I'm getting message). I am on the Stock Pixel ROM. The only two reasons I might think I see this are:

1) It is A11

2) I'm using Kiri kernel (though I don't think this is a kernel issue).

So I'm not sure why my device would report a problem here. Is Magisk/Lsposed/Zygisk causing this or would I see it regardless based upon my ROM (even though it's stock)?
[Magisk] J.Michael:
Should be easy to disable all modules and turn off Zygisk long enough to rerun Momo.

More work to restore unpatched boot image to test Momo with no magisk installed. (To hear @zgfg tell it, that is also no big deal, and when you re-flash the Magisk patched boot image, you won't even need to reconfigure Magisk.)
[Magisk] zgfg:
Disable LSPosed, reboot and check for ART

For Restrictions, maybe due to your custom ROM. IMO, should not be with Google's official Pixel ROM (regardless of rooted or not)

I don't have Pixel, don't know more about them (but Restrictions issue is known for MIUI, at least custom Xiaomi.eu)
[Magisk] TraderJack:
Yeah I just tried disabling all modules and nothing changed with ART and SDK.

To be clear I don't have a custom ROM, I use the stock A11 ROM factory image. I do use a custom kernel though.

I plan to rebuild from scratch within a few weeks, so I'll see if I can figure out at what point the issue shows up. I'll report back for posterity.
[Magisk] zgfg:
As I commented, modules are not about Restrictions..As said, ithat detection is maybe caused by what your custom Kernel does
[Magisk] TraderJack:
Right, but you said disable LSposed, which is a module yes? I just figured that I would turn then all off while I was at it to test. Unless there was some other way you meant for me to disable it. I did not uninstall the app, but I don't think that would make a difference.

Edit. I see you were referring to one for each message from Momo..so I got ya.
[Magisk] zgfg:
If you read my posts again. you should see that I suggested you to disable LSPosed module to retest RESTRICTIONS detection, not ART (for ART I repeated two times that IMO is related to your custom kernel but you continued to insist that you use official ROM and 'only' a custom kernel)

So I'm sorry if you don't distinguish between those two detections and what I was answering in my previous posts

Anyway, forget, I have no time to read/respond, to repeat things and arguing what I wrote or not

Good luck with Momo
[Magisk] TraderJack:
Not sure why your being so aggressive. In my post above I edited it that I understand you even before you responded (you even included it in your quote). And a couple posts up you can see I quoted you saying custom ROM even when I told you I was on stock. So you're just as guilty here of not double checking things you are writing.

Also, not sure where you got that I was arguing about anything, just stating the facts of what I tried. Yeah I misunderstood one thing you posted and stated as much, but no need for your type of response.
[Magisk] wugga3:
I'll hazard a guess... Custom kernel is really a custom ROM ... Or at least a form of a custom ROM as opposed to completely stock ROM... Oh well I was getting the popcorn ready to see where this went cause it sounded like it had potential to be interesting...

Cheers
[Magisk] TraderJack:
I'll admit, I'm not on here every week - but unless definitions changed a custom kernel != custom ROM.

As stated multiple times I am on STOCK factory A11 Pixel ROM. I am however using this kernel:

[Kernel][10.06.2022][4.9.317][Android 12]Kirisakura_S 5.1.1 for Pixel 3/XL aka Bluecross

Kirisakura-Kernel for the Pixel 3 and Pixel 3 XL Hello everyone, To keep it short: Here is Kirisakura - Kernel for the Pixel 3 aka Blueline and the Pixel 3 XL aka Crosshatch, together Bluecross. I would appreciate if everybody that flashes the...

xdaforums.com

So maybe my nomenclature is wrong, but I think how I phrased it is entirely appropriate.

In any event, it seems like some of my messages are from an older version of Momo (as Momo is only available on TG it has sometimes been hard to update). I decided to reset my phone and I am doing some tests now. I will report back shortly, but it looks like the latest version of Momo does not report these issue.
[Magisk] wugga3:
You all know way more than me my friends. And my retention of knowledge is terribly short lol... Sorry I couldn't contribute more cause I'd love to.. thanks
[Magisk] TraderJack:
Ok, so I did more testing from a fresh install and this is what I see...

Momo 4.3.1/4.4.1 do seem to report the same through all of the below:

- Non rooted device (Pixel 3XL A11 Stock ROM)

Debugging mode is enabled

Bootloader unlocked

- After install of TJW Magisk 26.4:

Found executable file "su"

Found Magisk

Debugging mode is enabled

Bootloader unlocked

- After enabling Zygisk in Magisk (with or without Momo on Deny List):

Found executable file "su"

Found Magisk

Found zygisk

Debugging mode is enabled

Bootloader unlocked

- After installing LSposed Module:

ART parameters are abnormal.

Debugging mode is enabled

Bootloader unlocked

So it is the installation of LSposed that triggers the "ART parameters are abnormal" detail.

There are a couple of strange things about this:

1) Removing LSposed (deleting the module) doesn't get rid of this error. In fact, even flashing my original boot.img back to remove Magisk does not rid the system of this error. It would seem that LSposed makes some change to the system that cannot be reverted.

2) I reset my phone and tried this about 4-5 times. On one or two occasions I did not get the ART error after installing LSposed, but this was when using Momo 4.4.1 to check. When I downgraded to 4.3.1 it reported the error and after it did, even upgrading to 4.4.1 continued to report it. It is possible this is some sort of race condition/timing because this makes no sense to me - I'm just reporting what I observed.

So, in short it does seem that 4.3.1/4.4.1 Momo reports the same for me. However I did figure out that the following traces is reported differently:

Debugging mode is enabled

This is because USB debugging is on. In 4.3.1 I was bypassing this with HuskyDG's hide_userdebug module. His module basically set the following:

resetprop -n init.svc.adbd stopped

This module is discontinued not and upgraded by his sensitive_props module. However the new module fails (for me) to bypass this message even on Momo 4.3.1. I had to manually write a script with the above setting and place it in

/data/adb/service.d/

This worked to bypass the error on Momo 4.3.1, but NOT on 4.4.1.

AFAIK there is no way to bypass this on Momo 4.4.1 (with Zygisk)

Also, as far as the "Restriction on non-SDK interfaces is not working" trace... that has not showed itself again since re-flashing my device so I will have to keep an eye on that to see if it reoccurs as I continue to set the device up.

So, this doesn't solve much, but it does beg the question as to what LSposed is doing to trigger the ART warning on my device and why removal of LSposed doesn't seem to revert it.

Hope these data points help someone else.
[Magisk] J.Michael:
So instead of saying some Momo detections are caused by custom ROM, maybe we should be saying "are caused by running non-stock ROM". If you change any part of the ROM, it is not stock. In particular, if you change the kernel, it is not stock.

Maybe when you change the kernel, the kernel is no longer "signed", and *that* is what it is complaining about.

As for why something is caused by LSposed, but doesn't go away when you uninstall LSposed: maybe LSposed creates a directory, or at least a file, that isn't deleted when LSposed is uninstalled. Maybe if you look at the "install script" it will become obvious.
[Magisk] TraderJack:
I've already established that none of the issues I am seeing are due to the custom kernel. Whether or not they appear happens even with the stock kernel. I don't think it is necessary (or true) to claim that changing a kernel makes the ROM "not stock", a kernel and a ROM are two different components. It is obvious if someone is using a custom kernel that the entire phone is not stock (and I never claimed it was). But, again this argument is moot since the Momo errors have nothing to do with the kernel (i.e. happen with or without it).

As far as the the LSposed issue. Well it would seem clear to me that LSposed is modifying something that it is not reverting. How else can you explain the error only existing after LSPosed is installed and not being removed once LSPosed is removed, especially if nothing else is being touched on the system? :)

However if it is doing that, it seems to be a fairly major issue and expecting the user community to parse through the source code for that doesn't seem feasible. I think the general expectation has been that when you enable a Magisk module it is operating on a protected space. If you install a module, and it causes problems, you remove it and no harm, no foul. In this case it appears that the installation of LSposed is doing a destructive change (as far as Momo is concerned) and that removing it does not revert that change.

In this particular instance, I doubt the ART issue is a major problem. I fully understand that we should not be so concerned about a totally clean Momo report - that it probably won't happen. So, I am not as worried that Momo reports it, but that LSposed performs a destructive change that cannot be reverted short of reset of device and that Momo doesn't disclose its source (so that we are unable to know what the change is), and LSposed developers claim that this is impossible. Well technically they claimed it was impossible, and then they claimed if they were doing it then the fault was with the ROM. I don't understand how that can be.

If installing LSPosed on your device, just to try it (not even installing a module for it) can make a destructive change that cannot be reverted, I think it is in the interest of the user community to understand this.
[Magisk] TraderJack:
Ok, I'm going to put one more post on this and then let it rest, because the issue is so bizarre I can't really come up with any justifiable solution to it.

While Momo's ART error clearly is related to LSposed being installed (as in, that is a pre-requisite for it to occur), it does not always occur and it is possible to get rid of based solely on Momo. The best way to explain is for me to recreate my tests (which I did multiple times on a clean device build, STOCK ROM/KERNEL):

The process is this after installing Momo 4.4.1:

Momo does NOT report an ART error

After installing Lsposed and Shamiko, Momo still does NOT report the ART error

Do an extra reboot to confirm no error

Uninstall Momo and reboot

Reinstall Momo and ART error is reported!! (NB: that the behavior is the same even without a reboot)

Remove Lsposed, Shamiko and reboot

Momo still reports ART error!

Clear Momo cache and reboot again

Momo still reports ART error!

Remove Momo and reinstall

Momo does NOT report ART error

Reinstall LSposed (and Shamiko) and reboot

Momo does NOT report ART error

It makes absolutely no sense to me that removing Momo and immediately reinstalling it would generate the ART error that is permanent (even after reboots, clears of the cache, uninstalls, etc). As the process shows, the only way to remove the error is to remove both LSposed AND Momo, and then reinstall Momo without LSPosed.

I had these same issues when upgrading Momo versions, so I suspect that it is possible that if you do not have the ART error now, but upgrade Momo you could conceivably get the error. IF so, following the process above might allow the error to be removed.

Once again, I doubt the ART error is really a big deal in and of itself. I have had it and had no issue running any apps I needed. It does however cast some doubt on Momo's reliability in its reporting.

I'm happy to continue to discuss and for other's to give their thoughts. I need to move on with setting up my device for use so can't do such extensive testing. In any event, like always, I hope this helps someone else.
[Magisk] HippoMan:
I've been lurking here during this discussion, and the kernels which are the most relevant to me now are the kernels of corn that are popping and which I'll soon be enjoying as I continue to sit back and follow this ... uh ... well, I guess I'll be generous and call it a "conversation" about how and when a piece of software can be called "stock" or "custom" or a "ROM" or a "kernel" and whether a "kernel" can be said to be or not to be part of a "ROM", and whether what one person said is the same as or different from what was said a bit earlier, and whether or not the participants are missing each other's points ... etc., etc., etc., etc., etc. ...

Keep it going, guys. This is quite entertaining.
[Magisk] TraderJack:
That's one word for it. Most of it is just a distraction away from the salient points of the discussion which, as I think my testing shows, come down mostly to the fact that Momo is erratic.

I definitely don't claim to be an expert on this, but I can generally be patient and thorough with testing. The results shown above are quite strange and I'd love for someone to explain to me why they occur without having to resort to quibbling over terms that are mostly irrelevant to the topic (and have been since almost the beginning of the discussion).
[Magisk] J.Michael:
If you uninstall LSposed before uninstalling and reinstalling Momo, do you get the ART error? (Assuming you were not getting it.)

Is Shamiko needed to produce the ART error in Momo?
[Magisk] Crunkrock:
Hey,

I could be too stupid to search but I did search this thread for the word 'profile' and nothing came up, so 🤷‍♂️

Anyway, I had hiding root with Magisk working well, specifically Google Wallet and other banking apps were working just fine.

My general setup is:

Magisk app hidden

Deny list properly configured and enforced

Universal SafetyNet Fix and MagiskHide Props Config modules installed

Until at some point Google Wallet was complaining about root again. The only potential issue I could come up with was that in the meantime I had created a secondary profile for work, and I was wondering if Google Wallet could be picking up on the root from there?

So on the primary account I went to set Magisk > Settings > Multiuser Mode > User-independent, and on the secondary I installed the Magisk app. That secondary Magisk app doesn't seem to be fully working, lots of things are greyed out, like it's not fully installed?

So I kinda suspect the issue there but not sure where to go from here. Any help is appreciated!
[Magisk] J.Michael:
If you had Magisk manager app installed, and then installed another Magisk manager app in a way that it was not replacing the first, then you have created the dreaded multiple manager app scenario.

I understand that you expected this "profile" mechanism to keep the apps separate and completely unaware of each other, but that is in the Android universe. Magisk exists in a bigger universe, and I would not expect the "profile" or "workspace" mechanics to come close to addressing the problem.

When you decided to try installing Magisk manager app in a "profile", did you uninstall the original manager app? If not, try that.