Part of the problem is that Google remove the interpreter of Android so and AOT codes creates big executables which need to be loaded in memory.

Part of the problem is not Google but the fact that application makers test on flagship phones Pixels, Galaxy etc.

Part of the problem is that Google waits too long before introducing Go edition (available since Oreo) which re-introduce the interpreter and provides a clear target.

Part of the problem is that low cost smartphones is not where the money is, so there is no real insensitive to target low cost smartphones.

I think what we should do is make their carbon footprint tally include their shitty javascript all over the internet and their apps on phones.

They used the VM approach for security reasons, which to me is terribly wrong. Mobile terminals should have hardware separation between subsystems, that is, the sensitive stuff (radio) enclosed in black hardware boxes where data goes in and comes out, just to make telcos happy, but everything else -I mean all the OS and apps- should be native and user accessible. This way one gets the best possible performance while maintaining a high degree of separation between kernel+userland and radio chipset which would let allow hacking whilst preventing anyone to tamper with cell connectivity.

Not using more hardware resources than reasonable has stopped being a thing. A large section of software writers behave as if that the only purpose of the hardware is to run the app they wrote.

https://www.android.com/versions/oreo-8-0/go-edition/

Software development is always a tradeoff between development time, features and performance optimisation. You can add more features in less time if you aren't too worried about performance. Most mobile developers neglect performance for simple financial reasons - it's an unfortunate fact that developing apps for low-income customers isn't very profitable. A user with a ₹4,000 Micromax phone probably isn't going to pay ₹200 for my app, but a user with a ₹60,000 Samsung phone might. No matter what Google do, a lot of apps are going to perform poorly on low-end devices.

https://developer.android.com/google-play/guides/android-go-...

They're aimed for lower spec phones with slightly reduced functionality, but still official / good quality.

In reality, this is expensive. Couple that with the fact that people who use low cost smartphones are not going to attract big capital, and thus they are left with average software developer.

https://en.wikipedia.org/wiki/Google_Fuchsia

Low memory optimization means switching from a copying collector to a simple mark & sweep collector. It's entirely up to the vendor to configure that JVM collector. Nokia does so I believe.

SW bloat in apps and bad config tunings for autocompletion and other user configs also lead to bad UI responses on low-powered phones. Google is partially doing the right thing by providing all the frameworks by itself leading to reduced bloat. You just use the default library, in shared memory. But a problem is of course Google removing the interpreter, costing a lot of discspace and memory.

But if you really look for low memory languages, please try Forth https://www.forth.com/forth/ or Joy https://hypercubed.github.io/joy/joy.html. They may provide interactive environment in as little as 2kB https://www.mpeforth.com/xc7.htm#umbilical, and interactive debugging for deep space probes https://www.forth.com/resources/space-applications/

The only thing I saw Android doing was 'Android Lite' which Nokia plans on supporting only Android Lite. I too wonder where Google is going with Android, but I fear as many have suggested they only care about using it as a means to track people and lock them into their own services... Sadly Android could be so much more and they clearly have the resources to make it so and yet... Nothing.

I would love to see Microsoft take Android OS fork it and make something that isn't a Memory hog and conserves on energy someday.

If MS forked Android, made it snappy while keeping it compatible with existing apps, and if they did their marketing correctly I could see this carving a small but profitable (for some value of profitable) niche.

That's assuming Google has some interest in not making it as snappy as it could be. I don't see what the reason for that might be.

I rather think we're talking about trade-offs here, the prime one being breadth of app selection vs quality of apps.

But any new Android fork would have to prioritise breadth of app selection as that would be the first question buyers would ask. Can I still run all my apps?

If they cut the revenue share to, say, 10% (or a fixed fee + 5%), then it wouldn't take long until all Android apps are available on the Windows store as well.

Electronics works at different economies of scale than websites/web applications/saas, where usually (at least at the beginning) you will probably churn out bloated applications to "go fast and be lean" and say who cares since you can just relatively easily bring in another 64GB VM.

If you need to produce 10 million units spending 0.1$ less on each unit is a godsend, you instantly have 1 million dollars more for R&D (and/or possibly profits).