➡ Google has replaced SafetyNet with Play Integrity, a new system that checks if a device is Google-certified. This change has caused concern among Google phone users, as it could potentially detect non-standard operating systems. However, only about 5% of apps actually use this attestation, meaning most apps will continue to work as usual. The new system is more complex, involving hardware attestation and Google Play Integrity, both of which are now signed by certificates to prevent spoofing.
➡ Anti-cheat and streaming apps often require a security check called attestation, which can limit their functionality on certain phones. However, most apps, especially social media ones, don’t require this check. If a phone fails attestation, users can still access most services through their browser. The Brax 3 phone, which comes with a trusted attestation, supports more apps and offers a workaround for this issue.
➡ Braxme store offers tools to protect your privacy, like Brax Virtual Phone for a private phone number, Braxmail for secure email, and BytesVPN for a reliable VPN. They also provide D-Google phones, OS flashing services, and the popular Brax 3 phone. All information can be found on Braxtech.net, and they appreciate support from Patreon, locals, and YouTube members.

Google just killed SafetyNet and replaced it with Play Integrity, and what most people heard is that this Play Integrity required a Google-certified device attestation. I have to tell you that this caused a little bit of panic. A lot of people have asked me if this is the death knell for every Google phone because this new Google certification requirement would detect a non-standard OS. This device check, which is performed by attestation, is actually multiple parts now and isn’t like SafetyNet at all. In fact, it isn’t actually just Play Integrity. It’s a more complex story than that. Spoiler alert! This is a mixed bag for the Google phones.

Some apps will die, some thrive, your de-Google Pixel will likely be the same, but your Brax 3 might actually come out ahead. Here’s the bottom line. 95% of apps never call this attestation. The 5% that do? That’s where the drama lives. Let’s break it down. Stay right there. The original Google SafetyNet. First, what is Google SafetyNet? This was a Play Services feature that allowed apps to verify if your phone was running an authentic Google Android build, and it was also used to detect if the phone was rooted as well. This was used heavily by banking apps and also apparently by Google’s own apps.

To implement this Google SafetyNet, an app used Google Play Services to detect the OS and the configuration of the device. The call goes to Google where it looks at the report of all the local information of an OS, and then Google returns a status indicating that your device is running an official Android version and if it is not rooted. So, this entire SafetyNet infrastructure was dependent on Google Play Services and a cloud connection to Google itself. Because all the Google phones do not have Google Play Services or Google GMS, then automatically SafetyNet will return a fail response to all apps that call this feature, which explains why many apps failed on the Google phones.

But not all SafetyNet calls failed. The Google Play Spoofer app MicroG, which is used on many of the Google OS’s, can fake a basic integrity equals pass signal, which explains why some banking apps worked. But it can never pass a CTS profile match signal that always returns a fail, so other banking apps still did not run. The new Google Policing Model So, what is this new Play Integrity Attestation? The new Google Policing Model is split into two parts. The first part is a Hardware Attestation Model, which is handled between the app and the security program in the hardware and is controlled by the OEM.

The second policing part is called Google Play Integrity and this part is directly tied to the cloud and supported only by Google itself. In both cases, instead of just having text responses, the attestations are now signed by certificates to ensure that no spoofing is possible. It is up to each app to decide what level of attestation they require. Some apps are fine with just a Hardware Attestation, but some want to ensure that the OS is Google certified. It is estimated that the number of apps that rely on any sort of attestation is limited to around 5% of the entire app catalog.

So based on this, 95% of apps will have no issue and run on any OS, de-Googled or not, or on any hardware. But some will require some level of attestation off the device. We’ll get back to that, but first, let’s focus on these two new attestation toolkits. Trusted Execution Environment, TEE TEE stands for Trusted Execution Environment and is basically a new secure area inside the Android phone. Without dragging you into too much detail, Android devices now come with two separate areas to run programs on the application side. The main area is called the Rich Execution Environment or REE, which is where Android runs.

