Captive portal login on Android: a deployment checklist for Cisco Meraki, HPE Aruba and Ubiquiti UniFi

The Android sign-in page fails to appear when Google's connectivity check reaches the internet before sign-in, or its redirect is blocked. Keep the probe host out of your walled garden, allow only splash and login domains, redirect the HTTP probe to an HTTPS splash page, and set a session timeout on Cisco Meraki, HPE Aruba or Ubiquiti UniFi.

What does the Android captive portal login actually do?

A captive portal is the splash page a visitor sees before the network grants internet access. It presents the login options the guest completes before going online. Purple's support article on the captive portal describes the full sequence.

Every major operating system includes a Captive Network Assistant (CNA). The CNA is a small built-in browser that handles the portal for the guest. On Android, the CNA has four jobs:

1. Check internet connectivity as soon as the cell phone joins the network.
2. Tell the person holding the cell phone that they may need to sign in.
3. Open a browser session for the splash page when they tap the notification.
4. Confirm an online status once the login succeeds.

When any of these steps breaks, the guest sees a connected network that does not work. They usually blame your WiFi, not their cell phone.

The connectivity check probe

When an Android cell phone joins a network, it sends a plain HTTP request to a Google-hosted connectivity check endpoint. That endpoint normally returns an empty HTTP 204 response. If the cell phone gets the 204, it concludes the internet is reachable and shows no sign-in prompt.

On a guest network, your controller intercepts that request before sign-in and returns a redirect to the splash page instead. The cell phone sees an unexpected answer and concludes it is behind a captive portal. The whole detection process depends on the probe being intercepted, not allowed through.

The "Sign in to WiFi network" notification

Once the probe fails, Android shows a notification telling the guest they may need to sign in. Tapping it launches the CNA browser session. If the guest swipes the notification away, the cell phone stays connected with no internet access. For that case, Purple recommends opening a browser and visiting neverssl.com. This third-party site stays on plain HTTP, so the controller can redirect it without certificate errors.

What is the captive portal login app on Android?

The captive portal login app is Android's CNA. It is a stripped-back browser with no address bar clutter or extensions. Purple's support documentation describes it as a "blank canvas" that lets the captive portal redirect complete unhindered. Stock Android closes the window automatically once authentication succeeds. Some handset manufacturers change that default, so on those cell phones the guest may need to close the window manually.

Behind the window, three systems work together. The controller manages the interaction with Purple's splash page servers. The splash page collects the guest's details and issues a one-time login. The controller then passes that login to Purple's RADIUS server, the authentication service that grants access, to complete sign-in.

The Captive Portal API and DHCP option 114

Newer Android versions can also learn about a portal without probing. The network advertises a Captive Portal API address through DHCP option 114, defined in RFC 8910. DHCP is the service that hands out IP addresses. The cell phone queries that API over HTTPS, and the response, defined in RFC 8908, says whether the device is captive and where the portal lives. This avoids the redirect trick entirely. It only works if the API endpoint behind the option is live and correctly certified.

What do you need before you start?

Gather these before touching any access point:

• Admin access to your controller or dashboard: Cisco Meraki Dashboard, HPE Aruba (Instant or Central, or a Mobility Controller), or the UniFi Network application.
• An open guest SSID. Purple recommends providing guest WiFi over an open network. Open networks are now the standard convention and reduce friction for visitors.
• A dedicated guest VLAN. A VLAN is a logical network segment. Guest traffic should never share a segment with staff or payment systems, which keeps you inside PCI DSS scope rules.
• Purple's walled garden list and splash page URL. Take the current values from the captive portal support article. Do not copy them from an old deployment.
• RADIUS details for Purple's authentication servers, from your Purple account.
• Test handsets. Use at least three Android cell phones from different manufacturers, plus one iPhone for comparison.

Purple is hardware-agnostic. It runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You configure the controller you already own, with no rip and replace.

How do you set up captive portal login on Android for Meraki, Aruba and UniFi?

Work through five settings in order. Each one maps to a named feature on every platform. For exact menu paths and current values, follow the Purple support article rather than this summary.

Step 1: build a tight walled garden

The walled garden is the list of domains a guest can reach before sign-in. It must include Purple's splash page domains and the domains for any social login you offer. It must not include Google's connectivity check host.

