[Magisk] V0latyle:
Sorry, I think I must have given you confusing information.

As far as the bootloaderl lock goes, it doesn't matter whether /system gets modified or not, because using avbroot you end up signing both the system and boot images with the custom key that you then install as the Verified Boot key.

When it comes to device certification, a modified system image may affect this, but this has nothing to do with the bootloader lock - which won't help you with Play Integrity verdicts anyway since you're using a custom key.

Right, because again, a custom AVB key does not have the same effect as the OEM key. The bootloader reports its lock state as thus:

Bootloader locked on OEM key with genuine unmodified OEM firmware: verifiedbootstate=GREEN

Bootloader locked on custom key with self signed firmware: verifiedbootstate=YELLOW

Bootloader unlocked: verifiedbootstate=ORANGE

Since Play Integrity by default uses hardware attestation on Android 8.0+ devices, any other state than GREEN will result in failure of Play Integrity verdicts. So, in that sense, locking the bootloader will not help you pass Play Integrity - unless you go back to pure stock OEM firmware.

Personally I think avbroot is pretty pointless - the intent of the bootloader lock is to prevent modification of protect partitions including /boot and /system. Android was designed to accomodate this so that custom firmware could be loaded on devices and still enjoy the protections of Android Verified Boot.

First, external modification is prevented because the locked bootloader will reject fastboot commands such as flash and boot, so an attacker with physcal access to your device cannot flash modified images to compromise your device.

Second, the bootloader prebents internal modification because the protected partitions are verified using the AVB key, so if an exploit gains elevated privileges and manages to modify protected partitions, they will fail verification and the bootloader will present a warning: either Your device is corrupt, or No valid operating system found.

The problem with using avbroot with a rooted device is that you are locking the bootloader while retaining the explicit ability to use elevated permissions to modify those protected partitions. The avbroot documentation warns about this:

The problem is that while Magisk does not change /system - because since Android 6, root is Systemless - it -does- change the boot image, which is also protected by the bootloader.

However, there's a third element in play here - the OEM Lock. This is the property get_unlock_ability. This functions as a "safety" allowing the bootloader to be unlocked. avbroot documentation warns explicitly against turning this off:

So, since OEM unlock is left on, the bootloader can then be unlocked, and an attacker can compromise the device.

Locking the bootloader on a custom key really only has benefits from a device security perspective. It's meant to be used with custom OS like CalyxOS or GrapheneOS without root, with OEM unlocking disabled.

And this is all moot anyway because locking the bootloader on a custom key will not help you pass Play Integrity, nor will it fix device certification issues. We can absolutely help you with those problems here, but I think it's important to dispel the misconception that locking the bootloader on a custom AVB key is the solution.

No, that should be sufficient. As long as Play Integrity reports 2/3 pass, all you should need to do at that point is force stop Wallet, clear Wallet cache, and reboot.

If you're already passing there is no need to clear Play Services data. This is only necessary if Droidguard gets "stuck", causing you to fail when you should be passing.

Just means Wallet hasn't caught up yet. Since you are failing you need to fix it. Use a custom print if you aren't already.

Force stop Wallet, clear Wallet cache, reboot.