Android Proxy Setup

A practical, field-tested guide to configuring HTTP, HTTPS, and SOCKS5 proxies on Android devices. Covers Wi-Fi-level setup, APN-level setup for cellular data, ADB-based system-wide configuration, and app-level routing for developers building Android apps that need to make requests through a proxy.

This repo exists because most of the Android proxy guides online stop at "Settings, long-press Wi-Fi, tap Modify, switch Proxy to Manual." That works for half the cases. The other half, you need APN routing, or system-wide configuration via ADB, or code-level proxy handling inside an app you're building, and the guidance gets thin fast.

Everything here has been tested on Android 12, 13, 14, and 15. Where behavior differs across versions, I've noted it. The provider-specific examples assume you're using Proxy-Cheap, which is what I've used for the last year on Android testing projects. The setup workflow described matches their actual dashboard and Credentials Generator flow.

Who this is for
Quick start
What an Android proxy actually does
Method 1: Wi-Fi proxy (per-network, no root)
Method 2: APN proxy (mobile data)
Method 3: System-wide proxy via ADB
Method 4: App-level proxy (OkHttp, native code)
Getting your credentials from Proxy-Cheap
Authentication: user/pass vs IP whitelist
Protocol support across Proxy-Cheap products
Random IP vs Session IP: picking the right mode
Testing your setup
Picking a Proxy-Cheap product for your Android workflow
Common issues and fixes
Further reading
FAQ

Who this is for

Three audiences I had in mind when writing this:

QA and mobile test engineers routing traffic from real devices or emulators through proxies to inspect requests, verify regional behavior, or test against staging environments.
Mobile developers writing Android apps that need to make HTTP calls through a configurable proxy (corporate networks, debugging, API integrations that require routing).
Power users and operators who run automation, market research, or social media account management from Android devices and want stable IP routing.

If you're trying to configure a proxy through your work or school's IT department, this isn't really for you. The configuration steps below assume you control the device.

Quick start

If you just need the three-line version:

Open Settings → Network & internet → Internet (or Wi-Fi on older versions).
Long-press your active network, tap Modify, expand Advanced options, set Proxy to Manual.
Enter the proxy hostname (or IP) and port, save.

That covers Wi-Fi-level HTTP proxy routing on stock Android. If you need authentication, SOCKS5, APN routing, or system-wide setup, keep reading. If you don't have credentials yet, skip to Getting your credentials from Proxy-Cheap first.

What an Android proxy actually does

A proxy sits between your Android device and the destination server. Your device sends its HTTP request to the proxy, the proxy makes the request on your behalf, then forwards the response back. From the destination's perspective, the request originated from the proxy's IP, not yours.

A few practical implications worth knowing before you start configuring anything:

Android's built-in proxy settings only handle HTTP/HTTPS. They do not natively route SOCKS5 traffic at the OS level. SOCKS5 requires either ADB-based configuration, app-level handling, or a third-party tool.
The OS-level proxy applies to most apps, but not all of them. Some apps make raw socket connections that ignore system proxy settings entirely. This catches people out. If you're routing traffic through a proxy and one specific app's traffic isn't going through, that's why.
APN-level proxies route mobile data, Wi-Fi-level proxies route Wi-Fi. They are independent. Setting one does not set the other.

Method 1: Wi-Fi proxy (per-network, no root)

This is the most common setup. Works on every modern Android version, no root required, takes about 30 seconds. The proxy setting is per-network, meaning each Wi-Fi network you connect to has its own proxy config.

Steps (Android 12 through 15)