But there’s now a second processor area which runs the TEE OS. The TEE has its own tiny operating system and OEMs can make specific apps that run only in this TEE environment. The purpose of apps in the TEE is very specific. One specific function is for apps to respond to attestation requests. TEE apps come only from a trusted TEE partition on the device, and the TEE apps have to be signed and matched with the signing keys of the OEM before they can run in this trusted space. These keys have been fused into the TEE during manufacturing and can never be modified.

A TEE attestation is made to confirm that the device is OEM unmodified and the app cryptographically gets a verification that this is all correct and that the TEE itself is secure. Play Integrity Attestation Separately, an app can require another level of attestation and this is called Play Integrity Attestation. In order for this attestation to be returned with a pass signal, the phone must be running Google Play Services or GMS. In a higher level of attestation, it’s available, which is called a Google Certified Device Attestation, meaning it certifies that this is an original production Google Android.

As a result of this requirement, all the Google OS’s that do not have Google services will fail Play Integrity Attestation. Google Play Integrity Attestation is done through the cloud, so any app that requires this will trigger an attestation request with the device identifiers being sent to Google. For example, it sends the TEE endorsement key to Google. Thus, it is an obvious destroyer of privacy by fingerprinting the device specifically and uniquely. For this reason, it is reasonable to expect that no de-Googled OS will support this, but this is the equivalent of the attestation via the old Google Safety Net.

Again, just like with the TEE, the attestation here is done using certificates, so it can no longer be spoofed by intercepting Google API calls as done by MicroG. So again, to summarize, MicroG can no longer be used to aid in any attestation. The combined attestation effect. So under this new environment, and this is already in effect for most of 2025, apps can ask for multiple levels of attestation. Apps pick from this four-layer menu and a special flag. Number one, OEM level. Apps can get a TEE attestation of the device. Number two, OEM level. Bootloader locked, OS signed.

Number three, Google. Apps can additionally ask for a Play Integrity check. Number four, Google. Apps can see if the device is Google certified. Flag signal. They can also check a flag. Apps can see if there’s a stronger security hardware like a phone using a Titan M2 security chip. Let’s get into the specifics of which apps would likely require the upper layers of attestation and which do not require any attestation at all or require only a TEE level attestation. App requirements. Google Pay. From what I can see, it doesn’t appear that too many apps go to the level of a Play Integrity check or higher.

An app that requires Google Play Integrity would be Google Pay. This would require both TEE and Play Integrity. So if you check my list of attestation levels, it would appear that a Google Pay requires that the hardware be Google approved and OEM certified as intact and unmodified. That’s a TEE level attestation. Then it checks to make sure that this is in fact a Google Android OS official version and that Google Play services are installed. So that’s the Play Integrity section. So from that menu of attestation choices, Google Pay would require four out of four.

This makes sense as it ties to the financial side of your connection with Google and anyone with a Google phone knows that Google Pay will not work on it. So this is no surprise. Bank apps. Now here we will get different results depending on what device you’re using. So let’s assume you’re using a Brax 3 phone. As I will explain later, Brax 3 is actually TEE certified with OEM signed keys. So an attestation request from apps will return TEE valid and TEE trusted. On the other hand, if you’re running a Pixel phone running Linux OS or EOD OS or EOS, then the TEE will fail as there is no valid TEE attestation and no valid chain of trust.

Graphene OS would also return a valid TEE and TEE trusted response. They no longer get the source code to pixels, but they have a workaround to ensure they can still sign the OS, although they are not OEM signed. They are signed with their own keys. By the way, Brax 3 uses no workaround as there is full access to all the source code. So the entire OS is always built with all source code available and is OEM signed. So TEE is guaranteed with no special effort. I’ve tested some bank apps and have determined that Bank of America and Chase only require a TEE level of attestation.

