Hacker News new | past | comments | ask | show | jobs | submit login
Amazon props Vega to replace Android-based Fire OS on future smart devices (goodereader.com)
52 points by edward on Nov 10, 2023 | hide | past | favorite | 60 comments



I totally interpret this as a move to prevent any sideloading and ensure data collection and ad injection are being done on their part. Can't easily prevent those on something that's not a fully baked Android.


Which would make firesticks useless for me. I use them primarily as Plex / Kodi clients.


Useless to the you, but due amazon these are loss making hardware that exists to sell amazon prime ppv so they would make more money if you and me didn't buy...


if they wanted to prevent side-loading, why do they allow it via a free app in their app store?


if you cannot prevent, at least get metrics.


the point is that they could prevent, if they wanted to. they have no obligation to allow that third party app in their store


I agree about ad-injection and data collection, but if they wanted to prevent side-loading they would have done it by now, at least via the main route, which is the Downloader app they seem to have no problem hosting in their app store

Amazon doesn't have much to lose from allowing you to install x piracy app, in fact it's a selling point for a lot of people. yes a few people might not subscribe to prime, but I would be surprised if that outweighs the ad revenue and device sales


I have a hunch if they remained on android core and specifically prevented sideloading it would spark more backlash than simply switching to another platform. This way they gain complete control of the ecosystem with less backlash. Less tech savvy people will buy it, and more tech literate people will skip it altogether as they couldn't profit off them anyways.


This would answer my question. Amazon is deliberately making things harder on their engineers. This would give a profit incentive.

Run away from FAAMG, they all decided to behave like Apple.


Interestingly we’re coming full circle back to the 2007 approach to mobile, when each vendor was trying to build their own Linux variant.

There was Nokia with Maemo; the Japanese corporation Access was building the “next generation of PalmOS” on Linux [1]; and many others besides. Android killed them all.

Now companies like Amazon who have invested heavily into customized Android are finding that their interests are so diverged from the Google-managed mainline that it might be easier to switch to a custom Linux. Something similar happened with Huawei (aka Honor) and their Harmony OS, though with extra geopolitical pressures.

This kind of “cycle of reincarnation” is common in the tech industry, as specialization and generalization alternate between occasional disruptions. It’s often fascinating to watch.

[1] https://en.wikipedia.org/wiki/Access_Linux_Platform


Embedded devices shine brighter when they run software that is much more memory and performance conscious than Android.


>Amazon who have invested heavily into customized Android are finding that their interests are so diverged from the Google-managed mainline

What exactly is that?

Given everyone from the US military to cars use Android, I'm not sure what sort of OS control they aren't getting.

Can you imagine not working around the issue and deciding to fork your own? I'd be dying to know what it is. (Just going to guess the software guys aren't happy, but the executives think it gives them strategy. If its software based, I'd guess its communications/signals)


If they create their own SoC with their own IP having their own system will make it easier to move forward, as they won’t need to share development concerns with a larger group (e.g. they want feature X to go into one direction, and Android takes it in a different one, meaning they would end up with a fork).

This is not a huge issue with smaller/trivial features, but can get really cumbersome with bigger ones, and even more so if the forks start diverging more. As for control, see Apple & getting a modern GPU API that works on mobile and desktop and can be iterated quickly.

For a large number of industries Android makes more sense because they depend on certain development processes (security, hardware support, regulated environment certification, etc), but for multimedia consumption a lot of those are not needed.

Last, but not least, vanity can be a big part of such decisions, too. Engineers love to build stuff, even if it means reinventing the wheel for the Nth time.


On Android you're completely subjected to the whims of Google, the ideas of openness and collaboration among vendors on Android are a sham

