4 ms·
> Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem The "app ecosystem" on a free mobile OS would be shared with th
by 0815test 8y ago
> Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem
The "app ecosystem" on a free mobile OS would be shared with the "ecosystem" of free PC apps. Chromium does target, e.g. Debian GNU/Linux, as do quite a few proprietary apps relying on Flatpack. There's no reason why we shouldn't be able to piggiback on this work for the mobile platform. Yes, UI is different, but not that different. Modern Linux apps already come with a touch-friendly UI, for example.
- _bxg1 8y agoAssuming the free mobile OS was Linux-based. And if it's going to be, I don't see why one wouldn't just start with an Android OSP fork. Even if Google stopped maintaining the latter, it's a huge head start compared to the alternative. That said, because of the way Google APIs have extended their tentacles into non-Google Android apps, many of them cease to function without Google Services installed. So you'd still have most of the app ecosystem problem.
- 0815test 8y agoAOSP is way too fragmented. An "app" dating back to, e.g. Android 2.3 (not that long ago), or even as late as Android 4.0 will not even build in a form suitable for a present-day version of AOSP - you have to go and rewrite the code yourself, there is no backward compatibility that reaches that far. Linux platforms are truly mature and can easily run code dating back to the 1980s. Add to that the pointless overhead caused by Dalvik/ART (especially wrt. RAM use - quite critical on a system with no swap space whatsoever!), and the gratuitous differences with widespread Linux kernel and userspace standards. Starting from scratch on a better base is short-term pain for long-term gain.
- zrm 8y agoThough you can just do both. Support both Android apps as well as New Better Thing and then all new apps use the new thing but the existing apps let you hit the ground running.