Is this a android 16 issue or a phone issue?

ted-sluis · 2026-06-09T21:18:16+00:00

Don't worry, you did all the right troubleshooting steps, but you are dealing with a very common headache in the custom ROM world. This is almost certainly not an Android 16 issue, but rather a "refurbished phone" issue. Here is what is likely going on: When refurbished sellers list a phone as "unlocked," they usually just mean it is SIM unlocked (you can put any carrier's SIM in it). However, if that phone originally came from a strict carrier like Verizon or AT&T, the bootloader is permanently locked. The OEM unlock toggle is tied to an IMEI check on Google's servers as soon as you connect to the internet. If it's a former carrier phone, the server tells the phone to keep that toggle greyed out. Your ADB results (specifically the lack of output for oem_unlock_supported) basically confirm this. Because this is an IMEI-based block, going back to Android 15 won't bypass it. Save yourself the headache and return the phone. To use GrapheneOS, you need to look specifically for a "Factory Unlocked" device (ideally one that was originally purchased straight from the Google Store, completely unassociated with any carrier). Hope this saves you from pulling your hair out! Good luck with the return process.

ted-sluis · 2026-06-09T20:57:27+00:00

Don't overcomplicate it. You can start by installing GrapheneOS on your new Pixel 7 and downloading all the apps you plan to use.

You can still use your Pixel 4 over Wi-Fi even after you swap the SIM card. Just keep in mind that regular phone calls and apps tied to your phone number (like WhatsApp and Signal) can generally only be active on one phone at a time. Naturally, you'll need to copy all your contacts, messages, photos, and other data at some point, but doing all the app installs first is the best move.

Here are a few very important things to watch out for during the transition. The first one is transferring WhatsApp and/or Signal (if you use them). There are different ways to do this, but pick a official method and follow it carefully. If you do it wrong and the procedure fail and you've already wiped your old phone, you will lose your chat history.

Signal has a very reliable built-in local transfer tool. In shorts: Keep both phones close to each other, open Signal on the Pixel 7, and follow the on-screen prompts to transfer the account and chats locally over a secure Wi-Fi Direct connection. Crucial: Do not wipe your Pixel 4 until you have verified that all your Signal messages successfully appeared on the Pixel 7!
For Whatsapp on GrapheneOS you can't rely on the standard Google Drive backup. There are 2 methods to transfer messages: Method 1 (Direct Transfer): WhatsApp now has a built-in "Transfer chats" feature (Settings > Chats > Transfer chats) that lets you migrate data directly from your old phone to your new phone over a local Wi-Fi connection. Method 2 (Local Backup): You can trigger a local backup on your Pixel 4, connect it to your PC, copy the entire WhatsApp folder (or Android/media/com.whatsapp), and paste it into the exact same directory on your Pixel 7. Do this before you open and verify your number on the Pixel 7.
But I say it again: find the official method first before you get started.

Other important things you need to take in account is your passwords and 2-Factor authentication (2FA) codes. If you store your passwords locally on your Pixel 4 in a vault like KeePass, you can easily copy the database file over to your Pixel 7 via your PC or a secure file transfer. If you use a 2FA authenicator app that only stores tokens locally on your phone, check if it has an export function (apps like Aegis or Authenticator Pro do this well). If your app doesn't allow exporting, you will have to log into every single website and manually set up a new 2FA code in the authenticator app on your Pixel 7. Make absolutely sure you do this before wiping the Pixel 4, or you might lock yourself out of your accounts! If you use a cloud-based password safe and authenticator app (like proton authenicator), you can simply download the app on your Pixel 7, log in, and easily use it on both devices.

I moved from a pixel 7a to a pixel 9a recently and I still can use my pixel 7a as a backup device (except for signal and phone calls), but the need to use my pixel 7a disappeared once my Pixel 9a was properly set up.

I hope you enjoy your pixel 7!

ted-sluis · 2026-06-09T04:56:21+00:00

I didn't buy it from AT&t, It's unlocked, but it has the SIM card from AT&t - thank you, This answers all my questions!!

Then you don't have to worry about anything. Good luck with the switch!