The common mistake is a broad wildcard. Adding every Google domain to support Google sign-in also lets Android's probe through. The phone receives its 204, decides it is online, and never shows the notification. Scope social login entries as narrowly as the provider allows. If you need Google sign-in and Android detection together, test both after every walled garden change.

Step 2: block everything else until sign-on

The controller must intercept all web traffic from unauthenticated devices. Anything left open gives Android a path to a false "online" result.

On Cisco Meraki, set captive portal strength to block all access until sign-on. On HPE Aruba, make sure the pre-authentication role denies everything except the walled garden and DNS. On Ubiquiti UniFi, confirm the guest network restricts all access before authorization, apart from the pre-authorization allowance list.

Step 3: redirect HTTP, and secure the login page with HTTPS

Controllers cannot cleanly intercept HTTPS traffic without triggering certificate errors. Android's probe uses plain HTTP, which the controller can redirect. Leave the probe's HTTP interception in place.

The page the guest lands on is a different matter. Purple's article on Cisco WLC captive portal certificate setup shows what happens when a controller redirects to an unsecured HTTP login address. Browsers show a "Your connection is not private" style warning, and guests assume the network is unsafe. The fix is a publicly trusted SSL/TLS certificate on the controller. The controller's virtual hostname must match the certificate's Common Name. The same principle applies to Aruba controllers that host their own login page.

Step 4: keep DNS working for unauthenticated devices

Guests must resolve the splash page hostname before they sign in. Allow standard DNS to your chosen resolver in the pre-authentication policy. Without it, the redirect points to a name the phone cannot look up.

Android's Private DNS setting adds a second consideration, covered in the troubleshooting section below.

Step 5: set a session timeout that fits the visit

The session timeout decides how long a login lasts before the guest must sign in again. Match it to how long visitors stay. A coffee shop might use a few hours. A hotel should cover the length of a stay.

Step 6: decide on DHCP option 114

Only advertise option 114 if a working, RFC 8908-compliant API endpoint sits behind it. A value pointing at an endpoint that does not answer correctly adds a failure point rather than removing one. If you are unsure, leave it unset. Android falls back to the connectivity probe, which Steps 1 to 4 already support. Confirm with Purple support before enabling it.

Where each fix lives on your platform

Fix	Cisco Meraki	HPE Aruba	Ubiquiti UniFi
Allow splash and login domains before sign-in	Walled garden ranges on the SSID's splash page settings	Walled garden whitelist in the captive portal profile or pre-auth role	Pre-authorization allowance list on the guest hotspot
Keep the probe host blocked	Remove broad Google wildcards from walled garden ranges	Remove broad Google wildcards from the whitelist	Remove broad Google wildcards from the allowance list
Block all other traffic until sign-on	Captive portal strength: block all access until sign-on	Pre-auth role denies all except walled garden and DNS	Guest network restrictions before authorization
Secure the login page	Redirect to Purple's HTTPS splash page URL	Publicly trusted certificate on the controller	Redirect to Purple's HTTPS splash page URL
Session length	Splash frequency and RADIUS session timeout	Session timeout in the captive portal or RADIUS profile	Authorization expiry on the hotspot
DHCP option 114	Custom DHCP option on the MX or upstream DHCP server	DHCP scope on the controller or upstream server	Custom DHCP option on the UniFi gateway network

How do you check the Android sign-in page works?

Test from a clean state every time. A cell phone that remembers the network, or holds a live session, hides the problem you are trying to find.

1. Forget the network on each test handset, then reconnect.
2. Watch for the notification within a few seconds of joining. No notification means the probe reached the internet or DNS failed.
3. Tap it and complete the login. The splash page should load without certificate warnings.
4. Confirm the window behavior. On stock Android it closes itself. On some manufacturers' builds you close it manually, which is expected.
5. Browse to a normal HTTPS site to confirm full access.
6. Repeat with Private DNS set to Strict on one handset, so you know what guests who use it will see.
7. Check the logs. Confirm the RADIUS accept in Purple and the client's authorized state on the controller.

Test on at least three manufacturers' Android cell phones. The iPhone uses a different probe host and CNA, covered in Purple's companion iPhone captive portal guide, but the controller-side causes are the same. One test session catches problems on both platforms.

