iOS useIsHeadphonesConnected not detecting lightning device or wired adapter

[TheFe91]

Summary

Version	8.3.1
Affected OS	iOS
OS Version	14.7

Current behavior

Connecting a lightning jack-adapter or a lightning microphone won't trigger any event. The useIsHeadphonesConnected(); hook always returns {"loading": false, "result": false}

Expected behavior

Connecting a lightning jack-adapter or a lightning microphone should return true on the result field of useIsHeadphonesConnected();

DEVICE NOT CONNECTED

{"loading": false, "result": false} = useIsHeadphonesConnected()

DEVICE CONNECTED

{"loading": false, "result": true} = useIsHeadphonesConnected()

NOTE:

Bluetooth headset or AirPods instead work perfectly

[mikehardy]

Hi there! That's a shame, it would be great if the same native API was working for both. If you can find a system API for iOS that allows us to listen for changes in wired audio device status and provide a PR, we can merge it and release it sure

[schie]

Hello!

Since I wrote it, I can look into this.

I'm pretty sure that I tested this, maybe an API changed recently?

[schie]

Not directly related, but it does work w/ AirPods. Once, I'm able to find a pair of lightning EarPods, I'll check — They're around here somewhere....

[schie]

@mikehardy this seems to be related to the event listener stub jazz added in 8.3.1.

I was on 8.3.0 and it worked. After upgrading, it didn't.

[schie]

Do you know where the documentation is regarding addListener and removeListener ? I'd be happy to implement it to make sure everything's kosher.

[mikehardy]

Ah, dangit. That's frustrating, I didn't think adding those stubs would have that affect. Out of curiosity, did you update react-native at the same time? The emitter system in react-native changed completely between 0.64 and 0.65 - like, they actually stopped inheriting from a superclass and just behave totally differently. I was only able to forward port react-native-firebase by reading the old version (https://github.com/facebook/react-native/blob/0.64-stable/Libraries/EventEmitter/NativeEventEmitter.js vs https://github.com/facebook/react-native/blob/main/Libraries/EventEmitter/NativeEventEmitter.js) and checking the related PRs listed in the file history between them etc.

It was non-trivial 😩 https://github.com/invertase/react-native-firebase/pull/5616/files#diff-82b084457a12d227f6ce7e525327c3c094a80001c1f4e987086fb7ca0c582899

I did not think anything approaching that would be necessary here, and I wonder if it's a problem between the react-native versions even without the stub implementations, or if there is more needed then the stub or... I dunno.

That was the process though: personal inspection of PRs related to the react-native files then testing, and I'm "lucky" that react-native-firebase has a really good on-device e2e harness so I was pretty sure it was okay after the port

[schie]

I was testing on 0.64. This seems it could end up super squirrelly to handle if this breaks < 0.65 RN.

[mikehardy]

Yeah, in my patch to react-native-firebase I had to take some pains to handle RN64 and RN65 and I carefully tested on both. It was intellectually challenging, so it had some interest, but I wouldn't say it was fun...

[tak-hntlabs]

I'm seeing problems with useIsHeadphonesConnected after upgrading my project to RN 0.65. Now turning on / off my AirPods no longer update the states of useIsHeadphonesConnected. It always show the first read state. Searching for known issues brought me here. Seems like the same root cause with the emitter breaking changes.

[schie]

I'll try to get to this over the weekend, but if anyone wants to be a hero… lol

[schie]

Since < 0.64 'returns an object w/ .remove' and = 0.65 'returns a function to remove sub', we can just do the following or something similar, right?

# src/internal/asyncHookWrappers.ts

export function useOnEvent<T>(
  eventName: string,
  initialValueAsyncGetter: () => Promise<T>,
  defaultValue: T
): AsyncHookResult<T> {
  // ...
  useEffect(() => {
    const subscription = deviceInfoEmitter.addListener(eventName, setResult);
    return () => {
       // original:
       // subscription.remove();
       
       // suggested:
       subscription?.remove ? subscription.remove() : subscription();
    }
  }, [eventName]);

  // ...
}

Apologies for the delay; super busy.

[schie]

This issue is just related to the event-watching hooks that we made. I'm going to make a few sample projects (0.64 and 0.65) to test.

[mikehardy]

That seems sensible - and yes unfortunately testing back and forth is the only way to be sure. My first cut on react-native-firebase was not correct until I checked it on 0.64 and 0.65 back and forth to get it just right

Semi-related, this is apparently what microsoft is using to manage version skew testing, multiple kits with different versions supplied as config? I think? Apparently it works well https://github.com/microsoft/rnx-kit and also this is interesting but needs someone to contribute web: https://github.com/microsoft/react-native-test-app/

Those come from discussion on the releases/release-testers channels on react-native discord as we battle through making all this stuff run 😅 - it gives me hope that a lot of these things will have well-supported solutions soon though, and most problems (minus web in react-native-test-app) already seem pretty well handled

[schie]

I think I was confused about my original suggestion. From testing and looking at the source code for both 0.64 and 0.65 versions of react native, they both still use subscription.remove() to close the sub.

Simply removing the listener stubs in iOS did the trick.

[rndi-bot]

🎉 This issue has been resolved in version 8.4.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[Daveeeeeeeeee]

Hello, i seem to experience it again :( bluetooth devices works fine but the lightning headphones are not detected