Add Fire OS compatibility

[mosesroth]

📝 Why & how

This PR adds Fire OS compatibility as an option to the directory and includes 45 libraries that have been tested and confirmed compatible with Fire OS.

✅ Checklist

• Added library to react-native-libraries.json
• Updated library in react-native-libraries.json

• Documented in this PR how to use the feature or replicate the bug.
• Documented in this PR how you fixed or created the feature.

[mosesroth]

Co-authored with @chris-trag and @giolaq

[chris-trag]

Screenshots showing the Fire OS platform filter / checkbox:

Thanks!

[mosesroth]

Inserted ⏎ per warning

[Simek]

Hey @mosesroth, thanks for working on this addition! I would like to ask few questions before we can proceed.

About which Fire OS we are talking about, is it the Android TV fork?

• https://developer.amazon.com/docs/fire-tv/fire-os-overview.html

Or this is about the new, proprietary Linux-based OS announced earlier this year?

[mosesroth]

Hi @Simek , yes Fire OS is the Android fork mentioned on the doc you linked, which is what we tested on.

Thanks,

Moses

[Simek]

Thanks for the clarification Moses! 👍

We were discussing this addition internally, and with react-native-tvos maintainer, and in case of the Android fork we lean into thinking that the separation (definition of FireOS as a separate platform) is not needed.

AFAIK when it comes to Android TV, all libraries marked with Android or tvOS support should be working fine on Android TV (so also on Fire OS) devices, since most of the code is shared with Android mobile platform. You can check the RN tvOS readme for a bit more details on that topic:

• https://github.com/react-native-tvos/react-native-tvos?tab=readme-ov-file#react-native-tvos

This is also a take that the Fire OS page I have linked previously stand by:

Fire OS is a fork of Android, so if your app runs on Android, it will most likely run on Amazon's Fire devices too.

If there are something that we miss, any concerns about compatibility or important differences between regular Android TV and Fire OS please let us know. We are happy to learn more about TV apps ecosystem, and work on clarifying the state of libraries support for different TV targets.

[mosesroth]

Hi @Simek , Fire OS runs on Fire tablets too, not just Fire TVs.

It is based on Android, but there can be some inconsistencies, not all Android libraries will work on FOS. For example, if a library requires Google Play Services, it won't work on FOS, because those aren't present on Fire devices.

[chris-trag]

Hey @Simek,

To add to @mosesroth points -- we took on the effort of testing each of these libraries because developers have asked for confirmation of Fire OS support: For both Fire TVs and Fire Tablets. It's an oversimplification to say Android == Fire OS since the core issues come with monetization and auth built-in support.

Google Play Services and Login with Google are propriety and not part of the Android Open Source Project. Any app that tries to load an library with dependencies beyond Google Play are running into functional testing issues and app submission challenges on multiple devices -- which is why we pulled this PR together.

Our original plan was to create a directory showing each library and confirming Fire OS compatibility but were encouraged by MSFT and META teams to aim for reactnative.directory as a single source of truth that developers can go to - whether it's a core platform or an out-of-tree extended offering.

I doubt the Expo Go directory filter received this degree of pushback so would ask you and your Expo colleagues to be impartial stewards of this shared directory. We represent one of many device ecosystem supporters that are investing time and effort to make sure React Native devs have clarity on which libraries they can use for specific devices.

[Simek]

Hey @chris-trag,

Introducing an additional platform to the directory happens really rarely, and usually it's a string-forward case due to how obvious are differences between, or limitations on certain platform. It was not obvious in this case, since no context has been provided in the initial PR comment about reasoning behind, or the FireOS itself, and why it requires a separated categorization in the directory, hence my follow up questions.

There are also different core contributors of this project, and other people from the React Native community whom I have asked about this topic which seems to lean more towards lack of separation. It also have been stated on the FireOS website that the system should be basically threaded as an Android. Based on that, I have proposed a solution, but still was open to further discussion which last paragraph shows.