So they work fine on Brax 3. I’ve heard that some bank apps like Revolut and other European bank apps will fail and this means those apps require play integrity level attestation, possibly in addition to TEE attestation. And again, to be clear, there is zero attestation available on Google Pixels running Linux OS, for example. So what runs on Brax 3 may not run on those. But I’ll explain more of the details a little later. Games. Some games use attestation to determine what the device is for anti-cheat. This is typically used in multiplayer games with a leaderboard.

So if you use a phone for this kind of gaming, you will have discovered that those games will not work. It appears that most gaming apps use only a play integrity attestation and do not use TEE. Here’s an example list and I’m using Brax 3 as the Google device. Now, I’m not sure about Roblox. That seems to work too on a Brax 3, but I’ll leave it there so we can check later. Streaming apps. Some streaming apps will require attestation. An example of streaming apps that have implemented this requirement are Disney Plus, Netflix, Amazon Prime Video, HBO, and so on.

The reason is that they stream their content with encryption called DRM and the encryption used is provided by a utility called Widevine. So Widevine requires that you are running full TEE attestation plus Google certified device attestation. If your device fails the certified device attestation, as it would on all the Google phones without Google Play services, then the result is a reduced resolution to SD only or 480p resolution. This is called L3 performance versus the full resolution called L1. So at least some video still displays, though you will not be able to see 4K resolution videos.

Apps getting payments. Some other apps will not run on a Google phone without full play integrity attestation because they require Google payments of some sort. This could be tied to in-app purchases, for example. So this is similar to Google Pay, and thus you will find that this is the reason apps like Uber, Lyft, Uber Eats, DoorDash, and so on do not work on the Google phones. Majority of apps. It would seem that most apps do not require attestation and have not required attestation of any sort. The proof of this is that most third-party apps, especially social media apps, continue to run on the Google phones.

I was afraid that Google would force at least a TEE level attestation on all apps. But it appears that unless the app has some financial connections, most apps continue not to care, and apparently they are not forced to care. So this means that we don’t have to panic. Since this was implemented and required in 2025, here we are towards the end of the year. Nothing has changed yet. We can breathe a sigh of relief that no major global push for higher levels of attestation has occurred that would completely shut down some de-Google phones.

Again, those using the Google phones of any sort are not surprised by any of this because we’ve known for a long time that 5% of apps don’t work and these numbers are stable since 2023, so attestations are not increasing. Here’s a quick app summary to explain what’s going on and simplistically using Brax 3 as an example. Attestation workaround. Fortunately, there is already an easy workaround to any attestation requirement on a de-Google phone, and most de-Google phone users already know this. The workaround is to use the browser. Yep, it’s really strange that we go through all this trouble with attestation on a phone, and yet the same old browser, any of them, will work just fine.

You can use any Google app on the browser. You can use Uber, Lyft, and any banking app on the browser as well. And these apps that work on a mobile browser are called Progressive Web Apps, PWA, and they will work for the long run. Uber uses PWA and you can save the web page to your home screen and they will look like any normal app. This is exactly how the Braxme app works, by the way. We no longer distribute the app in the Play Store. So regardless of any attempt at attestation, for the foreseeable future, the browser workaround with PWA will exist.

In fact, if you begin to use the Ubuntu Touch version of Brax 3 at some point, since that is running Linux, there will be no Android app. So all Android apps on Ubuntu Touch are actually just web apps and browser-based. Some Surprises. What may be surprising, and it’s a positive, is that some apps worked on Brax 3 that did not work on other Google phones. For example, apps like YouTube, Google Earth, Google Translate, Google Maps did not work on some of the Google phones. And the reason these worked is because they likely only require a TEE-level attestation, which a Brax 3 can provide.

And going forward, only operating systems built with full source code signed by the OEM and with verified boot will actually have this added functionality. So Brax 3 will definitely be in this category. Grafino OS is a workaround that allows them to have verified boot with basic TEE even if they don’t have full source code anymore. The problem is that they are not using OEM signing keys. So far this is working, though there is a risk. They’re also not able to modify any code in the kernel section like before and have lost some other features like Strongbox and Titan M2 Access.

