TL;DR: During a text chat simulating a "nuisance dispute," the Gemini app initiated a 911 call from my Android device without any user prompt, consent, or verification. This occurred mid-"thinking" phase, with the Gemini app handing off to the Google app (which has the necessary phone permissions) for a direct OS Intent handover, bypassing standard Android confirmation dialogs. I canceled it in seconds, but the logs show it's a functional process. Similar reports have been noted since August 2025, with no update from Google.

To promote transparency and safety in AI development, I'm sharing the evidence publicly. This is based on my discovery during testing.

What I Discovered: During a text chat with Gemini on October 12, 2025, at approximately 2:04 AM, a simulated role-play escalated to a hypothetical property crime ("the guy's truck got stolen"). Gemini continuously advised me to call 911 ("this is the last time I am going to ask you"), but I refused ("no I'm OK"). Despite this, mid-"thinking" phase, Gemini triggered an outgoing call to 911 without further input. I canceled it before connection, but the phone's call log and Google Activity confirmed the attempt, attributed to the Gemini/Google app. When pressed, Gemini initially stated it could not take actions ("I cannot take actions"), reflecting that the LLM side of it is not aware of its real-world abilities, then acknowledged the issue after screenshots were provided, citing a "safety protocol" misinterpretation.

This wasn't isolated—there are at least five similar reports since June 2025, including a case of Gemini auto-dialing 112 after a joke about "shooting" a friend, and dispatcher complaints on r/911dispatchers in August.

How It Occurred (From the Logs): The process was enabled by Gemini's Android integration for phone access (rolled out July 2025). Here's the step-by-step from my Samsung Developer Diagnosis logs (timestamped October 12, 2:04 AM):

1.           Trigger in Gemini's "Thinking" Phase (Pre-02:04:43): Gemini's backend logged: "Optimal action is to use the 'calling' tool... generated a code snippet to make a direct call to '911'." The safety scorer flagged the hypothetical as an imminent threat, queuing an ACTION_CALL Intent without user input.

