The main difference between arm Linux and arm android is how applications are packaged, (and android really wants you to build Java interfaces) partly because under the hood, android is Linux. It takes some development, but doesn’t need to be a “new codebase”. The harder problems are making the ux work with different from factors.
Actually, Linux is a good example of how this works, since you can build Linux for dozens of different CPU architectures (x86, x86_64, arm, risc-v, powerpc, and the list goes on)
There are places in the code where there are bespoke instructions to optimize for a given architecture, but overall, it’s still one massive “codebase”
The arm instruction set should be the same. Different processors might have different extensions. The main problem is the drivers. That’s why you can’t just flash any arm image on an arm phone, it has to have the drivers for the components that come with the phone
The difference there is it likely builds on the work they did for the Steam Deck and SteamOS. Writing a full Steam client for iOS or Android would be a huge amount of work independently from that.
It looks like they ran Linux apps inside a virtual machine on an Android phone. That has been possible for a long time now. That is certainly a route Valve could go down, but it won’t be a very good user experience.
Steamworks SDK supports Android now. Obviously, should there be an official full Steam client for Android, the preferred route is for game developers to release native Android games with Steam integration.
What’s running stand-alone games on Frame then if not a fully functional Steam client?
It is, but my assumption is that ARM-based linux and ARM-based android require a different codebase.
I’m not a dev though, maybe I’m wrong and it’s easier than I thought.
The main difference between arm Linux and arm android is how applications are packaged, (and android really wants you to build Java interfaces) partly because under the hood, android is Linux. It takes some development, but doesn’t need to be a “new codebase”. The harder problems are making the ux work with different from factors.
Actually, Linux is a good example of how this works, since you can build Linux for dozens of different CPU architectures (x86, x86_64, arm, risc-v, powerpc, and the list goes on)
There are places in the code where there are bespoke instructions to optimize for a given architecture, but overall, it’s still one massive “codebase”
The arm instruction set should be the same. Different processors might have different extensions. The main problem is the drivers. That’s why you can’t just flash any arm image on an arm phone, it has to have the drivers for the components that come with the phone
https://www.androidauthority.com/run-desktop-linux-apps-on-android-how-to-3586539/
That approach uses virtual machines. While that is possible (otherwise we wouldn’t see it), it is probably not really optimized for gaming.
Wine / Proton / Box64 (already used for gaming on android) is using translation layers, not a full virtual machine.
There was also an option to just install a Debian chroot on Android, with no virtualization in-between.
The app was called Lil’Debi, but isn’t maintained any more since 2018.
Whether or not it’s optimized for gaming is up to Google. The technology to bring Frame’s ARM Steam client onto Android exists.
The difference there is it likely builds on the work they did for the Steam Deck and SteamOS. Writing a full Steam client for iOS or Android would be a huge amount of work independently from that.
https://www.androidauthority.com/run-desktop-linux-apps-on-android-how-to-3586539/
It looks like they ran Linux apps inside a virtual machine on an Android phone. That has been possible for a long time now. That is certainly a route Valve could go down, but it won’t be a very good user experience.
Steamworks SDK supports Android now. Obviously, should there be an official full Steam client for Android, the preferred route is for game developers to release native Android games with Steam integration.