While Android runs on a lot of high-end hardware, it was originally targeted at devices that are under-powered compared to the cheapest smartphone chipsets now available.
Android also uses implementation approaches like a component lifecycle, the Zygote, and limited per-process heap size that reduce runtime memory use at the Java runtime layer.
The people who designed the Android runtime had also designed the Danger system, which used Java and ran in as little as 32MB of RAM.
While it is possible for an app developer to make an inefficient Android app, it is very likely that core phone functionality, like dialers, messaging apps, PIM apps, etc. are a lot more efficient implemented as Android apps than as Web apps.
Well, first of all Android has changed a lot since those early days. The competition has focused on higher-end devices to challenge the iPhone, not the low-end.
Second, it might be true that a single app could be more efficient as a native Android app than a web app. But regardless of whether it is (and I'm not sure it is - we would need to measure), the issue I mentioned is that Android phones have to support both native apps and their entire graphics stack etc., and the web platform and its entire graphics stack etc. Both because users can run both Android apps and a web browser, and because Android apps can embed a web view, so the combination happens even in a single app.
That fundamentally adds overhead. Of course, in theory massive amounts of work could remove it (you could unify both stacks on a single graphics codebase, and to some extent that is true on Android), but that might introduce compromises as well, and no one wants to compromise the high end which competes against Apple.
The bottom line is that Android doesn't ship super-low-end phones. That might not only be due to technical issues like these, of course.
Those are still much more expensive than the lowest-end. I think they cost around $100 last I heard, and a currency conversion on the amazon link there gives $104, which seems to confirm they haven't gotten cheaper.
If you sort this site by price http://www.snapdeal.com/products/mobiles-mobile-phones/filte... you find the cheapest smartphones are about 1500rs. That's about $25 (according to Google). Most of them run Android. Though, once Windows Phone 10 comes out, I'd be interested to see if that's a better UX at the ultra-cheap end of the spectrum. Nevertheless, Android is currently the OS of choice at the low end, wherever you draw the line on acceptable UX. And the latest and greatest Android is available for about 4800rs, or about $77, running on a quad-core SoC.
As for how that's done, it's because Android can aggressively "swap" (really serialize and reconstitute)background components out of memory, and it can do the same to whole processes. You can actually watch your Android app instance switch PIDs, as it comes back from having had all the components, and the underlying runtime instance, killed. Now, there are some fat slovenly apps out there that might not be happy with life in a very limited machine, but I bet those 1500rs phones push the minimum specs pretty damn hard.
Android also uses implementation approaches like a component lifecycle, the Zygote, and limited per-process heap size that reduce runtime memory use at the Java runtime layer.
The people who designed the Android runtime had also designed the Danger system, which used Java and ran in as little as 32MB of RAM.
While it is possible for an app developer to make an inefficient Android app, it is very likely that core phone functionality, like dialers, messaging apps, PIM apps, etc. are a lot more efficient implemented as Android apps than as Web apps.