SafetyNet is now is strong prohibitor to anyone wanting to develop or test so-called custom ROMs, system images, or otherwise. As of March of 2020, SafetyNet now deploys a method tied directly to the actual hardware to detect bootloader unlock.

While it must be said certain applications probably only should be ran on a fully locked and certified device, quite a few application developers (ab)use the SafetyNet Attestation API even in quite unnecessary use cases (eg, a photo editor or messaging app. Those are not very high security use cases that would in fact run on the most broken of environments).

Until recently Magisk (an extremely popular root solution, bypassing any apps that did not implement additional checks themselves was possible via running them in a sandboxed, clean environment free of any root access or modifications, thereby reducing the risk of the app not functioning as intended or leaking potentially sensitive information. Magisk is a systemless root, many nothing in the actual system is at any point touched and therefore a sandbox runs the app in a safe environment to conduct all but the most sensitive of duties.

Now that has changed. Every root detecting happy app, even when they don't need such stringent checking, will detect the unlocked status of the device and refuse to run at full capacity if at all. Even if the device is perfectly untouched and I just unlocked the bootloader, or my OEM ships bootloaders unlocked by default, I can no longer enjoy the ecosystem to it's fullest without dealing with inconsistent and potentially insecure OEM implementations, affecting the functionality of my apps (see: dontkillmyapp.com, a website dedicated to how OEMs break functionality of background apps), and usually ship out security patches significantly slower. While APEX's through GMS attempt to resolve this, so-called custom ROMs generally almost always ship out security updates monthly, and in some cases harden the system or kernel moreso than OEMs (see: https://security.samsungmobile.com/securityPost.smsb, item #2)

Generally speaking, developers do not change AOSP code in such a way that any APIs standardyly available change or don't work (and in fact the build system forbids it).

Every day my reasons to stick with the once open Android ecosystem is dwindling, and I'm wondering if i should buy an iPhone from Apple or from an android OEM because it's becoming hard to tell which is which. What was once a system where I could run what I'd like, much like one can do on a home PC, is no more (without reducing functionality). Even secure boot lets me have a surefire way to allow me to run my own software and still ensure security. Android has no such way and is more and more punishing anyone who wants to run their own things on their own device that they purchased with what we're assuming is their own money.

But back to the point of the issue: stringent device attestation even where not necessary.

My recommendation is to either:
1) Allow apps to use non-stringent testing by default, eg lower security apps do not need hardware backed attestation can go with the old fashioned method and thereby on anything short of a horribly broken device/ROM will continue to function correctly and require apps to specify strict checking;
2) Immediately rollback these changes as they will negatively effect as many users as they benefit;
3) Allow a user to manually bypass these checks, the same way we currently allow google signin on an uncertified device. This forces the user to assume all responsibility for any malfunctions and another chance to make sure a malicious actor cannot abuse this;
4) Create guidelines for apps to use the SafetyNet Attestation API as many apps may not truly need a higher level of assurance they are running on a certified device;
5) Find a way to certify on-device that it would pass CTS/VTS/etc

These would create a balance between ensuring security of your app where necessary and allowing the vibrant developer community to continue to thrive as it once did.