(https://www.theverge.com/2011/05/12/google-android-skyhook-l... , https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on... )


Alternative take: Nokia was before is time


Huawei did it due to sanctions though


On the surface, it seems like not being able to run any Android apps would significantly diminish the value proposition of Amazon tablets.

I wonder if they'll have some kind of AOSP-based Android compatibility layer to mitigate that.


My Kindle Fire is just a glorified Prime Video + VLC + web browser. I bet only a fraction of Fire users use more than Amazon + 'commodity' apps.


I have two of them with the Kids accounts on them for my concern. Dozens of apps that they love. Maybe over a hundred.


> Lowpass hints at Vega’s reliance on React Native for app development, a framework born from the Meta realms. This choice suggests Amazon’s ambition for cross-platform prowess, harmonizing app development across iOS and Android. While the report doesn’t explicitly address Vega’s potential migration to Fire tablets, one can’t help but wonder if this Linux-based revelation might unlock new dimensions for Amazon’s versatile devices.

Ironically Android started out with JavaScript, and due to performance they pivoted into Java, if I remember correctly.

I bet it will be the usual mostly written in C++, with JavaScript as kind of GUI markup language, actually.

As that is the way many seem to use React Native, as a cheap alternative to QML / Qt.


This is the direction React Native is heading, with Fabric Native Components[1] and Turbo Native Modules[2]. On the development side, you have JavaScript, the language we all love to hate and hate to love, with its vast ecosystem of readily available libraries that are well-documented and used daily by billions of people. On the functionality side, you have access to native code, which speeds up and lightens the workload, making the app performant.

[1] https://reactnative.dev/docs/the-new-architecture/pillars-fa... [2] https://reactnative.dev/docs/the-new-architecture/pillars-tu...


Lol, amazing to see history repeat itself over and over again


Indeed back in the dotcom wave, the startup I joined was making our own flavour of AOLServer.

Now in some projects, I am basically doing the same, with the difference that now I am using JavaScript instead of Tcl, and C++ instead of C for the native side.

At least now I have a JIT in the box.


Thanks, I wasn't aware of them.


> Ironically Android started out with JavaScript, and due to performance they pivoted into Java, if I remember correctly.

I consider myself very familiar with Android's early history and this would be news to me. Any sources? Love finding new tidbits.


what about the tens of thousands android apps?


You say this as if Android has tens of thousands of useful/good apps.

There’s probably 100-250 that you might _really_ want.

Amazon can easily afford to pay each developer $1 million to port theirs, if they get serious about their own OS.


That didn't seem to work for Microsoft.


There it is mostly an interop for doing JNI calls into the OS APIs, as people keep forgeting NDK is only for game developers and Java native methods.


android apps is more than an interop or JNI calls, it needs the "jvm" and lots of java libraries, docker-alike solution is the only thing I can think of that it could possibly work, but it's very heavy on cpu and memory resources when you have many apps to install. it seems to me infeasible to be Android apps compatible when Vega is used, nobody is going to rewrite all Android apps in RN.


Ah, I misunderstood your point, I took it from the point of view of how React Native is used in the context of writing Android applications.

As for Amazon, naturally if this goes forward they don't seem to care about keeping the Android ecosystem on their Fire tablets, as most likely doesn't bring them the business value they care about.

Note that FireOS doesn't run standard Android applications anyway.


> Note that FireOS doesn't run standard Android applications anyway

What do you mean by that?

I have a Fire Tab, and it has F-Droid and I've installed many apps from there with no extra steps.


Because it doesn't run AOSP + Google special sauce on top.

I guess you were lucky in what APIs were being used, or the wrappers provided by Amazon.


I have a Fire Tab and it's collecting dust, I'm fairly certain Vega won't be able to do F-Droid, which is a bold move.


> Vega’s reliance on React Native for app development

Seems to me that Amazon does not need a complete OS. Most successful apps are Netflix and other “best viewed in a browser” apps.

For a couple of buttons and images you prolly don’t need Android which seems overkill.

So this isn’t against Android, but simply accepting the fact that most consumers are best served with more lightweight apps.


people only need android to run the browser.

Google know this, hence why they killed fuchsia.

with android nobody can make a clone without heavy investment, like amazon and Samsung did, while also paying the extremely high cost of keeping backporting thise changes every new version. heck even google screwed up their port for the pixel line in the 14 upgrade.


Fuchsia isn't dead (yet). They just completed their rollout across the entire Nest Hub line.

Only 16% of the team were impacted by the (reported) layoffs, which still leaves the other 84% working on something.


nest is also in the same "dead" group. no matter what the line workers think


If Amazon has had hundreds of people working on a Linux customized Linux distro since 2017, that seems excessive.

Esp. given that Amazon should have 100% knowledge of what hardware it will need to support.

Are there any contributions to mainline Linux source code from Amazon over this?

> Amazon’s covert shift to a Linux-based operating system > 2017 itself. > A substantial workforce within Amazon’s Device OS group, reportedly numbering in > the hundreds, has diligently toiled on bringing Vega to lifeAmazon’s covert shift to a Linux-based operating system


> If Amazon has had hundreds of people working on a Linux customized Linux distro since 2017, that seems excessive.

Notwithstanding "The Mythical Man Month", some initiatives do in fact move faster when you throw more people at the problem. Not only can you explore more paths in parallel with more people, but the key insight is that you don't need absolute individual productivity in order to achieve overall good outcomes faster.


TBH Fire OS is already so diverged from modern Android developers either target it or they don't.


The only reason I bought my firestick was android compatibility.

- Wasn’t that also the reason for most people?


Wouldn't Google Chromecast be the more logical choice if that is the main reason?

Firestick has been wildly successful, and the vast majority of people buy it because it provides entertainment at a much cheaper price point than Apple or Roku, for example. The new Chromecast is relatively new, the first incarnation was a piece of crap that couldn't run any apps (it was literally just a way to cast from another device to your TV).


For a long time, Chromecasts didn't run Android and Fire Sticks did (and they were cheaper and easier to buy).


Especially if it will he locked down to prime only it will completely useless


> Especially if it will he locked down to prime only it will completely useless

Obviously it won't just be locked down to Prime. Amazon is not that silly.


What does the word "props" mean in the context of this headline?


I think "preps" got autocorrected.


I would assume “props it up” like: readies it, positions it.


preps would have been a better choice of word imo, perhaps it was a typo. I've never heard props used in this content before.

edit: had the browser window open too long and my reply is pretty redundant now


The two most important pieces of android are the Linux kernel and the android app runtime.

The article says that this new initiative from Amazon will use the Linux kernel and I would think they would have to maintain android app compatibility, so it’s hard to see that it’s much different then their existing FireOS.

React native could be a way for them to build their shell and some core apps, but it really doesn’t replace android app compatibility.


https://www.reddit.com/r/htmx/comments/16p3rbo/hyperscript_w...

It’s reactive native using htmx.

Less hungry than react and simpler to develop on.


Tangential, but was Fuschia the backup plan for Google if they lost the lawsuit to Oracle?


No, the backup plan was to switch the implementation of the Java core libraries from Apache Harmony to the already-GPLed OpenJDK.


I don’t see how it would help, the lawsuit was about the Java layer not the Linux kernel.


If you loose all your Apps and are starting again with Flutter/Dart you may as well replace the kernel too.


Except not even the Android folks are a big Flutter/Dart fans. You won't find them on Android SDK site.

It is a parallel business unit.


I'd rather they just use Ubuntu or else vanilla Android, but if they have anything like a normal GNU/Linux/PipeWire/DBus/Wayland userland available it could be cool .


They'll be back.


Here I was thinking chips...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: