Third-party TeslaOS in-car apps?

[srs5694]

Err... Tesla is running Linux.

The same OS Android is based on.

It's not really a "new platform"

It's true that Tesla uses the Linux kernel as the base of its OS, for at least one computer in the car; however, these days the OS kernel, and even low-level support libraries, aren't the biggest compatibility issue -- it's the APIs for managing the display, user input, etc. I have no idea what Tesla is using for that. It might or might not be related to the X Window System (the traditional windowing system for desktop Linux, although there are replacements that are slowly taking over) or whatever Android uses. Developing for Android is very different from developing for desktop Linux. I wouldn't assume that developing for Tesla would be just like developing for either Android or desktop Linux.

Also, as I believe I've stated elsewhere, third-party apps running natively on Tesla's computers pose a greater security risk than Android Auto or Apple CarPlay apps running in a mirroring window. Security is a big deal in computing, and given the importance of the computers in a Tesla, we should all be taking that very seriously. You have a chance to override a rogue Android Auto app that directs you to drive into a river. If that app is controlling your car on Autopilot, you might not have time to override it, particularly if you're one who doesn't keep your hands on the wheel at all times.

 

[JasonR67]

Apple's CarPlay is a bit more restricted (API's are by invitation only, like Apple TV)

Note: AppleTV's APIs are completely open. Anyone can develop for AppleTV.

 

[Knightshade]

It's true that Tesla uses the Linux kernel as the base of its OS, for at least one computer in the car

Right- the one that does the media/display/game/app stuff.

It
; however, these days the OS kernel, and even low-level support libraries, aren't the biggest compatibility issue -- it's the APIs for managing the display, user input, etc. I have no idea what Tesla is using for that. It might or might not be related to the X Window System (the traditional windowing system for desktop Linux, although there are replacements that are slowly taking over) or whatever Android uses. Developing for Android is very different from developing for desktop Linux. I wouldn't assume that developing for Tesla would be just like developing for either Android or desktop Linux.

Given the ease with which they added essentially already-existing games written for Linux (atari games via a linux emulator) and with which the original developer adapted their Android game (the racing game) I don't think it's too big a stretch to suggest that it'd be far more trivial to "port" existing software to run on the Tesla than it would a "new OS" as the other guy tried to call it.

Especially when there's already multiple ways to straight up run native android apps under Linux.

Also, as I believe I've stated elsewhere, third-party apps running natively on Tesla's computers pose a greater security risk than Android Auto or Apple CarPlay apps running in a mirroring window. Security is a big deal in computing, and given the importance of the computers in a Tesla, we should all be taking that very seriously. You have a chance to override a rogue Android Auto app that directs you to drive into a river. If that app is controlling your car on Autopilot, you might not have time to override it, particularly if you're one who doesn't keep your hands on the wheel at all times.

The media computer and the driving computer aren't the same computer, so...no.

It's why you can reboot the media computer entirely while still driving the car on autopilot.

It's also pretty easy to sandbox apps anymore- but I suppose if someone really did find an exploit here they could erase all your radio presets or something.

 

[jerry33]

It's true that Tesla uses the Linux kernel as the base of its OS.

Also, as I believe I've stated elsewhere, third-party apps running natively on Tesla's computers pose a greater security risk than Android Auto or Apple CarPlay apps running in a mirroring window

1. Yes. The kernel is Linux.
2. No. The displays and the driving are separate, you can reboot either display while driving. Not a security risk.

 

[srs5694]

2. No. The displays and the driving are separate, you can reboot either display while driving. Not a security risk.

I disagree, with a caveat. The two computers are still connected together. The driving computer, running on Navigate on Autopilot, gets its driving directions from somewhere, which is presumably the display computer (where you enter the navigation target and view the map). Give a developer access to the latter and the developer must necessarily have at least indirect access to the former. People who write exploits are very clever about finding ways to take advantage of such connections to do whatever malicious things they like. Note that I work in the computer field, although not in security, so I have a better-than-average understanding of how tricky it can be to completely isolate two computers when they have any connections to each other. Even in the absence of a direct exploit of one computer from the other, control of the display could create hazards. Imagine if a program (intentionally and with malice or through incompetent programming) altered the speedometer reading, for instance. That could result in your getting a ticket or driving at an unsafe speed and getting into an accident as a result. A program that intercepts your request to be routed to a Supercharger could give you bad directions, leaving you stranded without a charge. Those are just a couple of ideas that spring to mind.