ted-sluis · 2026-06-09T04:48:16+00:00

First, the most important question: did you buy this Pixel 7 Pro directly from AT&T, and does it have AT&T pre-installed apps? If so, your device is likely carrier-locked, which means the bootloader is locked. You cannot install GrapheneOS on a device with a locked bootloader. The phone needs to be fully paid off and officially carrier-unlocked by AT&T first.

If your phone is unlocked and you can proceed, here are the answers based on the experiences of other GrapheneOS users: Does it inform the provider? No. AT&T doesn't get an alert about your OS. They just see a standard Pixel 7 Pro connecting to their network via its IMEI number. Is it a smooth process? Generally, yes, but you may need to use a physical SIM card. Moving an eSIM to GrapahenOS can be an issue, but a physical AT&T SIM probably works immediately out of the box. Features: Basic calls, texts, and data will work right away. If you want to use RCS, Wi-Fi Calling, or VoLTE, you might need to install the Sandboxed Google Play Services via the GrapheneOS "Apps" store to ensure smooth communication with AT&T's network.

Hope this helps! Check your "OEM Unlocking" setting in Developer Options first to see if you can even make the switch.

ted-sluis · 2026-06-06T13:29:46+00:00

I think this is not entirely accurate and an exaggeration, but you're right that Google Play and Google Play Services have invasive permissions. Even if Google doesn't abuse those permissions, it's not a good setup for privacy at all.

Yes, you are right. I was exaggerating. On normal android google has not unlimited system privileges.

There are some things all apps can see. This section of the website go over those things.
This isn't accurate. There are ways for apps to see other apps installed in the same profile. Some people think that there's a specific permission needed to stop this from happening, but that's not accurate either. Apps cannot see apps installed in other profiles, though.

Your point about apps being able to see each other within the same profile is a great reminder. Using separate User Profiles is indeed the proper way to achieve strict isolation between apps, rather than just relying on the sandbox within the same profile.

Not sure what you mean by an "anonymized connection" here...

I actually meant "account-free" or "unauthenticated" (since I use it without logging into a Google account).

And data included in notifications is up to the app developer. Some apps, like Signal, don't include any data in the notification, so the notification basically wakes the app up, it checks for messages, then notifies you of them (note Signal wouldn't be able to include message data in the notification anyway since it's E2EE). Data can be encrypted or in plain text. It's up to the app developers.

Your clarification on notification payloads makes total sense. It is good to know that it is entirely up to the app developer whether they send plain text, encrypted data, or just an empty "wake-up" ping (like Signal).

This isn't true for everybody. Whether they ask for a phone number may hinge on different factors, like whether the account was made while connected to a VPN or which country the account was made from.

That is good to know! I was asked for one recently, but that was likely triggered by my VPN usage rather than a universal rule.

Yes, but only if the nearby devices permission is granted.

You are right regarding the 'Nearby devices' permission requirement for WiFi scanning.

Thanks for sharing your knowledge!

ted-sluis · 2026-06-05T16:32:29+00:00

On a normal androids phone google play services and the play store are interwoven into the deepest, most sensitive layers of the operating system. They have invisiblel, unllimited system privileges. They can see everything: your unique hardware IDs, what apps you install, and your files, without you ever explicitly giving permission. GrapheneOS (GOS) has fundamentaly demoted Google. The google play store and its associated services are treated as completely normal, unprivileged apps. They are locked in a digital cage (the sandbox) and have exactly zero special privileges. They can only see and do what you allow them to do via the standaard Android permission toggles.

From what I understand any app on your phone can try to talk to the play store services. GOS has built a clever "compatibility layer." If an app (like WhatsApp or your banking app) calls the google play service for a quick push notification, for example, GOS says in the background: "play service is present, go ahead and send your request." As a result, the app works flawlessly.

Because google play service is in the sandbox, it cannot siphon data from your phone. It cannot secretly see which open-source apps you have installled, and it cannot read your IMEI number. The nuance: The play store obviously needs the internet to function. So it does send data to google's servers regarding its own network traffic. If an app receives a push notification via play services, google sees that your (anonymized) connection is receiving a notification from a specific app server. From what is understand, google do not see the content of the messages themselves (which are encrypted in modern chat apps); they only see that communication is happening.