After getting bit more familiar with Android Open Source Project ecosystem it looks like to avoid the further fragmentation it would be ideal to use generic "AOSP" flag instead since there are several more AOSP-based OSes, besides FireOS, from different brands or manufacturers (https://en.wikipedia.org/wiki/List_of_custom_Android_distributions), and having a separate platform defined for every one of those distributions definitively feels like too many. If we separate-out one of the distributions, we should then treat the others similar, so this suggestion is more futureproof based.

An another approach might be introduction of Google Play Services field which would enhance existing "Android" tag with a tooltip, which will show if Google Play Services are required/needed or not. The similar feature we have for the New Architecture notes. It could also become one of the misc filters we already offer.

I wonder what are your thoughts on that, and "AOSP" flag idea?

If you feel strongly about retaining the separation would be great if you can provide more information on how FireOS differs from other distributions, and why there might be compatibility difference between certain AOSP OSes. I'm happy to learn more about that, since it might be easier to justify the separation, and more information can help up better asses the FireOS support claims on new entries.

Thanks for posting a bit more information, context, and your opinion. Hope we were able to find a solution which works for both invested parties, and it's more clear now what are the concerns from the directory side.

---

To clarify few misconceptions:

• React Native Directory is a community-based project, most of us work on it in our own free time, maintenance and new entries verification take time and effort, introducing new out-of-tree platform adds more work on all sides: package developers, contributors and directory maintainers. We already have in place rule that adding an out-of-tree platform support flag requires an example specifically dedicated for that platform, or reference to an existing open source project using it. Otherwise, it's up to reviewer or contributor to verify or confirm in some way the claimed platforms support.

• We try to achieve the balance between information granularity and the effort needed to maintain the data, since the most impressive list or directory won't be worth much, if it get outdated after a month or two. We would love to have the native platforms version range compatibility, browsers compatibility for web packages, and many other metadata but without an automation, or a respected standard how the data can be defined by library authors (in package.json for example) we would end up with a lot on manual, maintenance work which will grow each time new entry has been added. So it is also "by design", every data set extension need to be discussed/questioned.

• Expo Go was the initial reason why this directory came to fruition due to vast incompatibility it has at that time (+8 years ago), a lot has changed since then, and Directory pivoted more towards the registry of React Native libraries, to better suits the community needs. We were considering dropping "Expo Go" platforms since it's more a sandbox/starter, than a production-ready environment, but the community survey we have made showed us that majority of user don't want it gone.

• There are multiple people from different companies, including Meta, who have an administrator access to this repository. The code is fully open source and forkable with a general-purpose license, we have a communication channel for all the React Native partners and core contributors, and we always try to be as transparent and open to feedback as it is possible. The fact is that most of contributors works for, or was working at Expo at some time of their careers, but it does not mean that
  company is responsible for or forces any of the decision made by directory contributors.

[brentvatne]

I doubt the Expo Go directory filter received this degree of pushback so would ask you and your Expo colleagues to be impartial stewards of this shared directory.

I really don't like what you are implying here, @chris-trag. I think it's pretty rude to drop in to an established community and make a demand, then cast doubt on the intentions of the people who have been working on it for many years when they ask questions about it. @Simek is trying to ensure that what we are doing here is best for this site in the long run, and for the maintenance that he does in his spare time.

While Expo created the directory, as @Simek mentioned above, we also transferred it to the React Native Community organization with the intention to have shared stewardship - it just so happens that @Simek has been the main person to take responsibility for it.

[chris-trag]

@Simek thanks for the thoughtful response and I see & appreciate your points @brentvatne -- candidly after the time and effort we put into manually reviewing 50-100 libraries we’re bummed to get blocked at this stage. @Simek it’s incredible the sheer amount of work you’ve put into this project — Thanks for you all you do!

Truthfully I’m open to a compromise that lets your team feel good about the outcome and helps us avoid creating an entirely separate directory for the same information -- I think a single place of truth for react native compatibility across the ecosystem is a shared benefit and we’d love to contribute to regularly and actively test new libraries so the directory info stays fresh.

We’ve had a lot of developers confused by not knowing which libraries work with Amazon devices versus Apple or Google Play. If we were to re-work this PR, would you be open to the following changes (?) :

1. We’ll remove the Fire OS logo from the footer
2. Leave just the checkbox for Fire Devices so we can link from our docs and repo’s to a filtered list of vetted libraries that work across Fire TVs and Fire Tablets

Let me know what you think? Thanks!

[brentvatne]

Hello!

Thanks for the info, here's what I'm thinking:

Fire OS is the operating system that runs Amazon's Fire TV and tablets. Fire OS is a fork of Android, so if your app runs on Android, it will most likely run on Amazon's Fire devices too. (Source)

You've mentioned above that one of the conditions where a library would not work on Fire OS is when Google Play Services is required by the library. If we can list all of these conditions independently and use these to classify libraries, then we could add a higher level concept where Fire OS support is defined by a combination of these filters (which you could then link to from your docs). Other Android forks like Meta Quest, Huawei Harmony, and so on would then be definable with these feature classifiers as well (none of them support Google Play Services, for example).

What are other conditions in which a library would not be compatible with Fire OS?

[chris-trag]

Hey @brentvatne, @Simek, and +@douglowder,

I talked with the team these past 2 weeks and sought feedback from additional React Native community maintainers for additional perspectives. As a reset, let me share our intentions transparently and see if this opens an alternative that your team at Expo will feel good about approving.

User Story: "As a react native developer, I want to know which libraries are confirmed to work on Fire devices so that I can focus on publishing in multiple appstores/form factors quickly without surprises."

Top need: Clarity on libraries that are confirmed/verified to work on Amazon Devices & Services

Similar to how Expo Go is listed in the platforms filter but is not the end device experience, we receive a steady set of requests from developers (indie and Broadcast streaming app teams) to publish a canonical list of React Native libraries that support Amazon Fire devices.

Yes I acknowledge the marketing landing page you've been linking to says Fire OS is based on AOSP so there's a base level of compatibility, however we have a specific version fork of AOSP in addition to core libraries that need support in order for developers to have a smooth DX experience publishing on our 250 million devices: Login with Amazon, Amazon Appstore SDK, Location services, Amazon device notifications, Billing support, Matter Casting, Fire device supported DRM formats, Interstitial Ads (Publisher Services), etc. Our aim is to help devs have clarity and specificity on which libraries they can trust will work as expected versus what they need to find alternative libraries/solutions for.

Android to Amazon Fire OS common challenges w/ RN libraries

If a developer is taking an existing Android app built for Google Play to Fire TV, a common misconception is since it's all loosely AOSP it should just work. Many of the React Native community libraries are built with mobile-centric use cases that abstract just iOS/TVOS and Google Android backend services.

A great example is react-native-iap, which the maintainers added additional support to make sure payments work for Amazon devices as well as existing Android TVs and tvOS.

ReactNative.directory as the place of truth for libraries meta information/details

In addition, during our React Conf talk last year (28 min mark) I mentioned our ongoing work in testing and sponsoring projects that help RN developers easily get their existing apps onto Amazon devices. The suggestion from the other maintainers (Meta, MSFT, Callstack, SWM) was to reinforce this directory as the place of truth for compatibility with libraries and setting the expectation with the community they should be listing their projects and making clear what it does/doesn't support. We love this recommendation because we can help drive library updates to this site and help this project continue to be community-first. For instance, from our docs we plan to drive developers to this directory to review the full list of supported / verified libraries before they start the work of porting their app to work on Fire TVs, Tablets, and Echo Shows.

Rewording: Shift to a "Fire OS verified" approach?

From a framework perspective I can see how you'd have a strong desire to not have a flag for Amazon devices. What I'd ask is for your team to reconsider since we're offering to perpetually maintain a "Works with Fire Devices" (flexible on the naming of this and if this rather live under the status or type sections) filter where we are continually reviewing libraries and running integration tests to confirm it to works or not. I cannot guarantee it, but I could make efforts to get the other major device TV manufacturers to consider having a similar mechanism to check / verify compatibility for their flavors of OS/platforms.

ASK: Would you be open to side-stepping the "Amazon is not a platform" standoff and let us rework this PR to be a "Works with" or "Verified" flag in a way that you find amenable?

🙏 📦

[stmoy]

Chiming in from the desktop perspective -- ReactNative.directory has been super helpful for our desktop customers to learn more about which modules work with desktop and we're grateful to partner with folks like @Simek and others to get Windows + macOS represented.

@chris-trag mentions:

User Story: "As a react native developer, I want to know which libraries are confirmed to work on Fire devices so that I can focus on publishing in multiple appstores/form factors quickly without surprises."

ReactNative.directory is the quintessential "one stop shop" for the community to learn which modules are available for which platforms -- which is particularly helpful for Windows and macOS as out-of-tree platforms. I can imagine that @chris-trag is looking to get a similar sort of visibility for FireOS. It's a challenge that all out of tree platforms (and really any apps outside of the Expo ecosystem share): how do I know which modules work on the platforms I care about?

[brentvatne]

hey folks! @Simek and I discussed this and we're on board with adding a "Works with FireOS" status. one thing we'd like to do at the same time (or shortly after, it doesn't need to be in the same PR and you don't need to do it) is add a status for "Requires Google Play Services". we can then have three possible states for "Works with FireOS":

• yes: explicitly marked as working with FireOS. maybe it could be "verified".
• no: requires Google Play Services, or explicitly marked as not supporting FireOS.
• probably: works on Android, does not require Google Play Services. maybe "unverified" or "unknown" but ideally still communicating that it is likely to work.

(names of the statuses are of course totally open, i just wanted to choose the simplest words to communicate the idea as placeholders)

what do you think?

[chris-trag]

This would be excellent - I really like the approach & filter specificity 🙌

We'll clean up the PR for next week. QQ: Should we move the "Works with Fire OS" under the "Status" section?

[brentvatne]

@chris-trag - yup, status section works well! @Simek and i were also discussing possibly splitting expo go and fireos into a new section like 'Compatibility' that would go after status, but we can figure that out later