The caveat is that I don't know the exact nature of the connections between the two computers in Tesla vehicles. I infer that there must be some connection, because of the functionality of Navigate on Autopilot, the ability to update both computers, etc. It could be that the connection is more limited than I suspect -- but it could also be much greater. I have yet to see a good analysis of this subject by anybody who's competent to perform it, or who has inside information. Absent such an analysis showing a minimal threat profile, the only sane assumption is that both computers would be vulnerable to exploit should either one be opened up to outside development.

 

[eXntrc]

Err... Tesla is running Linux.

The same OS Android is based on.

It's not really a "new platform"

There is a misunderstanding here about the delta between what Android provides vs. the Linux foundation it's built upon. For a good article on the subject I recommend reading Android is Based on Linux, But What Does That Mean?

For those that don't have time to read the article, no problem. I think this image sums it up pretty well:

Android applications can (and do) take advantage of all those great systems in all those colored boxes. The YouTube app, for example, takes advantage of the Media Framework library. Navigation applications like Waze leverage the Location Manager service. And all of this code runs in a Java Virtual Environment called the Dalvik VM.

Linux, on the other hand, only provides the most foundational platform layer which you can see in red. Even this red area can be a little misleading because although it says things like "Audio Drivers" a music application wouldn't write directly to that layer. A music application would be written using the Media Framework APIs.

So unfortunately no, porting would not simply be adapting existing stuff for the car controls and displays. Any app written for Android would require a massive rewrite to run on raw Linux. Even the most fundamental systems like the windowing system (which is how application developers create things that get drawn on the screen) are entirely different. Which means that even the simplest "calculator" app would need a rewrite to work on base Linux.

 

[Knightshade]

Which means that even the simplest "calculator" app would need a rewrite to work on base Linux.

They wouldn't though- because as mentioned there's several ways to just run native Android apps within Linux already.

Heck Chromium OS can do it (in at least some forks) and guess that THAT is a version of? Linux.

 

[eXntrc]

I believe what you're referring to is mentioned in that article under the section "Why You Can’t Run Android Software on Desktop Linux". As that article describes, it's possible to do this through emulation. Bluestacks is an example of VM software designed specifically to do just this. You can even use Bluestacks to run Android apps on Windows. But as that article points out, there is a performance penalty with going this route since you have to emulate Android systems and map them to underlying platform systems.

It's worth noting here that Android Auto (and to my understanding Apple CarPlay) aren't "application platforms" in the traditional sense. Android Auto applications don't actually run on the vehicle hardware. Instead, the vehicle provides an output display and passes along button input. Android Auto applications actually run on your phone. Your phone sends video of what the car should draw over wireless, then the car sends back information to the phone about where the screen was touched or which hardware buttons were pressed.

This is important for a few key reasons:

1. The application doesn't need to be emulated because it's already running on the original intended hardware.
2. The host (in this case the Tesla computer) doesn't need to spend cycles running the app since the phone is doing that. So those cycles can be spent elsewhere.
3. Any game save state, application progress, login information, etc. doesn't need to be synchronized between devices because it's already on the device where it's running.
4. When you leave the car, you take your exact state with you and can just keep going if you desire.
5. This approach is fairly easy for OEMs to implement because it's basically the equivalent of Remote Desktop. No difficult systems to emulate, just video streaming.

This is why I'm of the opinion that the only reason for Tesla to go with a new application platform, one running directly on Tesla hardware, would be control. Going with Android Auto or CarPlay would:

• Be easier to implement
• Be faster to market
• Not require "wooing" developers
• Provide Tesla owners with an instant application catalog

But I think I've said enough on this subject. I've spoken my piece and I don't want to fan the flames of an argument. Only time will tell what Tesla ultimately does. I just hope whatever it becomes is what's truly best for their consumers.

 

[Knightshade]

