This page establishes the conceptual and technical framework of the Android IP Rotator (ADB) project.

Its goal is for any technical person who lands here to be able to:

• Understand the real problem being investigated.
• Know the initial hypotheses.
• Understand the test environment.
• Correctly interpret the conclusions.
• Continue the research without redoing prior work.

This section does not describe tools or specific commands; it defines the why and the scope of the project.

There is a common belief that when airplane mode is toggled on and off on a mobile phone, the carrier automatically assigns a new public IP address.

This project was created to challenge that assumption from a technical perspective, using a concrete scenario:

An Android phone used as a modem (USB tethering), controlled exclusively from a PC via ADB, with no root access.

The research does not assume outcomes. It documents what actually happens at the radio, system, and network levels.

The investigation is organized around a main question:

Is it possible to force a public IPv4 IP rotation by fully controlling a mobile data connection on an Android device only via ADB, without system privileges?

From this, other questions follow: [conversation_history:1]

• Can ADB reproduce the behavior of the system’s manual (UI) toggle?
• What differences exist between a logical change and a physical radio change?
• What evidence does the system leave when a real renegotiation occurs?
• Why do some reconnections change the IP while others do not?

The starting hypothesis was:

If the mobile connection is fully torn down and then re-established, the carrier should assign a new public IP.

The research aims to validate or refute this hypothesis, not confirm it for convenience.

All documented tests were performed in a real environment, not a simulation:

• Device: Redmi Note 13 Pro Plus
• Operating system: HyperOS (MIUI-based)
• Carrier: Mobile IPv4 network under CGNAT
• Connection mode: USB tethering
• Host machine: Windows
• Root access: No
• ADB: enabled with USB debugging (security settings)

This environment defines the observed technical limits. Results may vary across devices or carriers.

The project adopts an evidence-based observation approach, not assumptions.

Priority was given to:

• Reproducibility of tests.
• Controlled log capture.
• Comparison across scenarios.
• Interpretation of internal system behavior.

Conclusions are based on:

• Observable events.
• System states.
• Carrier behavior.

Not on theoretical expectations.

The core result of the research is:

Connectivity control via ADB does not reproduce the same internal flow as Android’s manual system toggle.

In many cases:

• The radio does not fully detach.
• The carrier session remains.
• The public IP does not change.

This finding reframes the problem: it is not about “rotating an IP”, but about understanding what constitutes a real disconnection.

A determining factor identified is the carrier’s use of CGNAT. This implies:

• Shared public IP addresses.
• Persistent sessions.
• Reuse of network context.
• Port changes without IP changes.

Under CGNAT, many reconnections do not invalidate the session, even if the device appears locally disconnected.

During the research, clear limits were identified:

• ADB is sandboxed by design.
• Deep radio control requires system permissions.
• Internal Telephony APIs are not accessible without privileges.
• The RIL is proprietary and OEM-dependent.
• The carrier ultimately controls IP assignment.

These limits are not project failures; they are architectural decisions of the Android ecosystem.

This project documents:

• What can be observed and controlled.
• What cannot be forced without additional privileges.
• Why certain approaches fail.

It does not attempt to:

• Bypass controls.
• Exploit vulnerabilities.
• Provide anonymity solutions.

From this point forward, the next sections go deeper into:

• Technical differences between manual toggle and ADB.
• Radio log analysis as evidence.
• Carrier behavior under CGNAT.
• Architectural limits of the system.

This document should be read as the conceptual foundation for the rest of the Wiki.