Open Settings.
Tap Network & internet (Android 12+) or Connections on Samsung devices.
Tap Internet or Wi-Fi.
Long-press the network you're connected to. On Android 13+, you may need to tap the gear icon next to the network instead.
Tap Modify or Edit in the menu.
Expand Advanced options.
Set Proxy to Manual.
Fill in:
- Proxy hostname: the IP or domain of your proxy server (from your provider's dashboard).
- Proxy port: the port number (from your provider's dashboard).
- "Bypass proxy for": the Android UI's literal label for the exclusion list field. Optional list of domains that should connect directly. Useful for local network resources.
Tap Save.

The credentials problem (and the fix)

Android's stock Wi-Fi proxy config has no username or password field. The hostname and port are all you can enter through the GUI. This is the single most common source of frustration when setting up a paid proxy on Android Wi-Fi, because most paid providers default to username/password authentication.

The practical fix for Proxy-Cheap users: switch your proxy authentication to IP whitelisting instead of username/password. In the Proxy-Cheap dashboard you can register your device's outbound IP, and once whitelisted, no credentials are needed in the Android config. The full procedure is documented in the Proxy-Cheap support knowledge base.

This works well for stationary setups (a test phone on a fixed office Wi-Fi, an emulator on a desktop) and less well for setups where your outbound IP changes often (testing on cellular data from various locations). For changing-IP scenarios, you're better off using app-level routing per Method 4 where credentials are handled in code.

What this method doesn't cover

Mobile data. This setting only applies when you're on this specific Wi-Fi network.
SOCKS5. Wi-Fi proxy config is HTTP only.

PAC URLs

The same screen has a Proxy Auto-Config option where you can paste a .pac file URL. This works if your proxy provider supplies one. Most don't, but some corporate proxy setups use PAC files for routing rules.

Method 2: APN proxy (mobile data)

If you need proxy routing to apply when the device is on cellular data, you configure it at the APN level. This is less commonly needed but essential for some testing and automation scenarios.

Steps

Open Settings → Network & internet → SIMs.
Tap your active SIM.
Tap Access Point Names (sometimes nested under Advanced).
Tap the + icon to create a new APN, or tap your existing carrier APN to modify it.
Find the Proxy and Port fields.
Enter the proxy hostname and port.
Save the APN. Set it as active if you created a new one.

Gotchas

Many carriers lock APN settings. If the fields are greyed out, you can't change them without unlocking the device's carrier configuration, which often requires a different SIM or carrier intervention.
APN changes can break your data connection until you reboot or toggle airplane mode.
This routes all cellular HTTP traffic through the proxy. If you only want some apps proxied, this is the wrong method. Use Method 4 instead.

Method 3: System-wide proxy via ADB

For developers and testers, ADB-based proxy configuration is more flexible than the GUI methods and supports authentication out of the box on newer Android versions.

Prerequisites

USB debugging enabled on the device (Settings → System → Developer options → USB debugging).
ADB installed on your computer. If you have Android Studio, you already have it; otherwise, install platform-tools from developer.android.com.

Set an HTTP proxy via ADB

Replace <your-hostname> and <your-port> with the values from your Credentials Generator output (see the next section on where to find these).

adb shell settings put global http_proxy <your-hostname>:<your-port>

To remove it:

adb shell settings put global http_proxy :0

Set proxy with hostname, port, and exclusion list

adb shell settings put global global_http_proxy_host <your-hostname>
adb shell settings put global global_http_proxy_port <your-port>
adb shell settings put global global_http_proxy_exclusion_list "localhost,127.0.0.1,*.local"

Set proxy with username and password (Android 11+)

adb shell settings put global global_http_proxy_username <your-username>
adb shell settings put global global_http_proxy_password <your-password>

These credential keys are honored by AOSP from Android 11 onward. Older versions ignore them, and you need a per-app solution instead.

For Proxy-Cheap users on rotating residential, the username field is also where the session ID parameter lives, which controls whether you get a fresh IP every request or a sticky session. See Random IP vs Session IP for the mechanics.

I've included a working shell script that wraps these commands and handles cleanup at examples/adb-system-proxy.sh.

Verify the proxy is set

adb shell settings get global http_proxy

This should echo the host:port string you set. If it returns :0 or null, the setting didn't apply.

Reboot persistence

The settings put global configuration survives reboots. To clear it programmatically:

adb shell settings put global http_proxy :0
adb shell settings delete global global_http_proxy_host
adb shell settings delete global global_http_proxy_port
adb shell settings delete global global_http_proxy_username
adb shell settings delete global global_http_proxy_password

Method 4: App-level proxy (OkHttp, native code)

If you're building an Android app and need to route HTTP traffic through a proxy from your own code, you handle this at the HTTP client level rather than at the OS level. This is the most flexible approach and works regardless of whether the user has configured anything in their system settings.

For OkHttp (the most common HTTP client on Android), the configuration looks like this:

val proxy = Proxy(
    Proxy.Type.HTTP,
    InetSocketAddress("<your-hostname>", <your-port>)
)

val client = OkHttpClient.Builder()
    .proxy(proxy)
    .proxyAuthenticator { _, response ->
        val credential = Credentials.basic("<your-username>", "<your-password>")
        response.request.newBuilder()
            .header("Proxy-Authorization", credential)
            .build()
    }
    .build()

For SOCKS5 instead of HTTP, swap Proxy.Type.HTTP for Proxy.Type.SOCKS. SOCKS authentication in OkHttp is messier than HTTP basic auth and often requires a custom Authenticator chain. I've included a full working example with HTTP and SOCKS5, with and without auth, plus a rotating-residential session ID pattern at examples/okhttp-proxy-client.kt.

For Retrofit, you wrap the same configured OkHttpClient and pass it to the Retrofit builder. No additional Retrofit-specific configuration is needed.

For raw Java HttpURLConnection, you set proxy settings via system properties before opening the connection:

System.setProperty("http.proxyHost", "<your-hostname>")
System.setProperty("http.proxyPort", "<your-port>")
System.setProperty("https.proxyHost", "<your-hostname>")
System.setProperty("https.proxyPort", "<your-port>")

This approach is global to the JVM process and applies to any connection made via HttpURLConnection afterward.

Getting your credentials from Proxy-Cheap

The placeholder values above (<your-hostname>, <your-port>, <your-username>, <your-password>) come from Proxy-Cheap's Credentials Generator, which you access from the dashboard after purchasing a proxy product. The workflow is the same across their product line and worth walking through once because it determines what values you'll be plugging into Methods 1 through 4.

Step by step

Log in at app.proxy-cheap.com.
From the proxy overview window, click on the proxy product you purchased.
Press the Setup Credentials button. This opens the Credentials Generator.
In the generator window, configure:
- Country. Pick the country you want your outbound IP to appear from. Some products also let you target by zip code or city.
- Session type. Random IP (changes every request) or Session IP (sticky for around 30 minutes). More on this in the next section.
- Hostname type. Some products give you a choice between DNS hostname and direct IP.
- Credentials count. Only relevant for Session IP, lets you generate multiple sticky-session credentials at once.
The right side of the window shows your generated connection details: hostname, port, username, password.
Use the copy buttons to grab each value, then plug them into whichever Android setup method you're using.

This procedure is documented in detail in the Proxy-Cheap rotating residential tutorial, and there's a separate article specifically explaining how the Credentials Generator works under the hood, including why the same username and password appears across multiple generated entries (the session ID parameter is what varies, not the user/pass).

What to expect from the values

A few quirks worth knowing before you start plugging values into things:

Rotating residential proxies use a shared IP pool. That means the hostname and port displayed in the generator are the same across all credentials and across all users on that product. The IP your destination sees is selected from the pool at connection time, not encoded in the hostname.
For Session IP mode, the same hostname/port/username/password applies to every credential row, but the underlying connection routes to a different sticky IP. The Credentials Generator handles the per-row uniqueness internally.
Manual or custom IP rotation is not supported. The only rotation controls are the Random IP and Session IP toggles in the generator. If you need per-request control beyond that, you'd build it at the application layer.

Authentication: user/pass vs IP whitelist

Most production-grade proxy services require authentication. Proxy-Cheap supports two methods, and the right choice depends on which Android method you're using.

Method	Auth support
Wi-Fi proxy (GUI)	No native credential fields. Use IP whitelisting instead, or use Method 4.
APN proxy	Carrier-dependent. Most APN configs have no auth fields. IP whitelisting is the workaround.
ADB system-wide	Username/password supported on Android 11+ via the `global_http_proxy_username` and `_password` keys.
App-level (OkHttp, etc.)	Full support, including HTTP Basic, custom authenticators, and SOCKS5 user/pass.

Username/password

This is the default for most Proxy-Cheap products. Credentials come from the Credentials Generator and travel in the Proxy-Authorization header on each request (HTTP Basic). All four Android methods can use this except Method 1 (Wi-Fi GUI) and most APN configurations, which have no credentials fields.

IP whitelist

The alternative. Register your device's outbound IP in the Proxy-Cheap dashboard, and once whitelisted, no per-request credentials are needed. This is the practical answer to "how do I get auth working on Wi-Fi when Android has no credentials field" without resorting to a third-party app. Registration is per-IP, so the technique works best when the device's outbound IP is stable (fixed office Wi-Fi, residential home network, emulator on a server). For setups where the IP changes often, stick with username/password and Method 4.

Tradeoff worth knowing

The Proxy-Cheap Chrome extension (Proxy Manager) supports username/password auth but does not work with IP-whitelisted proxies or with SOCKS5 (because Chromium-based browsers don't support SOCKS5 natively). If you're using the extension on a desktop for parallel testing alongside your Android setup, this is a gotcha to keep in mind.

Protocol support across Proxy-Cheap products

Not every Proxy-Cheap product supports every protocol. This matters when you're choosing between SOCKS5 and HTTP for app-level routing in Method 4, because not all of their products will give you a SOCKS5 endpoint.

Product	HTTP/HTTPS	SOCKS5
Static residential	Yes	Yes
Rotating residential	Yes	No (HTTP only)
Datacenter (IPv4 and IPv6)	Yes	Yes
ISP	Yes	Yes
Mobile (rotating and static)	Yes	Yes
Dedicated SOCKS5 proxies	Yes	Yes

The big surprise is that rotating residential is HTTP only, confirmed in their support FAQ. If you specifically need SOCKS5 with rotation, your options are: use static residential with the dashboard-configurable rotation interval (5 to 30 minutes), use mobile proxies (rotating + SOCKS5), or use their dedicated SOCKS5 product line.

Notes on protocol behavior

HTTP proxy. Android's native system proxy. Works through Wi-Fi config, APN config, and ADB. The default choice for most setups.
HTTPS proxy. Functionally similar to HTTP proxy from a client perspective. The connection between your device and the proxy is itself encrypted. Useful when you don't trust the network between you and the proxy server.
SOCKS5. Not natively supported by Android's system proxy settings. You can route SOCKS5 either via ADB-set system properties (limited app coverage), through app-level configuration in OkHttp (works reliably), or via a SOCKS5-to-HTTP bridge app.

A subtle thing about SOCKS5 worth knowing: SOCKS5 and SOCKS5h resolve DNS differently. SOCKS5 resolves the destination hostname locally on the device before sending to the proxy. SOCKS5h sends the hostname unresolved and lets the proxy resolve it. If you want the proxy to handle DNS, use SOCKS5h. In curl this is the --socks5-hostname flag.

Random IP vs Session IP: picking the right mode

When you generate credentials for rotating residential, you pick a session type. This is the choice that most affects Android testing workflows because it determines whether your IP changes mid-test or stays put.

Random IP

The IP changes on every request or every connection refresh. Useful for:

Web scraping with high request volume where you want maximum IP diversity.
Distributing load across many IPs to avoid rate limits on a single one.
Testing that your app correctly handles changing outbound IPs (rare requirement).

Not useful for most app testing, because most mobile test scenarios involve a multi-step flow (login, navigate, submit) where the destination expects the same IP across the session. Random IP will break those flows.

Session IP

Sticky for around 30 minutes. After the 30-minute window, the session can disconnect at any time and a new IP is assigned on the next connection. Useful for:

Mobile app QA testing where a single test run takes 5 to 20 minutes and needs a consistent IP throughout.
Manual exploration of an app's regional behavior over a short session.
Social media account testing where the destination expects session continuity.

This is the right default for almost all Android testing work. The 30-minute window is a hard cap, not a guarantee, so build your test runs to complete well inside it.

A note on duration

Custom session duration beyond the ~30-minute default is not supported on rotating residential. If you need longer sticky sessions (like multi-hour automation runs), the right product is static residential where the IP doesn't rotate at all, or one of the static IP products. Rotation interval on static residential can be customized between 5 and 30 minutes if you want some rotation but with stability inside the window.

Testing your setup

After configuring a proxy, you want to verify two things: requests are routing through the proxy, and the destination server sees the proxy's IP, not your device's IP.

Quick visual test

Open Chrome (or any browser) on the device and visit an IP echo service. A few options:

https://api.ipify.org
https://ifconfig.me/ip
https://httpbin.org/ip

If the IP shown matches the proxy's IP rather than your device's actual outbound IP, the proxy is working.

Testing with Termux (no root needed)

Termux gives you a Linux shell on Android with curl and most standard tools. Useful for testing specifically and verifying response headers.

# Without proxy (your device's real IP)
curl https://api.ipify.org

# Through HTTP proxy with auth
curl -x http://<your-username>:<your-password>@<your-hostname>:<your-port> https://api.ipify.org

# Through SOCKS5 with DNS at proxy
curl --socks5-hostname <your-username>:<your-password>@<your-hostname>:<your-port> https://api.ipify.org

Compare the IPs returned. If they differ as expected, you're good.

Common verification failure

If your test returns your real IP even though the proxy is configured, the most common causes are:

The app you're testing through doesn't honor system proxy settings. Chrome does. Some apps don't. Try a different app, or use Method 4 to route at the application level.
The destination uses certificate pinning that's rejecting the proxy connection. The request silently falls through to a direct connection. You'll see this in app logs, not in the browser.
The proxy itself is misconfigured. Test the same proxy from a desktop with curl first to isolate the issue.

Picking a Proxy-Cheap product for your Android workflow

There's enough overlap in the product line that picking can take a minute. Here's the decision tree I use for Android-specific work.

Use static residential when:

You need a stable IP for multi-day or multi-week QA work
You want IP whitelisting to work cleanly (the IP doesn't rotate, so your destination's anti-abuse doesn't see address churn)
You need SOCKS5 with stability (rotating residential doesn't support SOCKS5)
The setup is a fixed phone or emulator that stays on the same project for a long stretch

Use rotating residential when:

You're doing scraping work from an emulator at scale
You need IP diversity more than session stability
You're okay with HTTP only (no SOCKS5 here)
The 30-minute Session IP window fits your test run lengths

Use ISP proxies when:

You need datacenter-grade speed but want the trust signal of a residential ASN
The destination is sensitive to ASN, like social media platforms
You want SOCKS5 with a static IP at higher bandwidth than residential

Use datacenter proxies (IPv4 or IPv6) when:

You need cheap, high-throughput requests
The destination isn't going to inspect ASN or block datacenter ranges
This is bulk testing or load testing where cost per GB matters more than IP quality

Use mobile proxies when:

You specifically need traffic to look like it's coming from a real mobile carrier (4G/5G ASN)
You're testing app behavior that detects carrier networks
You're managing accounts on platforms that trust mobile IPs more than residential ones (Instagram is the canonical example)
You're okay with slower speeds in exchange for the carrier IP

Pricing details for all of these are on the services page. Pay-as-you-go works for most projects since you're not locked into monthly minimums.

For automating proxy provisioning

If you're managing more than a handful of proxies as part of a CI pipeline or test infrastructure, Proxy-Cheap exposes a REST API at docs.proxy-cheap.com for ordering, listing, and managing proxies programmatically. There's also an official Node.js SDK using the standard Client(API_KEY, API_SECRET) pattern.

Common issues and fixes

"Couldn't connect" after setting proxy

The proxy is configured but Android can't reach it. Check:

Is the proxy server actually reachable from outside? Test with curl from a desktop first.
Are you on a network that allows outbound connections to the proxy port? Some Wi-Fi networks block non-standard ports.
Did you typo the hostname? Trailing slashes, "http://" prefixes in the hostname field, and similar small errors break the config silently.

Proxy works in Chrome but not in app X

System proxy honors mostly, but not all apps respect it. The fix depends on the app:

If you can configure a proxy inside the app's own settings, do that.
If the app uses OkHttp or similar, you can sometimes set system properties via ADB that get picked up.
For apps that ignore everything, the only real option is a VPN-based proxy bridge that intercepts at a lower level. ProxyDroid (root required) and SocksDroid are the usual recommendations.

Certificate errors after enabling proxy

If the proxy is doing TLS inspection (some corporate proxies do this), Android will reject the inspected certificate by default. The fix is to install the proxy's root CA into Android's user certificate store: Settings → Security → Encryption & credentials → Install a certificate. Note that Android distinguishes user-installed CAs from system CAs, and many apps don't trust user CAs by default. This usually only matters in corporate or testing environments. Proxy-Cheap doesn't do TLS inspection on their managed products, so you shouldn't hit this with their setup.

Network may be monitored warning

Android shows this warning whenever a system proxy is configured. It's informational, not an error. You can ignore it if you set up the proxy yourself.

Proxy works on Wi-Fi but not on mobile data

Wi-Fi proxy config and APN proxy config are independent. Setting one does not set the other. Configure each separately per Method 1 and Method 2.

407 Proxy Authentication Required

The proxy server is rejecting your credentials. Three common causes:

Username or password mismatch. Regenerate credentials from the Credentials Generator and try again.
You're using a username/password from one product on a different product (each purchase has its own credentials).
The Wi-Fi method can't send credentials at all. Either switch to IP whitelist auth, or use Method 3 or Method 4.

FAQ

Does Android support SOCKS5 proxies natively?

Not at the OS level through the standard Wi-Fi or APN settings. The native system proxy is HTTP/HTTPS only. SOCKS5 needs either app-level configuration in your HTTP client, ADB-based system property routing (which has mixed app coverage), or a third-party proxy app.

Do I need root to set up a proxy on Android?

No. Wi-Fi proxy configuration, APN configuration, ADB-based system settings, and app-level routing all work without root. Root is only needed if you want to install certain third-party proxy management apps that operate at the firewall level, or if you want to install a system-level certificate that all apps trust.

Why doesn't my app respect the system proxy?

Some Android apps make raw socket connections that ignore system proxy settings. This is up to the app's developers. The fix is either to configure the proxy inside the app itself (if it supports that), or to use a lower-level interception method like a VPN-based proxy bridge.

Can I set different proxies for different apps?

Not with the built-in Android proxy settings, which apply globally. For per-app routing, you need either an app-level proxy that you configure inside each app, or a VPN-based proxy app that supports per-app routing (some do, like NetGuard combined with a proxy backend).

How do I authenticate with a proxy that requires username and password?

On Android 11 and newer, you can set credentials via ADB system properties (see Method 3). For app-level routing, all major HTTP clients support proxy authentication in their builder configuration (see Method 4). For Wi-Fi-level configuration without ADB, Android doesn't expose authentication fields, so you either need IP whitelisting on the provider side or a third-party app.

Why does the same username and password show up across multiple credentials in the Generator?

This is intentional for rotating residential. The Credentials Generator produces multiple connection strings that share the same username and password, but encode different session IDs internally. Each string routes to a different sticky IP from the pool. The official explanation is in this support article.

Can I manually pick which IP to use from the rotating pool?

No. Custom or manual IP rotation isn't supported on rotating residential. You only have the two session modes (Random IP, Session IP) and the country selector. If you need a specific named IP, use static residential or ISP proxies instead, where the IP is fixed when you provision.

Does setting a proxy affect battery life?

Marginally. There's a small CPU and network overhead from routing through an intermediate server, but it's not significant enough to notice in normal use. Heavy traffic through slow proxies can warm the device and drain battery faster than direct connections, but for typical use you won't see a meaningful difference.

Can I use a free public proxy from a list?

You can, but I wouldn't for anything serious. Public free proxy lists have three persistent problems: most of the proxies are offline within hours, the operators of the live ones often log or modify traffic, and they're shared by thousands of users which causes the IP to get rate-limited or flagged on common destinations. For one-off testing it's fine. For anything where reliability or session stability matters, a paid provider is the practical choice.

Will my carrier or ISP see what I'm doing through a proxy?

They see encrypted traffic to the proxy server, but they don't see the contents of HTTPS requests beyond the proxy hostname. They also see the volume and timing of your traffic. A proxy is not a privacy tool in the way a VPN is; it's a routing tool. If privacy from your carrier is the goal, a VPN is the right answer, not a proxy.

What's the difference between a proxy and a VPN on Android?

A proxy routes HTTP traffic from apps that honor the system proxy setting. A VPN routes all traffic from the device, regardless of the app, at the IP layer. VPNs are more comprehensive but slower and less granular. Proxies are faster and more selective but only cover apps that respect proxy settings. For most testing and automation use cases, a proxy is the right tool. For privacy from your ISP, a VPN is.

Disclaimer: this is a personal documentation repo, not an official Proxy-Cheap project. Configuration steps tested on stock Android 12, 13, 14, and 15 on Pixel devices and Samsung Galaxy S22/S23. Behavior on heavily-skinned OEM versions may differ, especially around the Settings menu paths in Method 1 and Method 2. Provider-specific information reflects Proxy-Cheap's documented workflow as of the latest dashboard state; if their UI or product features change, the support knowledge base is the source of truth.

Contributions welcome via PR. Issues for setup problems you've hit on specific Android versions or specific OEMs are especially useful, the more configurations documented the better.

Name		Name	Last commit message	Last commit date
Latest commit History 4 Commits
README.md		README.md

Folders and files

Latest commit

History

Repository files navigation