Why does the Android sign-in to WiFi network notification not show, and how do you fix it?

Most failures trace back to one of five causes. Start with the symptom the guest reports.

Symptom	Likely cause	Fix
Connected, no notification, no internet	Probe allowed through by a broad walled garden entry	Remove wildcard Google entries from the walled garden
Notification appears, splash page never loads	DNS blocked before sign-in, or splash domain missing from walled garden	Allow DNS pre-auth; add Purple's splash domains
"Private DNS server cannot be accessed" warning	Private DNS set to Strict with a named provider	Guest switches Private DNS to Automatic, signs in, switches back
Certificate or "not private" warning	Controller login page served over HTTP or with an untrusted certificate	Install a publicly trusted certificate matching the hostname
Login succeeds, window stays open	Manufacturer changed the CNA default	Close the window manually; no network change needed
Guest must sign in on every visit	New randomized MAC address or short session timeout	Lengthen the timeout; explain randomized MAC settings
Guest dismissed the notification	No prompt to fall back on	Open a browser and visit neverssl.com

Does Private DNS break captive portals?

It can. Android's Private DNS setting encrypts DNS lookups using DNS over TLS. It has two active modes that behave differently on a guest network.

In Automatic mode, Android uses encrypted DNS when the network supports it and falls back to the network's own DNS when it does not. Captive portals load normally.

In Strict mode, the guest names a specific DNS provider hostname. Before sign-in, that provider is unreachable, because your pre-authentication policy blocks it. The phone may be unable to resolve the splash page, and Android may warn that the Private DNS server cannot be accessed.

You cannot reasonably add every public encrypted DNS provider to your walled garden. The practical fix is guest-side guidance. Add a line to your signage or help page: switch Private DNS to Automatic, sign in, then switch back.

Why do Android phones have to sign in again every visit?

Android uses a randomized MAC address per network by default. A MAC address is the hardware identifier your controller uses to recognize a device. The randomized address usually stays stable for one SSID. It changes if the guest forgets the network, resets network settings or changes the privacy setting. To your controller, that phone is then a brand-new device.

The second cause is your own session timeout. A short timeout forces a fresh sign-in whenever the session expires, however stable the MAC address is. Review both before assuming the phone is at fault. For venues where returning visitors matter, OpenRoaming offers automatic, secure reconnection without a splash page. It suits travel hubs and multi-site properties.

Worked scenario 1: a 200-room hotel with Google sign-in

Illustrative scenario, figures for illustration only.

Situation. A 200-room city hotel added Google sign-in to its splash page. Within a week, front-desk staff logged repeated complaints from Android guests. Phones showed full signal but no pages loaded, and no sign-in prompt appeared. iPhone guests reported far fewer problems.

What was done. The network team reviewed the Meraki walled garden. A contractor had added a broad wildcard covering all Google domains to support the new login option. That entry let Android's connectivity probe through. The team replaced the wildcard with the narrower entries listed in Purple's support article. They then retested on cell phones from three manufacturers.

Outcome. Every test handset showed the sign-in notification on the first connection. The front desk logged no further Android WiFi complaints over the following two weeks. The hotel also extended its session timeout to cover a typical three-night stay. That removed daily re-logins for returning guests. See how Purple supports hospitality venues.

Worked scenario 2: a local government library network on UniFi

Illustrative scenario, figures for illustration only.

Situation. A local government ran guest WiFi across 12 branch libraries on Ubiquiti UniFi. Visitors with newer Android cell phones reported a "Private DNS server cannot be accessed" warning and a splash page that never loaded. Branch staff spent time talking visitors through settings they did not understand.

What was done. The IT team confirmed DNS was allowed before authorization, so standard lookups were working. The affected cell phones all had Private DNS set to Strict with a named provider. The team added a short instruction to the splash page help text and branch posters. It told visitors to switch Private DNS to Automatic, sign in, then switch back. They also left DHCP option 114 unset, because no compliant API endpoint was in place.

Outcome. Branch staff reported that most affected visitors now signed in unaided using the poster instructions. Support requests to the central IT desk for library WiFi fell to a handful per month. Public-sector venues share many of the same patterns as transport and healthcare sites.

