Enterprise Networking Guide
Mobile Android CTS and GTS Testing: Lab Preparation Guide for IPv4/IPv6 Dual-Stack Networks
For smartphone and mobile device R&D testing teams, we introduce a real globally routable unicast IPv6 and IPv4 dual-stack network, matching DNS resolution, and required service connectivity over existing lab broadband, supporting shared use across multi-model test benches and flexible adjustments by project.
During build development and pre-shipment validation for smartphones, tablets, and other Android mobile devices, testing teams frequently run CTS and GTS test suites. Unlike routine office internet use, compatibility and service validation often requires test Wi-Fi to simultaneously provide routable IPv4 and IPv6 dual-stack connectivity to the public internet, matching DNS resolution for both address families, and stable access to external test services. Using your lab's existing broadband, we bring a usable global unicast IPv6 and IPv4 dual-stack network and required service connectivity directly to the test site—avoiding the long construction waits of installing new physical dedicated lines so multiple device models and automated test benches in the same lab can share stable network conditions.
What mobile CTS and GTS testing requires from a lab network
Many R&D lab networks are built around standard office needs, primarily supporting PCs and mobile devices accessing web pages and internal repositories over IPv4. Once compatibility testing begins, testers often run into two network roadblocks: first, on-site broadband or wireless routers lack usable public IPv6, causing test cases involving the IPv6 stack, dual-stack switching, or address resolution to fail outright; second, even when a device screen displays an IPv6 address, the lack of stable external IPv6 routing, dual-stack DNS resolution, or connectivity to target test services causes test runs to time out and abort midway.
According to Google's public Android CTS preparation documentation (Set up CTS), the Wi-Fi network connected to the device under test (DUT) must support both IPv4 and IPv6, have an internet connection with working DNS for both IPv4 and IPv6, support local IP multicast, and treat the DUT as an isolated client. The documentation also notes that IPv6 connectivity can be provided via native carrier IPv6, a virtual private network, or a Wi-Fi AP with an IPv6 tunnel—what matters is that the wireless interface actually receives usable IPv4 and IPv6 addresses and completes the external communications required by the tests.
When planning a lab network, seeing an IPv6 address string on a PC or phone screen does not necessarily mean the environment is ready; conversely, you do not have to be limited by whether local broadband offers native carrier IPv6, nor do you need to apply for a new traditional international physical dedicated line. As long as the lab test wireless network provides genuinely routable IPv4/IPv6 dual-stack internet access with DNS resolution for both address families—and on-site wireless parameters are configured as required—the network prerequisites will be met.
Note on network conditions for GTS and different Android versions: Google's public CTS setup page does not publish a unified specification for GTS. Requirements for external service access, dual-stack policies, and network egress regions vary across major Android releases, device form factors, and specific GTS test suites. When preparing for GTS or targeted regression testing, we align the required dual-stack connectivity and service access scope with the target version, authorised test documentation, and project checklist used by your R&D team.
How we deliver a usable IPv4/IPv6 dual-stack network to the lab
Tailored to smartphone and mobile device testing labs, we deliver global unicast IPv6 address blocks, required IPv4/IPv6 outbound connectivity, and access to target test services directly to the lab floor, reducing the time testing teams spend reworking underlying network infrastructure:
- Reuse existing lab broadband directly: There is no need to apply to building management or a carrier to lay new physical dedicated lines. You can connect to our transmission network over existing lab or office broadband, with shorter provisioning lead times than traditional carrier dedicated lines—ideal for R&D projects working against tight build milestones.
- Provide a routable global unicast IPv6 and IPv4 dual-stack environment: We deliver global unicast IPv6 address blocks alongside IPv4 connectivity to the lab access appliance, giving the test subnet both usable IPv4 and IPv6 internet egress and matching dual-stack DNS resolution. The access appliance supports DHCPv4 and IPv6 stateless address autoconfiguration (SLAAC), working smoothly with the on-site test network to assign dual-stack addresses to test phones.
- Support system image, SDK, and test dependency downloads: Beyond running test cases on handsets, test hosts and continuous integration environments pulling system images, SDKs, OTA update packages, and test assets can also transmit over this dedicated test network, cutting down long wait times for large file downloads before each new build test cycle.
- Preconfigured access without disrupting the office internal network: Both physical appliances (bridge, bypass, or gateway mode) and virtual appliances (bypass or gateway mode) are supported. Appliances support zero-touch deployment and automatically fetch preconfigured settings once connected. Labs can mount the dedicated dual-stack network separately under a test subnet or dedicated test Wi-Fi without reconfiguring the daily office internal network.
Coordinating test Wi-Fi, client isolation, and multi-bench reuse
When running network-related test cases, handsets under test connect to the public internet through on-site test Wi-Fi in the lab. Keeping the handset network environment stable and ready requires combining our upstream dual-stack connectivity with your on-site wireless LAN configuration:
Coordinating the upstream dual-stack channel with on-site AP configuration: Our network delivers stable IPv4/IPv6 dual-stack internet connectivity, global unicast IPv6 addresses, and dual-stack DNS to the lab access gateway or test switch. Meanwhile, local IP multicast forwarding and treating the handset under test as an isolated client—as required by the CTS environment specification—must be enabled on the lab's on-site wireless APs or wireless controller. A cross-region transmission channel does not replace client isolation on local wireless equipment, nor does it unconditionally bridge all local Layer 2 multicast to remote endpoints. During deployment, we work with your lab administrator to align the upstream dual-stack subnet with the parameters of your on-site test APs and RF shield box wireless environments.
Shared reuse across multiple device models and automated test benches: Handset manufacturers and design houses often run parallel test tracks across multiple models, regional software branches, and overnight automated regression test benches. By centrally bringing a dual-stack test network into the lab, test stations, RF shield boxes, and automated hosts across project groups can share the same infrastructure by test SSID or LAN subnet, without maintaining separate dial-up links or software proxies every time a new test bench is added.
Flexible bandwidth scaling by R&D cycle and connection logging for retests: During peak submission windows for new models, major version freezes, or large-scale concurrent regression runs, network bandwidth can be scaled on demand without waiting for traditional physical dedicated line construction. In addition, our appliances log DNS queries (source IP, target domain, resolution result) and 5-tuple connection records, helping teams cross-check the network egress, DNS responses, and connection state during intermittent test failures to more quickly distinguish device software defects from external network fluctuations.
Service scope and delivery experience with similar test networks
Within the R&D testing workflow, our network solution is positioned to provide stable, reusable IPv4/IPv6 dual-stack connectivity, cross-region service access, and transmission support. System firmware and hardware implementation on the devices under test, test suite and platform account applications, test plan orchestration, and final certification report submissions remain the responsibility of the R&D testing team and respective parties in accordance with platform guidelines.
In R&D testing projects for Android Automotive smart cockpits within the same Android ecosystem, we have centrally delivered standard global unicast IPv6 addresses alongside multi-region network environments—including Hong Kong, Singapore, the United States, Germany, and India—into domestic testing facilities, enabling different project teams in the same office to share infrastructure and allocate network resources on demand. Smartphone and mobile device testing labs preparing environments for CTS, GTS, and overseas software regression can draw on the same proven dual-stack delivery and multi-region network scheduling capabilities to efficiently complete network preparation for every build validation cycle in their local labs.
Basic information to share in an initial consultation
- The city where the testing lab is located, and whether testing is run at a single site or collaboratively across multi-site R&D teams.
- The type of testing project underway (such as smartphone or tablet CTS, GTS, or daily build regression), along with any specific target Android version or test suite requirements.
- Specific requirements of the devices under test for IPv4/IPv6 dual-stack addresses, DNS resolution, external test services, or regional network egress.
- Existing broadband access in the lab, as well as the general connection setup for on-site test Wi-Fi APs, RF shield boxes, or automated test benches.
- Your planned schedule for starting this test round or build submission—no need to prepare a complete network topology diagram or packet capture troubleshooting report in advance.