fix issue 1579

[Sonicizslow]

Changed how isEmoji detection works due to a change on the Android client.

What changed?

Change made to isEmoji detection from packet.decoded.emoji == 1 to packet.decoded.emoji != 0 within the MeshPackets file.

Why did it change?

Issue 1579
The android client changed how the handle sending emoji information, moving from using 0 as false, and 1 as true, to using the emoji ID. This resulted in tapbacks being sent from the android client to arrive on the iPhone as a new message.

How is this tested?

I removed the entitlements for critical message, carplay, associated domains, and weather kit so I could self sign and install on my iPad. I then tested messaging between apple, android, and web via hardware.

I did find that web does not seem to currently support tapback.

Screenshots/Videos (when applicable)

Checklist

• [ x] My code adheres to the project's coding and style guidelines.
• [x ] I have conducted a self-review of my code.
• [x ] I have commented my code, particularly in complex areas.
• [x ] I have verified whether these changes require an update to existing documentation or if new documentation is needed, and created an issue in the docs repo if applicable.
• [x ] I have tested the change to ensure that it works as intended.

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

Updates tapback (reaction) detection in the iOS message parser to align with newer Android behavior where decoded.emoji may contain an emoji ID (non-zero) rather than a strict boolean 1.

Changes:

• Treat any non-zero packet.decoded.emoji value as a tapback/reaction when creating MessageEntity instances.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[garthvh]

this is an android bug

[alecperkins]

Android says Apple is doing it wrong. meshtastic/Meshtastic-Android#4417

Edit: per discussion, Apple is correct and Android needs to fix.