What does it cost, and what do you get back?

Most Android captive portal fixes cost staff time, not hardware. Walled garden entries, captive portal strength, session timeouts and DNS rules are configuration changes on the controller you already run. The main direct cost is a publicly trusted certificate, where your controller hosts its own login page.

Purple Guest WiFi comes in three plans: Connect, Capture and Engage. Pricing depends on venue count and plan, so ask Purple for a quote against your property portfolio.

The return is every Android visitor who signs in rather than giving up. Each completed login is a connected guest, and on Capture and Engage it is also first-party data gathered through conscious-choice opt-ins. That data feeds WiFi analytics and the CRM and marketing platforms you already use. Purple's own data shows 440 million logins in 2024 across 80,000+ live venues. At that scale, a detection fault on one guest SSID is a measurable loss of connected visitors.

There is also a cost you avoid. Guests who see a certificate warning or a dead connection judge your venue, not their cell phone. For retail and hospitality brands, that first impression happens at the door.

If staff also need access alongside guests, run them on a separate SSID with identity-based authentication. Purple's blog post on How to Enable Single Sign On covers connecting Microsoft Entra ID, Okta and Google Workspace.

Frequently asked questions

Does Purple Guest WiFi work with the Cisco Meraki, HPE Aruba or Ubiquiti UniFi access points I already own?

Yes. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep your existing access points and controller. You point the guest SSID's captive portal at Purple's splash page, add the walled garden entries from Purple's support article, and set Purple's RADIUS server for authentication. No rip and replace is required.

Does Android Private DNS break captive portals?

It can, in Strict mode. In Automatic mode, Android falls back to the network's own DNS, and the portal loads normally. In Strict mode with a named provider hostname, the phone may be unable to resolve the splash page before sign-in, because that provider is unreachable until the guest authenticates. The fastest fix is for the guest to switch to Automatic, sign in, then switch back. Put that instruction on your signage.

Why do Android guests have to sign in again on every visit?

Usually because the phone presents a new randomized MAC address, or the session has expired. Android randomizes the MAC address per network, and forgetting the network or resetting settings produces a new one. Your session timeout also decides how long a login lasts. Set it to match the visit pattern, such as a full hotel stay rather than a single coffee. OpenRoaming offers automatic reconnection for returning visitors.

Do I need an SSL certificate for my captive portal?

Yes, for any login page your controller hosts itself. Modern browsers expect HTTPS for login pages and warn when they meet an unsecured HTTP link, which makes a sound network look unsafe. Purple's guidance for Cisco controllers is a publicly trusted certificate, with the virtual hostname matching the certificate's Common Name. Android's probe still uses HTTP, so interception continues to work.

Should my guest WiFi network be open or password protected?

Open, with a captive portal. Purple recommends providing guest WiFi over an open network because it is now the standard convention and reduces friction for visitors. Android and iPhone both detect a captive portal on an open SSID and prompt the guest to sign in. Keep guest traffic on its own VLAN. Run staff or resident access on a separate SSID with identity-based authentication.

Is data collected through the captive portal CCPA/CPRA compliant?

Yes. Purple is GDPR, CCPA, ISO 27001 and Cyber Essentials certified. The splash page uses conscious-choice opt-ins, so each guest decides what they share and whether they receive marketing. The data you gather is first-party data, collected with consent at the point of login. You still set your own privacy notice and retention policy, as with any personal data you control.

How long does it take to fix an Android captive portal problem?

Most fixes are a single configuration change on the guest SSID, followed by testing. Walled garden edits, captive portal strength, DNS rules and session timeouts need no new hardware. Budget most of your time for testing on at least three manufacturers' Android cell phones from a clean state. Some brands change how the login window behaves, and you want to find that before your visitors do.

Is the Android fix different from the iPhone captive portal fix?

Partly. The controller-side causes are the same on both platforms: walled garden scope, blocked DNS, HTTP redirects and session timeouts. The differences sit on the device. Android probes a Google-hosted endpoint, while iPhone probes an Apple one. Android also adds Private DNS behavior and manufacturer changes to the login window. Purple's companion iPhone captive portal guide covers the Apple side in detail.