I believe what you're referring to is mentioned in that article under the section "Why You Can’t Run Android Software on Desktop Linux". As that article describes, it's possible to do this through emulation

Your article is over 2 years old.

There's chromebooks running Android apps under Chromium (Linux based OS) which runs on hardware no more powerful than what the Tesla MCU2 has in it today (some less powerful).

 

[srs5694]

Your article is over 2 years old.

The Android software stack hasn't changed all that much in two years, though. The basic principles still apply.

There's chromebooks running Android apps under Chromium (Linux based OS) which runs on hardware no more powerful than what the Tesla MCU2 has in it today (some less powerful).

The arguments against creating a new development environment for Tesla (vs. iOS/CarPlay and Android/AndroidAuto) is not fundamentally one of performance. I realize that @eXntrc did mention performance, but that wasn't the main point of his argument. Performance concerns have little to do with whether it's technically possible to run a port of SomeRandomApp on Tesla's computer with reasonable performance; rather, it's about whether doing so might degrade other features you might want to run simultaneously (mapping, music playback, etc.) -- and to reiterate, this isn't a key point to the argument against implementing a "Tesla store" with third-party apps. The main arguments have to do with developers' time investments, security, practicality, and so on.

 

[Knightshade]

The Android software stack hasn't changed all that much in two years, though. The basic principles still apply.

Given I was talking about advances in HW and emulators, not the Android stack, no, it doesn't.

Just the opposite in fact- it reinforces how easily modern HW can run android apps via emulation without stressing decent hardware.

The main arguments have to do with developers' time investments, security, practicality, and so on.

All of which are basically 0 if they're running in a sandboxed Android emulator.

See also all the folks doing exactly that with their chromebooks for example.

 

[srs5694]

The Android software stack hasn't changed all that much in two years, though. The basic principles still apply.

Given I was talking about advances in HW and emulators, not the Android stack, no, it doesn't.

Just the opposite in fact- it reinforces how easily modern HW can run android apps via emulation without stressing decent hardware.

That's a straw-man argument; as I clearly stated, this is not primarily an issue of performance (although that could become an issue in corner cases, such as if CPU load spikes when running certain apps -- either Tesla's own apps or third-party apps).

The main arguments have to do with developers' time investments, security, practicality, and so on.

All of which are basically 0 if they're running in a sandboxed Android emulator.

See also all the folks doing exactly that with their chromebooks for example.

If you're running an Android emulator on the Tesla, then there's basically no advantage compared to using Android Auto or Apple CarPlay -- you'll get no access to Tesla-specific features, which to my mind is the main point of wanting to run third-party apps directly on the Tesla's computer. I suppose you'd (potentially) be able to run any Android app, which AA/CP won't let you do; but AA/AP restrict what can run largely for safety reasons -- playing Angry Birds while driving is a Bad Idea, and any solution that enables you do do that is a Bad Idea, too.

The fact that something can be done on a Chromebook does not mean that doing something similar on a Tesla would be a good idea, compared to the alternatives (like supporting Android Auto and Apple CarPlay).

 

[Cyberax]

Has Tesla/Elon ever mentioned anything about opening up for external developers to create apps for the in-car display? I think that would be another game-changer and further cement Teslas lead in BEVs. A Tesla-controlled software eco-system (like iOS) would make it even harder for other car manufacturers to keep up.

Right now there's simply no way Tesla can offer third-party API, except to a very narrow set of application developers under strict supervision by Tesla.

This is because apps will have to run on the same hardware as the car's UI. So a malicious app would be able to ransomware your car, for example. Or wreak havoc on CAN bus through the Gateway.

They can perhaps try to partition the system through virtualization, putting the app code into a VM with limited access. But the hardware on Tesla Model S/X doesn't support virtualization, and is too slow for most applications anyway.

 

[Knightshade]

If you're running an Android emulator on the Tesla, then there's basically no advantage compared to using Android Auto or Apple CarPlay -- you'll get no access to Tesla-specific features

That's not true at all. There's a number of advantages-just 2 examples-

1) Tesla gets total control over WHICH apps you can use. With AA for example basically any app that supports it will display on the car screen and those that don't won't- with this method any app tesla picks will work (and any they don't, won't).

