Greetings,

I was wondering: has anyone else ever seen something similar?

Setup: GrapheneOS Pixel 10, no Google account, no Play Store, no Google Play Services. Telegram was installed from the official Telegram Android APK, not from a random mirror.

First case: an existing Telegram account, already active on another device through Telegram X, with 2FA enabled and an email already configured. When I tried to log in from the GrapheneOS phone, Telegram did not send the login code to the already active sessions. Instead, it forced me into an email login flow. The email shown was correct, the code arrived, I entered it, and Telegram replied with EMAIL_NOT_ALLOWED.

That is the part I still cannot make sense of. Telegram picked the email, sent the code to that email, accepted that this was the login path, and then rejected the same path after I entered the correct code. What the fuck.

I tried to rule out local hardening as the cause. I loosened the app setup enough to test: network allowed, notifications allowed, unrestricted battery, unused-app management disabled, sensors allowed, dynamic code loading allowed, and a generally more permissive setup. Contacts stayed denied. Nothing important changed.

Then I tried Telegram X, also from the official Telegram X source. It did not solve it. It again drifted into the same kind of degraded authentication path, and at one point I got Premium/payment-style friction on an already existing active account. I stopped there. I was not going to pay just to discover the next stupid gate in the maze.

Then I tested something more interesting: a real mobile number, not the previous account/number, not linked to any Telegram login email, and known to work normally on another GrapheneOS Pixel where Telegram sends the code to existing active sessions. On this no-Google Pixel, Telegram Android again did not show the normal “code sent to Telegram on your other devices” flow. It went straight to “choose a login email”.

So the issue does not look specific to one weird number or one weird account.

To check the opposite direction, I also tested the original account from a clean Telegram Desktop folder, without reusing the existing tdata session. Desktop behaved normally: it sent the code to active Telegram sessions, accepted the code, asked for the 2FA password, and logged in. No SMS, no email, no Premium nonsense.

So the account was alive, the existing sessions were valid, and the normal code-to-active-sessions flow worked outside Android on this Pixel. Telegram Web also worked by QR in Vanadium inside Private Space. Messages sync, the session persists, and the workaround is usable.

The pattern now looks pretty clear: Telegram Desktop works, Telegram Web works, active sessions work, QR works, but Telegram Android on the no-Google GrapheneOS Pixel keeps being pushed into email/Premium-style fallback paths instead of using active sessions.

The comparison that bothers me is that another GrapheneOS Pixel with sandboxed Google Play available does not show this behavior. On that device, Telegram also shows a Play Integrity-related entry in app details. On the no-Google device, that entry does not appear. That does not prove causation, but at this point it is a pretty loud clue.

My current suspicion is that Telegram Android may rely on Google Play Services, Play Integrity, or related device-trust signals during login. Maybe not as a universal hard requirement, but enough to push some devices/accounts into a worse fallback path. And if that fallback path is email-based and can end in EMAIL_NOT_ALLOWED, or even Premium/payment friction, the user is basically dumped into a swamp.

Has anyone else seen this pattern?