useFunctionsEmulator doesn't work on real device

[cjam]

After quite a while trying to figure out why my android device couldn't connect to my functions emulator on local host I finally traced through the code and found this section:

react-native-firebase/packages/functions/lib/index.js

Lines 96 to 102 in decb6af

	if (isAndroid && _origin) {
	if (_origin.startsWith('http://localhost')) {
	_origin = _origin.replace('http://localhost', 'http://10.0.2.2');
	}
	if (_origin.startsWith('http://127.0.0.1')) {
	_origin = _origin.replace('http://127.0.0.1', 'http://10.0.2.2');
	}

Which will work great for emulators, but breaks real devices since 10.0.2.2 is only within emulators. So ideally, you only want to run this code if it is running within an Android Emulator. Otherwise, if on a physical device it should be left as localhost and reverse proxied via

adb reverse tcp:5001 tcp:5001

[mikehardy]

Hmmm we use this pattern in a lot of locations (and in other repos as well - FlutterFire). Will have to think about this one.

[cjam]

Sure thing. I'm definitely not an android expert, so perhaps my device is misconfigured? You guys are doing testing on actual devices or all emulators?

[mikehardy]

I think the expectation is that if you run it on a real device, you'll configure it for the IP of the actual machine hosting the emulator?

[mikehardy]

I personally am running emulators 99.9% of the time and supporting the same via E2E testing in CI. On Android especially since the only differences between emulator and real device is cloud messaging (which is normally not tested in any sort of automated way) there isn't much need to run against real devices until final checks before launch, for me

[mikehardy]

Related thought: even if we maintain the expectation that this mapping is acceptable and we expect real IP addresses for real devices, this obviously violates principle of least surprise and is hard to figure out. Code should log that we're remapping when it happens, and docs should mention it it as a minimum reaction to the issue

[cjam]

I have written/and am using a package (https://github.com/cjam/react-native-spotify-remote) that wraps the Spotify SDK's and requires being run on a device with spotify (hence why I can't use the emulator).

I was trying to follow the same pattern that was being used by the react native package (with the adb reverse) as it doesn't involve having to change environment variables for ip address etc and can be scripted into the development workflow easily.

I'm grabbing the packager HOST / PORT like this

import { NativeModules } from 'react-native';

const scriptURL = NativeModules.SourceCode.scriptURL;
const address = scriptURL.split('://')[1].split('/')[0];
const hostname = address.split(':')[0];
const port = address.split(':')[1];

export const PACKAGER_HOST = hostname;
export const PACKAGER_PORT = port;

Then using it within my firebase service wrapper like this:

constructor(){
        this._app = firebase.app();
        this._links = firebaseLinks();
        this._auth = firebaseAuth(this._app);
        this._functions = firebaseFunctions(this._app);

        if (__DEV__) {           
            // PACKAGER_HOST 
            // On iOS = Machine IP Address
            // on Android = localhost 
            // on Android Emulator = ??  (I suspect 10.0.2.2)
            this._db = this._app.database(`http://${PACKAGER_HOST}:9000?ns=${this._app.options.projectId}`);
            this._functions.useFunctionsEmulator(`http://${PACKAGER_HOST}:5001`);
        } 
       //....
}

So perhaps you're right, just passing the IP Address in an environment variable would work, I suspect this is likely why using the authEmulator wasn't working as well (for me).

[mikehardy]

docs have been updated and as of next release if the remapping happens, it will print to console that it happened and what to do if it is not what you want. Thanks for reporting this, sorry for the frustration - I imagine it was an unexpected surprise when you discovered it!

[cjam]

Thanks @mikehardy. I found a few things that morning. One was this behavior, and the other was a bug in the Firebase cli, so I suppose it's partially positive? 👍