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?