2) Tesla gets total control over how, when, and where such apps display- versus many AA/CP implementations that take up 100% of the display (or a specific fixed % of it)

There's others (including potentially what else they might give apps access to securely if they want to involve some actual development to add hooks for it but that's getting into the weeds a bit)

I suppose you'd (potentially) be able to run any Android app, which AA/CP won't let you do; but AA/AP restrict what can run largely for safety reasons -- playing Angry Birds while driving is a Bad Idea, and any solution that enables you do do that is a Bad Idea, too.

But, as I pointed out- running via emulator means Tesla has complete control over what apps are allows and what aren't.... rather than letter AA/CP decide for them. That would be a very Tesla preference.

For example they might decide more music streaming apps are fine, but not navigation ones because they REALLY want you to use their generally crappy nav software to leverage NoA type features so they never offer emulation support for nav apps.

The fact that something can be done on a Chromebook does not mean that doing something similar on a Tesla would be a good idea, compared to the alternatives (like supporting Android Auto and Apple CarPlay).

Nor does it mean it's a bad one.

There's pros and cons to both options.

Tesla has so far been pretty clear on the fact the cons are winning regarding AA/CP, thus the curated emulation route I suggest for a Tesla app store is at least ahead in that Tesla seems open to the general idea of such an app store once the fleet is larger and it's worth bothering with.

 

[srs5694]

That's not true at all. There's a number of advantages-just 2 examples-

1) Tesla gets total control over WHICH apps you can use. With AA for example basically any app that supports it will display on the car screen and those that don't won't- with this method any app tesla picks will work (and any they don't, won't).

That may be an advantage to Tesla, but not necessarily to owners, for a reason you mention later in your post:

For example they might decide more music streaming apps are fine, but not navigation ones because they REALLY want you to use their generally crappy nav software to leverage NoA type features so they never offer emulation support for nav apps.

Music apps work fine via Bluetooth streaming (although admittedly if you want to do anything complex with their user interfaces, they suffer that way -- but such manipulations are generally unsafe when driving, which is why AA/CP implementations generally impose restrictions). Your hypothetical of Tesla blocking all navigation apps would be a big negative to this approach from the user's point of view.

Basically, both AA/CP and the Android-in-a-Tesla approach you're advocating limit your choices of what apps to use based on what somebody other than the driver thinks is a good idea (or decides arbitrarily). I'm sure there'd be cases where drivers might prefer Tesla's choices, but as in your example of the navigation restriction, there would also certainly be restrictions that would be better on the AA/CP map.

2) Tesla gets total control over how, when, and where such apps display- versus many AA/CP implementations that take up 100% of the display (or a specific fixed % of it)

There are AA/CP implementations that restrict it to a portion of the display. This would actually be necessary in a hypothetical Tesla implementation, at least for the Model 3, since part of the display shows your speed and car status indicators, which I believe are required by law to be visible whenever the car is moving.

Tesla has so far been pretty clear on the fact the cons are winning regarding AA/CP, thus the curated emulation route I suggest for a Tesla app store is at least ahead in that Tesla seems open to the general idea of such an app store once the fleet is larger and it's worth bothering with.

Somehow I doubt if the Android-in-Tesla approach you're advocating would be any more appealing to Tesla than AA/CP; they're too similar in their feature sets.

A full-on Tesla-native app store has even more problems. That's not to say it won't happen, but if it does, I'll be very wary of it, and I'm skeptical if it'll build enough apps unless Tesla seriously subsidizes it.

 

[eevee-fan]

Just bought a Model 3, really bummed that it has limited selection of streaming video and audio. I had to resort to using my phone to stream iHeart Radio, kind of defeats the purpose of the car data plan.

 

[Knightshade]

You necroed a nearly 4 year old thread to say that?

THAT said- thanks for giving me a chance now to follow up on the previous last post from srs5694 where he was super dubious about the idea I was mentioning that Tesla might support 3rd party apps with this recent news:

Tesla To Add Official Support for Third-Party Services and Apps

Tesla prepares to transform user experience by enabling support for third-party applications. Discover how this may revolutionize the way we interact with our T

www.notateslaapp.com