Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not support local insecure connections on 'newer Android phones' #5

Open
DanMakingWithAI opened this issue Sep 20, 2024 · 2 comments

Comments

@DanMakingWithAI
Copy link

Crosspost from Discord

A bit of digging suggests that on newer Android phones, the 01 mobile app will refuse to connect to a local livekit server (such as the one exposed by the 01 python code) that is served over http rather than https. I had suspected this to be the cause of my app not connecting, and a logcat over adb confirms it - the app produces this in the log trace (after the token check passes)

09-20 23:38:40.653  5218  5273 W ReactNativeJS: 'websocket closed', { room: undefined,
09-20 23:38:40.653  5218  5273 W ReactNativeJS:   roomID: undefined,
09-20 23:38:40.653  5218  5273 W ReactNativeJS:   participant: undefined,
09-20 23:38:40.653  5218  5273 W ReactNativeJS:   pID: undefined,
09-20 23:38:40.653  5218  5273 W ReactNativeJS:   reason: 'CLEARTEXT communication to 192.168.1.159 not permitted by network security policy',
09-20 23:38:40.653  5218  5273 W ReactNativeJS:   code: 1006,
09-20 23:38:40.653  5218  5273 W ReactNativeJS:   wasClean: undefined,
09-20 23:38:40.653  5218  5273 W ReactNativeJS:   state: 4 }

Of course, using ngrok you get an https endpoint, so folks doing the --expose flag when starting the 01 server should not experience this.

I only say 'newer Android phones' because I searched the error line in Perplexity
: https://www.perplexity.ai/search/reactnaivejs-livekit-error-cle-WPS1IVDRQ56eacKjW0o8lg

That (re)search thread proposes fixes, if desired - enabling cleartext communication only for local networks and with a clear warning to users could be a reasonable idea. Or denying it and alerting on 'http' rather than 'https'. Or catching and relaying the warning etc. etc.

Alternatively, updating the documentation to say this won't work is fine, too. I have no particular opinion either way. 😊

@DanMakingWithAI
Copy link
Author

A bit more Perplexity searching suggests the reasonable fix might be to use the expo-network plugin and update the plugin section of the app.config.ts file to include the relevant section of this:

import { ExpoConfig } from 'expo/config';

const config: ExpoConfig = {
  // ... other configurations
  android: {
    // ... other Android-specific configurations
  },
  plugins: [
    [
      'expo-network',
      {
        'android': {
          'networkSecurityConfig': {
            'cleartextTrafficPermitted': false,
            'domains': [
              {
                'domain': '10.0.0.0/8',
                'cleartextTrafficPermitted': true
              },
              {
                'domain': '172.16.0.0/12',
                'cleartextTrafficPermitted': true
              },
              {
                'domain': '192.168.0.0/16',
                'cleartextTrafficPermitted': true
              }
            ]
          }
        }
      }
    ]
  ],
  // ... rest of your configuration
};

export default config;

Means little to me as I don't know Expo/React Native, but I get the IP address reasoning so hopefully this isn't too far off hte mark 😄

@KillianLucas
Copy link

This is so helpful, thank you so much @DanMakingWithAI!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants