androidhttphttps

Cleartext HTTP traffic to myserver.com not permitted on Android N preview


Yesterday I got a new upgrade for the Android N preview. Ever since I upgraded, I cannot start my app anymore.

java.io.IOException: Cleartext HTTP traffic to myserver.com not permitted

I have tried to set the usesCleartextTraffic to true in the manifest or to add a network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">myserver.com</domain>
    </domain-config>
</network-security-config>

Neither did work. Any ideas about what is going on there?

When I try to define networkSecurityConfig in the manifest, I get a compile error

Error:(35) No resource identifier found for attribute 'networkSecurityConfig' in package 'android'

Not really sure why. The file is there and everything looks good.

Found this suggestion in the Android issue tracker from Google. They suggest to move the network_security_config definition to the meta-data. I still get the same exception though.


Solution

  • There is a known issue in Android N Developer Preview 4 where, if an app modifies its ApplicationInfo.flags, it triggers the blocking of cleartext traffic from the app, even if the app didn't request cleartext traffic to be blocked. The fix is in the next Developer Preview. Thus, this has nothing to do with your Network Security Config. In fact, it looks like you don't even need to declare a custom Network Security Config.

    If you can't wait until the next Android N Developer Preview, check your app for places where it modifies its own ApplicationInfo.flags. Typically this takes the form of getApplicationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE or getApplicationInfo().flags = ApplicationInfo.FLAG_DEBUGGABLE. The fix for these usages is (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE).

    Alternatively, as a workaround, invoke NetworkSecurityPolicy.isCleartextTrafficPermitted() as early in your app's lifecycle as possible. This workaround should work if invoked before the code which tampers with ApplicationInfo.flags.