Android Kitkat网络请求证书认证问题：谷歌是否强制添加开发服务器证书？

Great question! Let's break this down clearly—Google/Android hasn't implemented a direct mandate to add your dev server's certificate, but changes to default network security policies are almost certainly why your requests started failing recently, even though they worked in January.

What's Actually Happening? #

Android has been gradually tightening its default network security rules over recent versions, and two key factors are likely at play here:

1. Target SDK Version Updates
   If you upgraded your app's targetSdkVersion to Android 11 (API 30) or higher since January, the default network security config now strictly enforces certificate chain validation. Previously, with lower target SDKs, looser rules might have allowed your dev server's untrusted (e.g., self-signed) certificate to slip through.

2. System-Level Security Hardening
   Even if you didn't change your app's target SDK, recent Android OS updates (especially on newer devices) have strengthened the default trust store behavior. Self-signed certificates or certificates from untrusted CAs are no longer automatically trusted for app network requests.

Google's Core Security Mechanism: Network Security Config #

This isn't a "mandate to add your dev cert"—it's a mandate to use trusted certificates by default. Android's Network Security Config (introduced in Android 7.0) controls this behavior. By default:

• Apps targeting API 24+ don't trust user-installed certificates unless explicitly configured.
• Apps targeting API 30+ block plaintext HTTP entirely (unless allowed via config) and require full certificate chain validation for HTTPS requests.

If your dev server uses a self-signed certificate or one issued by an internal CA not in Android's default trust store, the system will reject the connection with that CertPathValidatorException error.

Why Did It Work in January? #

There are a few plausible reasons:

• Your app was targeting an older SDK version (pre-API 30) where default validation rules were less strict.
• Your test device was running an older Android version that hadn't received the latest security hardening updates.
• You might have had a temporary workaround (like a custom TrustManager) that was accidentally removed in a recent code change.

Quick Recap of Valid Solutions (Since You Found a Fix Already) #

For clarity, here are standard approaches to resolve this for development:

• Recommended long-term fix: Get your dev server a certificate from a publicly trusted CA (free options like Let's Encrypt work perfectly). This aligns with production requirements and avoids config hacks.
• For local development: Add your dev server's certificate to your app's network security config:
  1. Place your cert file (e.g., dev_cert.pem) in res/raw/.
  2. Create res/xml/network_security_config.xml with:

     <?xml version="1.0" encoding="utf-8"?>
     <network-security-config>
         <domain-config includeSubdomains="true">
             <domain>your-dev-server-domain.com</domain>
             <trust-anchors>
                 <certificates src="@raw/dev_cert"/>
                 <certificates src="system"/>
             </trust-anchors>
         </domain-config>
     </network-security-config>
     

  3. Link the config in your AndroidManifest.xml under the <application> tag:

     android:networkSecurityConfig="@xml/network_security_config"
     

• Never use in production: Temporarily disable certificate validation (via a custom TrustManager in your HTTP client like OkHttp). This skips all security checks and exposes your app to man-in-the-middle attacks.

内容的提问来源于stack exchange，提问作者David