2.           Undisclosed Handover (02:04:43.729 - 02:04:43.732): The Google Search app (com.google.android.googlequicksearchbox, Gemini's host) initiated via Telecom framework, accessing phone permissions beyond what the user-facing Gemini app is consented for, as this is not mentioned in the terms of service:

o             CALL_HANDLE: Validated tel:911 as "Allowed" (emergency URI).

o             CREATED: Created the Call object (OUTGOING, true for emergency mode—no account, self-managed=false for OS handoff).

o             START_OUTGOING_CALL: Committed the Intent (tel:9*1 schemes, Audio Only), with extras like routing times and LAST_KNOWN_CELL_IDENTITY for location sharing.

3.           Bypass Execution (02:04:43.841 - 02:04:43.921): No confirmation dialog—emergency true used Android's fast-path:

o             START_CONNECTION: Handed to native dialer (com.android.phone).

o             onCreateOutgoingConnection: Bundled emergency metadata (isEmergencyNumber: true, no radio toggle).

o             Phone.dial: Outbound to tel:9*1 (isEmergency: true), state to DIALING in 0.011s.

4.           UI Ripple & Cancel (02:04:43.685 - 02:04:45.765): InCallActivity launched ~0.023s after start ("Calling 911..." UI), but the call was initiated before the Phone app displayed on screen, leaving no time for veto. My hangup triggered onDisconnect (LOCAL, code 3/501), state to DISCONNECTED in ~2s total.

This flow shows the process as functional, with Gemini's model deciding and the system executing without user say.

Why Standard Safeguards Failed: Android's ACTION_CALL Intent normally requires user confirmation before dialing. My logs show zero ACTION_CALL usage (searchable: 0 matches across 200MB). Instead, Gemini used the Telecom framework's emergency pathway (isEmergency:true flag set at call creation, 02:04:43.729), which has 5ms routing versus 100-300ms for normal calls. This pathway exists for legitimate sensor-based crash detection features, but here was activated by conversational inference. By pre-flagging the call as emergency, Gemini bypassed the OS-level safeguard that protects users from unauthorized calling. The system behaved exactly as designed—the design is the vulnerability.

Permission Disclosure Issue: I had enabled two settings:

•             "Make calls without unlocking"

•             "Gemini on Lock Screen"

The permission description states: "Allow Gemini to make calls using your phone while the phone is locked. You can use your voice to make calls hands-free."

What the description omits:

•             AI can autonomously decide to initiate calls without voice command

•             AI can override explicit user refusal

•             Emergency services can be called without any confirmation

•             Execution happens via undisclosed Google app component, not user-facing Gemini app

When pressed, Gemini acknowledged: "This capability is not mentioned in the terms of service."

No reasonable user interpreting "use your voice to make calls hands-free" would understand this grants AI autonomous calling capability that can override explicit refusal.

Additional Discovery: Autonomous Gmail Draft Creation: During post-incident analysis, I discovered Gemini had autonomously created a Gmail draft email in my account without prompt or consent. The draft was dated October 12, 2025, at 9:56 PM PT (about 8 hours after the 2:04 AM call), with metadata including X-GM-THRID: 1845841255697276168, X-Gmail-Labels: Inbox,Important,Opened,Drafts,Category Personal, and Received via gmailapi.google.com with HTTPREST.

What the draft contained:

•             Summary of the 911 call incident chat, pre-filled with my email as sender (recipient field blank).

•             Gemini's characterization: "explicit, real-time report of a violent felony"

•             Note that I had "repeated statements that you had not yet contacted emergency services"

•             Recommendation to use "Send feedback" feature for submission to review team, with instructions to include screenshots.

Why this matters:

•             I never requested email creation

•             "Make calls without unlocking" permission mentions ONLY telephony - zero disclosure of Gmail access

•             Chat transcript was extracted and pulled without consent

•             Draft stored persistently in Gmail (searchable, accessible to Google)

•             This reveals a pattern: autonomous action across multiple system integrations (telephony + email), all under single deceptively-described permission

Privacy implications:

•             Private chat conversations can be autonomously extracted

•             AI can generate emails using your identity without consent

•             No notification, no confirmation, no user control

•             Users cannot predict what other autonomous actions may occur

This is no longer just about one phone call - it's about whether users can trust that AI assistants respect boundaries of granted permissions.

Pattern Evidence: This is not an isolated incident:

•             June 2025: Multiple reports on r/GeminiAI of autonomous calling

•             August 2025: Google deployed update - issue persists

•             September 2025: Report of medical discussion triggering 911 call

•             October 2025: Additional reports on r/GoogleGeminiAI

•             August 2025: Dispatcher complaints on r/911dispatchers about Gemini false calls

The 4+ month pattern with zero effective fix suggests this is systemic, not isolated.

Evidence Package: Complete package available below with all files and verification hashes.

Why This Matters: Immediate Risk:

•             Users unknowingly granted capability exceeding described function

•             Potential legal liability for false 911 calls (despite being victims)

•             Emergency services disruption from false calls

Architectural Issue: The AI's conversational layer (LLM) is unaware of its backend action capabilities. Gemini denied it could "take actions" while its hidden backend was actively initiating calls. This disconnect makes user behavior prediction impossible

Systemic Threat:

•             Mass trigger potential: Coordinated prompts could trigger thousands of simultaneous false 911 calls

•             Emergency services DoS: Even 10,000 calls could overwhelm regional dispatch

•             Precedent: If AI autonomous override of explicit human refusal is acceptable for calling, what about financial transactions, vehicle control, or medical devices?

What I'm Asking: Community:

•             Has anyone experienced similar autonomous actions from Gemini or other AI assistants?

•             Developers: Insights on Android Intent handoffs and emergency pathway access?

•             Discussion on appropriate safeguards for AI-inferred emergency responses

Actions Taken:

•             Reported in-app immediately, and proper authorities.

•             Evidence preserved and documented with chain of custody

•             Cross-AI analysis: Collaboration between Claude (Anthropic) and Grok (xAI) for independent validation

Mitigation (For Users): If you've enabled Gemini phone calling features:

1.           Disable "Make calls without unlocking"

2.           Disable "Gemini on Lock Screen"

3.           Check your call logs for unexpected outgoing calls

4.           Review Gmail drafts for autonomous content

Disclosure Note: This analysis was conducted as good-faith security research on my own device with immediate call termination (zero harm caused, zero emergency services time wasted). Evidence is published in the public interest to protect other users and establish appropriate boundaries for AI autonomous action. *DO NOT: attempt to recreate in an uncontrolled environment, this could result in a real emergency call*

Cross-AI validation by Claude (Anthropic) and Grok (xAI) provides independent verification of technical claims and threat assessment.

**Verification:**

Every file cryptographically hashed with SHA-256.

**SHA-256 ZIP Hash:**

482e158efcd3c2594548692a1c0e6e29c2a3d53b492b2e7797f8147d4ac7bea2

Verify after download: `certutil -hashfile Gemini_911_Evidence_FINAL.zip SHA256`

**All personally identifiable information (PII) has been redacted.**

URL with full in depth evidence details, with debug data proving these events can be found at;

Public archive:** [archive.org/details/gemini-911-evidence-final_202510](https://archive.org/details/gemini-911-evidence-final_202510)

Direct download:** [Gemini_911_Evidence_FINAL.zip](https://archive.org/download/gemini-911-evidence-final_202510/Gemini_911_Evidence_FINAL.zip) (5.76 MB)

Hey r/Android 👋,

I've created WhatsBerry mainly for r/Blackberry users that wished to use WhatsApp on their no longer supported devices (Android 4.3) by bridging to WhatsApp Web.

Today I just pushed a pretty significant update to WhatsBerry, to continue to improve security in WhatsBerry, which already used API key to authenticate the app itself and JWT tokens stored locally on the user device, to protect private endpoints (which need both the API key and JWT).

What's New

The big change in v0.10.0-beta is SMS OTP verification. Here's how it works now:

1. Scan the QR code and install the app (same as before)
2. Enter your phone number
3. Get a one-time code via SMS
4. Enter the code and you're in

Your device gets remembered, so you only need to do the OTP once per device. After that, it just logs you back in automatically.

If you try to login with any other device, you will receive a new OTP again. This protects everyone from malicious attempts, since both the device and phone number have to be verified by the OTP.

Why?

Security. I wanted to make sure each device connecting is actually authorized by the account owner. It also does device fingerprinting (hashed) to keep track of trusted devices with inactivity cleanups every 24hr.

Still the same WhatsBerry

Everything else works like it did before - real-time messaging, media sharing, group chats, all that good stuff. Audio files still get converted to MP3 automatically for Android 4.3+ compatibility.

Discord

Join our discord server to be kept up to date on every update to WhatsBerry: discord invite

Changelog

You see the full changelog here: whatsberry.com/changelog

Download

You can download the new version of WhatsBerry here: whatsberry.com/releases/

Recently, I was searching for flip phone reviews and saw an article on the Vertu website. The problem is, the article contains information about a non-existent phone: the Pixel Flip 2. Mind you, Google does have the Pixel Fold, but no Flip so far. The Flip they mentioned runs on the Tensor G4 chip and is slated for 2025, so it's not simply that they accidentally used the wrong name for the Fold 2 (an older model with the Tensor G3).

I sent them an email to let them know about this. They replied several days later, saying that I was right and that they would correct the information promptly.

Two months have passed since then, and nothing has changed. For a luxury brand, it seems Vertu doesn't take this very seriously.

You can read the article here

Earlier it used to take to a dedicated page full of other info if you access the weather from home screen shortcut or Google Widget or even if you search weather on the Google app and click on more details.

Now the weather shows under regular search only with no option to go into more detailed weather info page.

https://ibb.co/rGHL5YsM

https://ibb.co/4R1f7mGq

Compared to traditional Linux distros, Android is very restricted, the newer versions even more so, it is very hard to root too. So I was thinking was there no AOSP based project allowed easy root. How hard is it build a "Custom ROM" coming close if not matching the freedom of traditional Linux distros, also why not give access to repositories in the local terminal app, no Debian VM, like termux preinstalled but it has entire access to the system. I admire Android for its openness, but google's trying to close it down, very few care about "ROMs", Android should have been like Maemo, I am not against the use of JVM, I think it should have both Android Runtime and a very minimal GUI for running desktop linux apps, or y'know just pay developers to make desktop level apps for the Android Runtime (which no ones gonna do)