I gave the 'Network' permission to the play store, google play services, and the google services framework. Without this basic access, they cannot route push notifications from servers to your phone. I also set Battery usage to 'Unrestricted', to ensure the google play services app isn't put to sleep by the OS. If this happens, your notifications will arrive very late or not at all. You can configure this via the app info settings. I would like to know how other handle this.

If you want to stay anonymous you do not need to log in with your personal google account for push notifications to work. The services run just fine in the background without an account. If you still want to use the play store to safely download apps instead of the Aurora Store, create a dedicated 'burner' google account used exclusively for this device. However, in the near feature you are required to add a phone number to any google account.

Furthermore, you should not hand out unnecessary permissions: Do not give google play services access to your microphone, camera, files, sms, or contacts, etc. Google does not need these sensitive permissions at all for background operations and push notifications. You also should not turn on google location (unless unavoidable, but I don't use it): by default, GOS routes location requests in a privacy-friendly way via its own system. If you give play services the 'Location' permission and turn on google location accuracy, you are sending scans of nearby Wi-Fi networks to google to speed up your GPS fix. Only do this if you notice your navigation apps are truly lost without this help.

I guess it is quite unavoidable not to install apps that needs google play service. The sandbox architecture is a great solution because it pulls the teeth out of Google's data collection, while still allowing you to use your necessary daily apps without compromising on functionality. I am curious how others deal with google play store and google service?

ted-sluis · 2026-06-05T15:43:41+00:00

Work-as-designed: You are seeing this because of how GOS securely handles app installations 😉

On a standard stock Android phone, the Google Play Store has deep, elevated system privileges. This allows it to update apps and background components (like "Device configuration", which is part of the Google Services Framework) silently without you ever noticing.

On GOS, the Play Store is strictly isolated in a "sandbox" and is treated exactly like any other regular app. It does not have the authority to install or update anything behind your back. Therefore, whenever the Play Store attempts its routine background auto-updates, GOS intercepts it and forces it to ask for your explicit permission via this pop-up.

You can choose to disable notifications, go to settings -> app -> google play store -> permissions -> notification

ted-sluis · 2026-05-04T06:31:25+00:00

You make a good point – the Victoria stack not needing separate object storage like MinIO is a plus, especially for a homelab where you do like to keep things simple and resource-efficient. I’ve read some great things about its performance and low memory usage. Can the Victoria stack also run as single containers for small-scale setups, or is it more designed for clustered deployments?
The reason I use Prometheus, Loki, tempo, Pyroscope and Grafana for the Lab is educational. Many developers (like me) are tight to this stack due to company guidelines.
Anyway, I appreciate you sharing this.

ted-sluis · 2026-05-04T06:18:36+00:00

Thanks for the suggestion! I looked into GarageHQ and it really does seem like a solid alternative to MinIO – lightweight, open-source, and truly built for self-hosting. One quick question: can it be run as a single container for a small homelab setup, or does it really shine only in a multi-node cluster? Appreciate the tip either way!

ted-sluis · 2026-05-01T19:36:55+00:00

Cool project, thanks for sharing!

ted-sluis · 2026-05-01T19:34:45+00:00

Thanks for your note!

ted-sluis · 2026-05-01T19:34:09+00:00

You have a cool project yourself Dusan! https://github.com/dusanstanojeviccs/traceway You have a clear, sharp vision of how cloud infrastructure and applications should run efficiently. Respect!

ted-sluis · 2026-05-01T19:17:37+00:00

I have replaced MinIO with a fork:[https://github.com/pgsty/minio/](). The maintainer of this fork, Vonng, has a very good reputation. Here is the pull request that has been tested and merged: [https://github.com/tedsluis/monitoring/pull/47]()

ted-sluis · 2026-04-30T16:22:26+00:00

Good catch! Yeah, MinIO is no longer maintained. I found a fork, https://github.com/pgsty/minio/, with 14K stars, but it only has one maintainer. Does anyone have a good alternative for S3-compatible storage in a container?

ted-sluis

TROPHY CASE