As an Android developer and someone who has studied the ASOP internals, I don’t see what the big deal is. If I were going to build custom hardware that has a custom ui then it makes complete sense to start with the open source version of Android. Google has spent billions inventing that wheel and you can use it for free. It has everything you need (except realtime). The natural way to build ui apps in Android is to make an apk. Doing anything else would be weirdly unnecessary.
Yep. Making a feature electronic with your own OS is immediately burned by
- WiFi/ip stack
- 4g/5g wireless
- graphics drivers
That’s why pretty much everything is android. I just wish these startups would stop shoving Ubuntu server with chromium inside and at least do something like Netbsd and libcairo.
The biggest downside I see is that 1. according to reviewers the battery life is utter garbage. Using Android probably isn’t helping that much. And 2. There is no actual purpose for this device, there’s nothing it does you can’t do better with a phone.
The target market for this is presumably the same as the Playdate but any of the normal AI apps would be better for most users tbh
> The target market for this is presumably the same as the Playdate
I don't think "this could be an app on my phone" works as an argument for the Playdate the way it does for the Rabbit R1. A dedicated gaming device with real buttons is better than a touchscreen any day and the constraints of the hardware make the games unusual and highly creative. It would diminish the experience considerably if it was just a mobile app.
Contrast with the R1 which seems to want to be a general purpose device that just does everything worse than the supercomputer you already carry around in your pocket.
Sometimes it's not about what it can do at first but what long term potential the creators see. Perhaps this is the MVP they could make and release but they made design choices that aren't apparent due to a vision for a future iteration that is more capable.
An MVP for this device would be an app, there’s no demonstrated capabilities the playdate has that a phone can’t do. I actually think the Humane pin “””succeeded””” in that they actually produced a device that has capabilities a 5 year old smartphone loaded with the same software doesn’t.
Donald Rumsfeld — 'You go to war with the army you have, not the army you might want or wish to have at a later time.'
In that context; Android is mediocre but I don't mean that in a nasty way. It might not be the best design or the most dynamic but it is the one that we have today that is powerful and easy enough to do what is needed.
If I was to build a portable, whatever, as much as I would love to start from a blank slate, that alone could mean being years behind just to get off the ground floor. Building a base OS isn't easy even if you know what you are doing, having something that is 100% free to launch off is wonderful.
Most people don't realize that Android was originally intended to be a BlackberryOS clone, but was pivoted to compete with iOS at the last minute instead. Once you understand that, a lot of the design decisions start making a lot more sense.
The big deal is that it's just a hardware skin for an app while they are trying to pitch their customers on a new type of computing platform. It's just vaporware. It's a software company larping as a hardware company. They should be laughed out of existence.
Several folks have stated that it could be just an app. I disagree. Modern versions of Android on a real phone severely limit what an app can do. It can't run forever, it can't gather any and all telemetry available to the physical device at will.
As for battery life, there's a lot you can do at the OS layer to limit what services run, but at the end of the day you're not running on a piece of hardware that has been honed by thousands of engineering hours and billions of dollars, so V1 is going to be pretty rough.
Being dumb hardware which connects to a smart device for the juicy tasks. If nothing relevant is running locally anyway, then this setup makes more sense on surface to get longer battery time.
But overall, I think people are just disappointed how much it sucks, and satisfied as every knew it from the beginning.
The bits of this controversy about "where's the LAM?" are strange to me. My impression from the beginning was that the "Large Action Model" was a server-side thing, and the hardware was going to be almost-entirely a way to talk to their services.
Apparently this impression was far from universal.
I recall the LAM being a/the (stated) reason why it couldn't "just be an app."
If it's vaporware on-device it's more evidence that it could have just been an app. Perhaps there was special on-device sauce coming in a future update, but as of now it's a client making http calls.
You probably really wouldn't want it to be doing that on someone else's server, using your authentications to all your apps. Which is what it actually does (or claims to, anyway).
Yeah the whole point was supposedly you can "train it" by operating a generic "app" and it would learn so in the future other people could operate these apps via voice only.
A clearly as yet non-existant feature. But would definitely require super obervation, recording, and control above standard android. Also insecure as hell.
It would be super dumbo-bonkers insecure if you werent actually running these "Generic app training" on your own device, but in some cloud emulation. yikes
This is as dumb as microsoft selling their next big feature of ai knowing how to control generic windows applications... that means they are going to record EVERYONES screens and actions without consent, we all know how microsoft respects users consent
Mobile devices don’t have the memory or the memory bandwidth to run an LLM that’s big enough to be good at much. Plus the fixed battery and thermal constraints.
As someone whose job is to inference on the edge. No one is getting a mass product consistently inferencing on the edge for $199 not today and not next year (and I’d bet not in 2026)
What do you mean by edge? There are already many apps that use LLMs and diffusion models locally on even a mac M1, which means iPhones and tensor chips aren't far behind
This will perform inference on Phi-2 or Mistral on almost any iPhone device. The first neural engine came with the A11 bionic chip which is in the iPhone 8. People can buy that phone for $150 used on Amazon.
I think that's evidence that inference on the edge is already here
You could even go up a few iPhone versions and still be <$199. iPhone 12 used ~$190 supports iOS 17 and can run the Tiny models (phi-2).
For small models, today a used iphone 14 costs ~$300. Which means next year it will by down to ~$200.
I'm pretty sure by 2026, we will be able to inference "medium" models like Mistral/Llama3 8B on a <$199 device. That's not even factoring in how much better models will get by that time
That’s not what the parent comment is talking about. They say that no one can mass produce these devices and sell them for $200. You don’t mass produce used iPhones to sell to people.
What I find interesting from the analysis is that the hard-coded, per-app event handlers suggests their integrations are nothing more than traditional wrappers around the services they support, instead of some magic, AI powered LAM living on the cloud that can interact with anything:
It’s implemented as a launcher, per the article. And saying it _could_ be an app is missing the point of the device entirely.
It’s like saying the Light Phone could be an app. They’re trying to do something entirely different, and an app that does what the rabbit does would be very uninteresting.
But what the Rabbit R1 is doing as an app running on a cumbersome hardware device is totally uninteresting. And that is the point people are making when they say it's just an app.
The purpose of the Light Phone is to detach oneself from the unnecessary, time-consuming features of smartphones. There are approaches to this that are simply apps, and they are popular, but there is a genuine benefit to the approach a Light Phone takes which uses separate hardware to completely wall the user off, which app implementations can't do. And the standard phone manufacturers won't make the Light Phone obsolete by incorporating that feature, because it directly contradicts their business models.
With the R1, the point is to have an LLM powered AI assistant. Absolutely nothing about the product is enhanced by doing it as a separate device rather than an application. The design is eye catching, but comes at the price of several hundred dollars and requires you to carry two devices around. The second Apple or Google implements this functionality on their phones, this thing is dead. And I guarantee you they are working on this as we speak, and it will be available within 1-2 years natively on iPhones/Android.
What is the different thing they are trying, which isn't already there since years, through Smartphones, Smartwatches, Amazon Echos and the wide integration of Google Assistant and Amazon Alexa on the multiple devices and services they offer?
Well, if there's no reason to redesign the wheel then maybe they should stop claiming that the "rabbit r1 is not an Android app" themselves. I would venture to guess the reason why this is emphasized, other than that, is that multiple reviewers made the point that it really should've just been an app.
“rabbit r1 is not an Android app” is true though. To a different degree, saying the r1 is an android app is like saying a polestar 2 is an android app. Yes, android OS and android software running on that OS is a part of it, but the device as a whole is the combination of all of its software and its hardware.
A more accurate dig at it is that the main functionality rabbit r1 could be offered just as an app instead of bundled on its own hardware, which is not so true of a car.
You're right, and I should've adjusted my reply to be a bit more precise. That said, man, from my perspective, it's barely different than an Android app. It feels like some weird twist on the "just ship your computer" joke with Docker, wherein they just shipped a chunk of Android phone with their app. Honestly, I mostly ignored these devices when the news and fuss came around, but this class of device really does hit me as the least compelling new class of device I've seen in quite some time, personally...
If you turn off Battery Optimization, yes. Apps can even draw over and control other apps. Assuming the LAM is just an app controlling AOSP in a VM server-side, this really should have just been an app with the LAM sending touch events back to the device.
Not sure about nowadays, but a few years ago yes. You could run a foreground(?) service which kept an icon in the righthand corner (can’t remember too well). Anyway, I had an app which kept a http server always running.
The (explicit or implied) corollary is that it is nothing more than an Android App. At which point, why pay for a separate physical device? Not even much of a novelty at that point.
I've built multiple embedded Android products and this seems like an absolutely terrible case for embedded Android.
Usually embedded Android is a trade where you get rich multimedia and heavy UIs made easy at the cost of raw performance compared to something like Qt and a minimalist RTOS.
The Rabbit R1 takes advantage of none of that. The UI is intentionally minimalist, while power draw was supposed to be a concern here. The thing is essentially a dumb client at the end of the day.
For the kind of money they raised they should have been able to do something closer to bare metal and gotten much better performance and battery life.
I would have probably recommended Android myself if I had been involved. The points you raise are valid, but:
1. You're going to have way better board/vendor support with Android.
2. The Android networking stack is more featureful than any RTOS. You aren't constrained with e.g. TLS support or paying a vendor $$$$ to implement what the infra team wants.
3. You can hire Android developers by the dozen. RTOS application developers are much more annoying to hire, even if they'll work for cheaper.
4. You don't have to pay a vendor (or build it yourself) to get basic platform functionality like A/B updates, a build system, secure boot, etc. Android has solutions for these of admittedly varying quality.
But you'd also get all of this and more by skipping the hardware entirely and just selling the app.
If the main goal is vendor support, Android is downright awful compared to Linux when it comes to embedded use cases.
You can get up to date Linux versions for pretty ancient stuff, but AOSP does zero favors for porting and vendors are more than happy to throw their hands up and leave you fending for yourself, breaking lots of stuff (like the build system) along the way
...but they also raised $30M and landed an extra $10M in their first week of preorders. Between that and the heat behind their name, they weren't hurting for cheap labor.
I think you're ascribing too much intention to their choices, this device feels like they raised a bunch of money, let everyone do their own thing and dumped the result over the wall.
Good mainline linux support has not been my experience for the kinds of mobile SOCs the Rabbit was inevitably going to be using. Taking a look at the PostmarketOS support page for the mediatek SOC used in the product [0], seems like most of the sleep and radio drivers are not mainlined/supported. Yes, Qualcomm and mediatek drop support after annoyingly few years, but they do provide support before EOL.
Haven't mentioning mainline support at all, and I'm speaking relative to Android: vendors that do Linux poorly do Android even more poorly
And I wouldn't say that these vendors blanket provide support before EoL. I work on a product where EoL is a very long time due to automotive involvement. The vendor's standard of support is extremely low, with most requests resulting in being pointed to some "partner" which is usually a ragtag team of contractors well versed in some set hacky fixes for the vendor's boards
Your goals when selecting an RTOS are usually development-centric, not to provide product level features. What did you have in mind that the OS should be bringing to the product?
What? There's no reason but product level features to choose an RTOS. An RTOS won't be more ergonomic, won't make life easier in general, won't give you any new primitives that are development related...
You choose it because the product demands good performance, low latency, etc. And the Rabbit fits that bill pretty cleanly.
Closer to bare metal doesn't mean it needed to be running a custom GPU driver, but it's also not running a Flutter/Compose app on a 6 year old GPU core...
Typo, didn't realize I wrote "RTOS" out of habit instead of "OS".
Regardless, I wouldn't consider those product level features and I also wouldn't consider them strictly limited to RTOSes either. A normal operating system is going to be significantly better for performance on good hardware, which is why all of the top supercomputers are running a variant of Linux. An RTOS may give you lower latency, but it's really specialized to realtime as I'm certain you're aware.
You choose an RTOS because you either have those realtime constraints, you want a "smaller" system, or you're running hardware that can't support a full-fat operating system (e.g. ESP32) and the RTOS offerings are what's most convenient. I don't think any of those apply to the Rabbit device in a realistic way. Implementing it in an RTOS wouldn't speed up the server-side inference that's doing the actual work here, for example. Since there aren't reasons to go with an RTOS, your criteria for OS selection are going to lean towards the meaningful benefits a normal OS like Android offers, both in terms of development tooling and board support.
The criticism is that, this could’ve been an app. Imo the more important question is still, why does it matter even if it’s not an android app. If all the “magic” happens on the backend, how does it matter if it’s Android, Windows or iOS. At the end of the day, it still could’ve been an app.
They sold a whole bunch of these on the basis of it being a neat hardware gadget, only for people to find out they’d paid $200 for an app that didn’t work and the hardware is unnecessary and doesn’t do anything your phone doesn’t do.
It all just seems like a bit of a scam for these companies to be saying you need to buy their hardware in order to use their app, only to find out their app doesn’t work after you’ve paid out the money for the hardware.
If rabbit’s pitch was “pay us $200 to trial our app” they’d have had no takers.
I agree with your take. This device kind of reminds me of the kiosk use case. There are times where having a single device, that does one thing well, feels better than having to search through a crowded smartphone for an app.
As an Android developer I don’t understand the reason behind mixing Jetpack Compose and Flutter. I’m not an expert on cross platforms, I mostly work on Compose, so if anyone wants to share.
Good chance it started with flutter (for prototyping, lack of direction of product early on) and then when it was decided it was going to run on a fairly normal Android device someone said we should use something a little closer to Android native dev.
My guess is the stuff in flutter world is technical debt.
They most likely added a dependency that transitively depends on Compose, possibly for some prebuilt UI.
EDIT: Another possibility is that they started out with some template app that happened to have the Compose dependencies included in the Gradle build script, and with this being a Flutter app, they had no reason to touch the Gradle script beyond just adding the Flutter dependency. Assuming the app doesn't have R8 enabled, all of Compose would remain in the APK unused.
Ok, I took a closer look at the analysis page linked to from the main article. There does seem to be a decent amount of Kotlin code written by Rabbit themselves, mostly UI for the settings screens, as well as some networking-related stuff (WebSockets, Wi-Fi, etc), hardware-related things such as the camera, OTA updates, etc. Basically, things that make sense to be handled closer to the operating system itself.
Interestingly, as far as I can tell, Compose is only being used for a "hardware test activity". The rest of the Kotlin side of things seems to use the traditional Android UI stack with activities, views and fragments. That makes three distinct UI frameworks in use on the Rabbit R1 - Flutter, Compose and traditional Android.
Thanks for the thorough lookup, I have worked with launcher, IoT apps on Android. And, Flutter (or any cross platform) would never be an option for this kind of projects. It’s not just because we need easy access to the hardware (camera, Bluetooth, etc) but also the different protocols (MQTT, RTSP, etc) are very complex.
> Founder and CEO Hans Dockter has said that he originally wanted to name the project "Cradle". However, to make the name unique and less "diminutive" he instead chose "Gradle", taking the "G" from the use of Groovy.
I expected as such, and Wikipedia confirmed it for me.
Probably just fast moving startup stuff. Different developers working on different features with different preferred toolsets. Can normalize it all later, right now launch is most important.
In theory, it's a better and quicker experience than pulling out your phone and using the ChatGPT app for questions and other apps for other things. In practice, the things it does worse might offset the things it does better.
Agreed, a device with less function that does the same thing as a smartphone, something virtually everyone has, seems like an odd business idea. There’s a reason most people do not have, nor carry a digital camera anymore.
> In the same way the Apple Watch doesn’t do anything better than an iPhone
I don't own an Apple Watch, but even my basic little Fitbit Charge has quite a few things it does way better than my phone (some of which my phone can't do at all, due to not actually having the required sensors).
It's a little weird to me how common a sentiment this has been in all this. Do y'all not actually use the wearables that already exist? They all have something clear and useful that they do excellently compared to the weird little Android box that the r1 currently is - even little sleep rings like the Oura ring.
And that's beside the fact that the r1 isn't even a wearable.
That is the thing. Not using the smartphone has a point when it propose better ergonomic. Having to carry and get another device out of your pocket is not better ergonomic.
It would make sense not being just a smartphone app if the device was wearable or could be used hand free, it is not.
The latest iPhones are not actually 3x faster, or even 2x faster, for many common tasks such as opening a pdf compared to a 5 year old iPhone on iOS 12. Even for unusually intense workloads, like exporting dozens of pdfs at the same time, it doesn't get anywhere close to 3x.
save you a click
> We didn't find a "LAM" in the APK, but that doesn't mean it isn't happening in the backend. It also doesn't mean it is happening in the backend.
> rabbit is an android launcher
It seems like a pretty basic breakdown, imo. I don’t know much about Flutter or Kotlin but I was expecting a lot more detail in an article hitting the front page.
Bit of a nothingburger really, given what we already know about the device.
I wish them the best with their product, and hope it improves, but I don’t think it’s worth it right now if you expect to get a really good tool - it’s a gimmicky, early days product from what I gather.
I turned down an interview with Rabbit. While I was looking into the company, I watched a product demo of theirs featuring the CEO who didn’t use the scroll wheel on the device (instead used the touch screen) and it seemed as if multiple features shown were not actually in a functional state. Kind of a weird tech stack, too, based on the job description.
The LAM stuff is a lie. It's all hard coded handlers for the included functionality. Go check out the /rabbitr1 subreddit where you'll find a bunch of security vulnerabilities and more shady shit by this company.
There was a repo that falsely claimed to have released the language action model code, when it became apparent that the "leaked" code did not actually prove any of the points made in the README the author deleted the repo. You can read Retr0id's analysis here: https://web.archive.org/web/20240424095544/https://github.co...
EDIT: I have just realized that you were replying to Retr0id.