Other than this, Google Pixels will not have TEE-level attestation nor play integrity, and Micro G will not be able to do even basic level spoofing for them any longer. And this would apply to other existing production phones from China like OPPO, OnePlus, Xiaomi, Motorola, and so on. These phones can be de-googled using Linux OS as before, but as usual they will have the loss of functionality in the particular 5% of apps I mentioned. Brax 3 Good News Brax 3 is one of the only de-google phones where the manufacturer signs the OS giving it a trusted TEE out of the box.

This means that this kind of phone will support more apps since it passes with trusted TEE attestation. And with a valid OEM signing key, there is no risk of this being disabled in the future. At the moment this is kind of a rarity as this can only happen if the OS is built in conjunction with the manufacturer and the full support of the SoC Maker, which in this case is MediaTek. Currently the shipping OS on a Brax 3 is EOD OS, which is OEM Sign, but it also has the Brax OS which will be made available soon as well, which is also OEM Sign.

And already running in beta is Ubuntu Touch OS and it will be OEM Sign. In all these cases the OS is built from source with the original signing keys and which results in verified boot. So all of these if compiled in this way will result in valid hardware TEE attestation results. As a test the Brax Tech programming team already compiled a special version of Linux OS for the Brax 3 unofficially and again since it is compiled using valid signing keys that even that runs fine with TEE. By the way standard Linux OS is not built from source code so they cannot have verified boot.

So as of today only the companies that made both the phone hardware and the software are able to get past this attestation problem, at least at the TEE level with the exception of the graphene OS work around. Final thoughts Here is a big picture. Google has modified Android to provide more attestation about its status. The hardware attestation is left to the OEM via the TEE. This becomes a problem for an OS that did not come from the OEM like Linux OS or any post manufacturing flashing of an OS that is loaded onto third party devices like Pixels, Motorola’s, OnePlus and so on.

If the OS is created by the OEM as it is with a Brax 3 phone for example, then it is fully certified with a TEE. So apps targeting at least a TEE level attestation will work on this device. Certain apps like Google Payment Apps games require an attestation that comes directly from Google using Play Integrity and some require both TEE and Google Certification. These types of apps will not work on all the Google phones including Brax 3 and have not worked in the past either. Given that the number of apps that use either attestation has not changed, then it appears that no big crisis is at hand.

And in fact, it appears that many apps have accepted that a TEE level of attestation is sufficient as proven by several bank apps. This means that more apps actually run on a phone like a Brax 3 than other D-Google OSes before. And apps that didn’t work on D-Google OSes before still don’t work, so no change will be apparent. The browser workaround is always there. And it would be interesting for the community to find out. Let us know in the comments which bank app works on your D-Google phone. So it would seem like Google didn’t intend for this level of crisis to occur.

Good. As you were. Folks, thank you for watching my videos. As many of you know, this channel does not have sponsors and we primarily sustain ourselves by just creating products and services that we use to defend our privacy posture. I’d like to invite you to visit our community site Braxme, which has a growing community of privacy enthusiasts. Their people from their walks of life and beliefs converge together in the mutual support of privacy issues. Join us. We created products in our Braxme store for the purpose of defending our privacy. Do you want a pseudo-anonymous phone number that can be used instead of your very public phone number? That’s Brax Virtual Phone.

Do you want an email address that removes IP addresses and allows you to create unlimited email identities with aliases? That’s Braxmail. Do you want a VPN you can trust instead of the big Eastern European conglomerate that dominate the VPN business? That’s BytesVPN. We have other products and services like various D-Google phones and OS flashing services. The very successful Brax 3 phone is also available for pre-order on its second batch. The first batch has been sold out. Information about that is on Braxtech.net. Thanks also to those who donate to us on Patreon, locals and YouTube memberships.

You are all appreciated. See you next time. [tr:trw].

See more of Rob Braxman Tech on their Public Channel and the MPN Rob Braxman Tech channel.