How Fragmented Is Android?(eggonomy.com) |
How Fragmented Is Android?(eggonomy.com) |
Has this person ever been around iPhone owners when a new update comes out? I seem to remember a ton of lamentation at every step of slower speed, worse battery, laggy UI, moved features, removed features, and the like.
Yeah, there's a lot of different Android versions out there. Who cares? Other than security updates, it's pretty much a non-issue. Developers target the version they want to support and publish their app online.
Users have absolutely no say! Planed obsolence does.
every single device could be running the latest version just fine. But the manufacturer intentionally decide to not offer (or allow!) the update on not cases.
This is pure greed over consumer rights (or respect).
want the latest security patch on your 2yr old $600 device? too bad, trhow it in the landfill and buy a new one (often with worse features)
Android O, P and Q are 88% of our Android devices. By far and large, fragmentation is something I _never_ have to think about.
Jetpack libraries are here to handle it for us, as an abstraction layer between the OS and third party apps.
I would have mentioned that e.g. camera apps are an exception : here hardware fragmentation can be a pain. I was half surprised to see that Google is also working on that one with the camera x library.
There have been cases where the fragmentation bites us; and there might be in the future (although in all fainess my iOS colleagues sometimes have to create specific fixes as well) but the last time I had to scratch my head because of a device specific bug was years ago.
And at the time, I was already finding these articles deeply ridiculous.
[1] You say that O/P/Q are 88% of your devices but they only represent 38.7% of devices accessing the market (Q doesn't even show up) per https://developer.android.com/about/dashboards. Likely the solution Google has provided ignores a significant chunk of devices out there. When they announce these new initiatives, they tend to support the most widely-used and recent devices while quietly ignoring the rest. A valid strategy, but hardly comprehensive. (yeah, yeah... this time is different)
[2] Technically, they can still access the market, they just can't download anything. Probably either some web API breakage or no longer supported version of something on the device.
He said he targets North America. Those stats you referenced are global.
If he was supporting parts of Asia, Latin America, etc then I have a feeling his team would have to be more careful.
> You say that O/P/Q are 88% of your devices but they only represent 38.7% of devices accessing the market
NO !!
That's the issue with these articles. They just read the android dashboard and pretend that:
- it applies everywhere
- many different devices = difficulty for the devs or users
The dashboard reports the global figures. These figures are heavily skewed by third world countries where old versions of Android are still shipping.
"The market" ... this is absolutely meaningless. If you work for let's say Lyft, the market is wherever lyft can operate, that's not the whole world, so whatever the Android version dashboard tells is meaningless for you or your users.
For our market 88% of the users are O or superior. 6 months ago we stopped supporting devices older than lollipop for this particular app (IIRC it was because they don't support TLS 1.3 and it was giving us some security concerns). For the app I worked on before, we had legacy apks : apks that are still distributed on the play store but that we don't maintain. Basically when we decided to stop "supporting" an old Android version. And by old; I mean Android Eclair; this was a pretty popular app with tons of users on various devices. So we take our current app that still support that old API level. We make sure that it is as stable as we can get it (since we always launch new features, we always have new corner cases, we make sure these are handled). And when it is ok; we set this apk as a legacy one on the play store : if you have one of these old Android versions, you are going to be able to continue using or even installing that older apk. Technically we can update it if we want to, but unless there is suddenly a wave of crashes or complaints we just leave it be.
Even for that app, the figures were roughly the same (and that's while being available in 150 countries, that was for a pretty popular app). For these legacy apks, we often had something like 10k installs, while the main app is in the dozens of millions (but since that app had a paid subscription, make the service work even for old device was a must do).
And yeah, even for that job where we had an app available on API 7+ (Android 2.3 eclair IIRC), the figures were still pretty similar and fragmentation was something I read about in stupid articles, not a part of my daily job. I am not working for Google, if I had to solve fragmentation issues everyday, I would be the first to complain about it. I am here to build an app, not maintain random OEMs hacks.
4.4.x and 5.x can certainly use the Play Store. I use both of those versions regularly, and they still works well (in fact, I keep 4.4.x support, and do not plan on stopping soon).
In Europe, a few manufacturers still sell 5.x devices. In particular, my manufacturer of choice only recently decided to finally upgrade the small tablet / low cost option to give us the chance of having an OS that's not 5 years old on purchase /sarcasm.
May I mention that contrary to iPads, older devices allow to side-load older app versions (that you can easily find online). I recently re-used a 4.0.2 device and installed VLC and Firefox on it (all it will ever need). And for 4.2+, you can just use F-Droid, most apps are going to be compatible.
Just like the "deal of the day" ones that are still being sold across German consumer stores at shopping malls.
I have no interest AT ALL in the manufacturer of the device.
Fragmentation simply doesn't feel like an issue, at least to me.
Then you can't just ignore large percentages of the market.
I still find iOS to be my preferred platform but the “it just works” feeling is no longer there.
Of course if you’re writing manual frame code or using some third party UI library, that’s a very different story…
- native UI elements (labels, text fields, images, listviews, etc)
- images in any standard format (png, jpeg, etc)
- network requests that doesn't fetch more than a few 100kb of data at a time
- simple touch interaction (single item tap/drag/swipe/slide)
- read/write to internal storage
- play audio
...then you're fine and fragmentation is most likely a non-issue. OTOH, if you require
- openGL or 3D graphics calls
- read/write to removable storage
- video streaming, HLS streaming, or even local video file playback
- downloads/network fetches of larger amounts of files/data
- multi-touch UX
- rear and/or front or any specific camera access
- actually any hardware sensor/broadcaster/receiver access (gyro, accel, flashlight, bluetooth)
- OS manipulation (custom keyboard, replace default telephony/texting, modify native modals such as share view, register with the OS as a share-target, etc)
...then enjoy lopping off a chunk of your userbase (which you may have to specify manually, although Google helps with this) or struggling to write lots of OS detection switch statements with custom logic for handling each of these things. Working on an app that does 4+ of the things from the latter list, Android fragmentation has been and will continue to be a problem, even if it isn't really at any given point.
If we just want apps which move blobs of text back and forth between views and across the network, then yes fragmentation is not an issue.
Yes. The backwards sensors in the Nexus 5x and 6 were particularly amusing/irritating: https://www.theverge.com/2015/11/9/9696774/google-nexus-5x-u....
If you can just code for "The 90% with a reasonably modern browser, at least one working eye and JS enablded" then you are in a different situation.
Fragmentation hurts the people in the first camp that need to support 99% or more, for example if you are coding an app for a government service and not for a startup.
The irony, is that Android was originally designed to be a Camera OS. So its still fragmented in the thing it set out to do.
https://www.pcworld.com/article/2034723/android-founder-we-a...
A considerably number of companies have to actually deal with this fragmentation, for example, we have a product that integrates with a device via Blutooth, and we have to deal with this issue. We can't just 'not serve' a bunch of customers.
This is a huge exception that suppresses third party innovation.
https://i.imgur.com/0Ar0ta5.png
My point being: there ARE other iOS versions in use. I have a backup working iPhone 4 turned on right now. It won't upgrade beyond iOS 5 (I think it's iOS 5). But somehow the author ignores all those 0.1% iOS versions, yet shows them for Android (with 4 decimals no less).
Apps don't care what version of Android you run, they care what API support you have, and apps can detect API support at runtime and adapt.
OTOH, the article fails to mention that Apple refuses to let you support devices after EOL, and even some of the oldest Android devices in existence can run even the newest Android, as long as you're willing to upgrade the ROM yourself.
Phone hardware typically is literally falling apart after 3-5 years, any truly old phones are ones that users have chose to keep on life support but not upgrade their ROMs (or made the mistake of buying a phone from a consumer-hostile brand, which is, ultimately, the only valid argument for Android fragmentation).
The only company that is truly consumer hostile is Samsung. And, frankly, I don't know why anyone would buy Samsung or Apple or even Google's own Pixel series... OnePlus charged me $550 for a phone (the 6T) that has the same size screen (and its an AMOLED too), literally same parts, but with more RAM and storage, and a bigger battery, that is otherwise identical to a Pixel 3XL or a Samsung S9+ or whatever top tier extra large phone that costs $800-1300; and that new 7 Pro? Still an amazing deal, and OnePlus supports Android on their phones ridiculously long times.
I can be listening to music on my phone and One+ will just kill Pandora, or Spotify. I have to manually "lock" music apps and workout apps in One+'s task switching UI to keep them from being randomly killed while in use.
Hilariously enough I have one game on my phone that will always run in the background and never be killed, sucking down a lot power. Somehow even when not in the foreground it consumes massive CPU. I don't think it is even malicious, just oddly programmed. I wish my music apps could pull off the same trick though!
I'm having a really hard time understanding this statement. Does the author mean with respect to how updates are handled? It clearly cannot mean in terms of sheer number of installs, Android is clearly _leagues_ ahead of iOS in that regard.
Android doesn't brag it has 75% share. Actual data is that 85% of smartphones run Android and that's market share. Fact that they are not updated to the latest version doesn't change the market share.
Android has its issues, but “math” like this isn’t the answer. This is drivel, really.
Also: See Wintel for fragmentation. Everywhere in nature and tech diversity is good. But somehow not for mobile phone OSes.
It depends on what the cause is. If I have no option to update to a recent version and causing diversity that way, it is bad. If I can choose to install a custom version, it is good. So in Android's case, the diversity is just a symptom of the underlying fragmentation of responsibility for updates.
However, phone manufacturers might see this a bit differently.
For 85$ it ships with Oreo.
That's kind of amazing : for a relatively modest sum, you get a lot of technology.
It makes me wonder why anybody would recommend a costlier device shipping with 4.4
For WebView, Android 4.4 is stuck on Chrome 30/33 and anything older still uses AOSP.
Samsung users often use the Samsung browser, which is often a very obsolete version that came with the phone.
1. https://www.xda-developers.com/google-chrome-android-droppin...
chrome on android is dead to me. so many antifeatures it's maddening.
Fragmentation doesn't bother me. Yes, on some devices the app crashes, on others the sound lag is unbearable. I don't really care, as long as it works fine on most devices. Two things infuriate me, though. Enough to never again spend another minute developing for android.
Every time I enter android studio, it wants to update. The studio wants to update. Suddenly it's incompatible with build system (yes, the build system has dependencies on IDE version!). Then gradle wants to update. Then SDK. Then IDE again. It's never-ending cycle of updates. Each update has 20% chance to cause build errors on this project (Love2D for Android). Each error has a cryptic message, and it's resolved by something completely unrelated to error message. Usually it's solved by bumping up the minimal SDK version and thus cutting off some percentage of potential users. I dread each and every attempt to re-build my app.
The second thing is recent requirement to provide 64-bit version of each app. My app depends on framework written in C++ with additional libraries in C. I can't and won't spend time to get the build for 64-bit version working. Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to update existing app to existing users ever again, for non-technical reasons.
Fragmentation I can deal with. All web developers deal with it daily. But Google's treatment of development is horrible and I don't want any part of it. Because of this I've transitioned to web as platform. At least I can be safe that anything I build will be runnable in 10 or 20 years.
One of the colleague once estimated that just giving a new Android phone to all customers who is still using annoyingly old phone is better solution than supporting old Androids. He calculated the cost of supporting old Android(amount of time wasted multiplies by engineer's wage). He concluded that it's actually cheaper for a company to give every old android users of our service a new phone than diligently supporting old Android versions. Also, it greatly improve the QoL of engineer.
Sadly, our company never executed this plan.
You should upgrade an old device because you need a new feature or you want more speed a modern device can offer you, but having to abandon the device because it doesn't work properly anymore should not be an option you're forced to consider, and that's the point, the vendors do force this upon you to drive their sales.
From these observations, it seems that Android's fragmentation is getting worse, and that newer versions of Android have more and more trouble establishing themselves as the dominant version. In fact, JellyBean was the last version to reach more than 50%.
Any kind of app that's not exclusively targeting emerging markets on 512MB phones will have significantly higher percentage of newer Androids. If you're targeting US, EU, China, Japan, Korea and S. America you'll probably have Androids before 6.x in marginal <10% total figures.
Any kind of app that's being released together with its iOS version will probably have double to triple percentage of new Android versions and pretty much non-existant usage stats on Androids before 5.0.
Those dashboards reflect pretty much no app published on Play store - not even apps like Facebook.
In Germany, on consumer stores at shopping malls you can still buy pre-paid devices with Lollipop.
It's actually _much worse_ than this. Here's a review of the "Samsung Galaxy S10+": https://www.anandtech.com/show/14072/the-samsung-galaxy-s10p...
This "device model" is actually two devices with completely different SoCs. There is no meaningful sense in which these two phones are one device. Sometimes the manufacturers document this, sometimes they just start selling a phone that identifies itself by the same name as an existing phone but with a GPU that has completely different performance characteristics.
Most people update their phones to the latest available version for their phone, so it would be 144 OS-device-manufacturer combos (more or less).
That's a rather dubious view of market share, parsing the definition to include only the most recent version of an OS. Under that mode of accounting, I'm sure MacOS enjoys market share "dominance" briefly after each October update of Windows. But if we extend Android version back just to 8.x then ~46% of all android devices are accounted for, and 46% of Android's total 75% of mobile install base is still quit a bit more than 80% of iOS's 23% mobile install base.
And even that I don't really care about. iOS is a great OS. What I don't like are sloppy definitions and methodology in something that presents as data analysis.
It's a stretch to say each manufacturer that puts what amounts to little more than a custom skin and vendor-specific apps constitutes its own distinct fragment. So too is it disingenuous to represent each point-release of Android as a separate fragment, especially when the author goes on to lump all iOS 12.x point versions together.
I'd also say that fragmentation, in some small way at least, works in favor of android users that have older versions installed because apps can't just target the latest version given that vendors don't push the latest updates to all users. It means older devices can still get many/most new apps on their devices. Contrast this to Apple, where not updating to the latest version can have an impact on app availability much sooner, while updating the OS tends to degrade (in my subjective experience) user experience significantly when you hit the second or third such update. Last time I had to update my kid's ipad to a newer iOS version it basically killed it. It was necessary so she could play minecraft again, but the device became unbearably slow, and minecraft crashed anyway. (My solution was to "upgrade" to an $80 kindle fire kids version, which plays minecraft quite nicely. That I'll admit is absolutely its own fragment of Android though)
For the most part it isn't a problem for us - we require Android 6+ and for the phone to have various sensors.
Some of our customers can't afford the latest or greatest Android devices - that's fine - we will do our best to support them.
Could Android do what iOS does? To a degree yes, they would just have to cripple phones forcing people to make the choice between newer software and a slower phone or leaving something that works just fine as it is....
The reality is that thanks for it being an optional API, introduced in version 7, only flagships have proper support.
And even then, each OEM provides a different version, with their own set of instructions.
Hardly any better than GL ES.
Now they are doing it compulsory on Android 9, upgradable via the store, with GL support being supported via ANGLE.
Guess what, first you need to get a device with Android 9 on it.
This just an example among many others across other API surface areas.
So much for Java on mobiles being too much of fragmented system that Google was going to sort out with their solution, hence the need to undercut Sun.
The fact they made it mandatory and independent of vendor in 9 is laudable. Doing so absolutely costs them adoption of the latest releases but they did it anyway.
When you say "first you need a device with Android 9" that is on the vendors to provide. And the scarcity of 9 can in part be contributed to compulsory Vulkan support. Most of Googles first party phones now run it, even though their general attitude of abandoning 4+ year old products is still egregious.
Like for example, the "PC 98 System Design Guide":
https://www.amazon.com/PC-98-System-Design-Guide/dp/15723171...
Fact is, just get a new phone is not an answer that consumers likes to hear.
Not every country is like US with everyone on contracts getting free replacements every two years.
Many of us enjoy the freedom of pre-paid replacable SIM cards, and use our phones until they either die or get stolen.
In any case, I only used Vulkan as the most recent example, I can give plenty of other ones, and I develop native Android as hobby.
Other Android developers with more in depth knowledge have plenty of war stories.
I would think the real fragmentation that developers have to consider is in things like screen size, or custom APIs by hardware vendors. In my experience, it's the difference between Samsung's bluetooth stack and Android's own
https://medium.com/use-hover/hover-launches-v1-0-stable-and-...
2) It's more helpful to look at aggregations on cuts that will impact your product and codebase. e.g. % of devices above API level 19, % of users with each screen size grouping, what % of our users are on tablets, etc. These answer questions when you should drop support for an API, when you should start using new features, how many different UI mocks you need. Those are the relevant questions.
3) Do test your UX across a couple different phones categories. Samsung & vanilla Android have different button placements and icons.
4) There are plenty of libraries and tools available to handle this problem. I won't say it's not something to think about, but it's usually pretty low on my list.
A new Android device will get one “latest update”. Before the user buys it. After that, it will be just as fragmented as the rest.
So many iOS app developers would use new SDK as soon as newer iOS is out, and abandon existing users who chose to use old iOS. Worse, those app developers would choose to drop old version, release a new version that requires you to purchase again.
Any iPhone released since 2013 - with the exception of the 5C can run the latest OS.
(I suppose there may be a security argument for upgrading as far as possible, but it's not like iOS 7 is up-to-date either. If you're concerned about security, you shouldn't be using an iPhone 4.)
Yes, I realize that as a developer, fragmentation can be more of a pain on Android, but comparing it directly to iOS is comparing Apples to oranges.
However, I still have every galaxy note I have ever owned, working, and in great condition (Note 2, 5, and now 8). My dad is actually using the 5. All of them got upgraded at least once to a newer Android OS and they are still solid devices.
Granted, other than Note, I've only owned a Startosphere for the hw keyboard, so I can't compare it to others, but even after I realized that the Note 8 was crazy expensive and made me double think what my next phone will be, I worry if the longevity can be matched.
Several Galaxy and Note devices also cannot ROM swap at all due to locked bootloaders, which makes that the most consumer hostile thing of all. I'm not sure which models this effects, but it is enough to put Samsung on my forever shitlist.
The upgrades that make the phone slower and slower and remove pre-existing functionality. The removal of Android native features, with replacements that stop working after some time. The severe locking of the phone.
But then, Samsung is far from the only ones doing this. I've personally stopped buying their phones because it's better to buy cheaper stuff and just switch after the manufacturer starts with the shenanigans.
The only way people can beat the 6T and Pixel 3's camera is with the newer phones: the 7 Pro, S10, Honor 20, Mi 9, the Pixel 4 (when it finally comes out) all use the same sensor: the Sony IMX586.
You may be just simply stating you don't like the 6T's camera app... it does low light differently. Not worse, but different, and in my opinion, more accurately. People have put a copy of Google Camera on their 6Ts and enabled the Pixel 3 low light mode (it's entirely in software and not a function of the hardware; change a prop, and any phone gets the Pixel 3 enhancements), and the 6T either performed essentially identically, or slightly better.
The 2012 iPhone 5 is the newest unsupported iPhone. Would you really want to support a phone that old and have to support both a 32 bit and a 64 bit version of your app?
For a developer, there is no difference between a 32-bit and 64-bit.
I would challenge that. I'm still waiting for Android Pie (August 2018) on my OnePlus 3T (November 2016). That's not even two years, and while OnePlus have promised to eventually bring Pie to this phone, it's already almost 9 months late. By the time the 3T is updated to Pie, Android Q will be out.
Eventually I stumbled on the "Lock" feature, which as far as I know is specific to OP, and that solved everything. I'm pretty annoyed with OP about it to be honest. Android has app-specific battery optimization settings built in but they just completely ignored them.
Turns out Android, at least however this app is setup, maybe by default, leaves the app fully running. Like zero effort to suspend it automatically. A part of the UI crashed and a hunt to find the bug made me realize this... I fixed the bug, but still haven't really looked into how to really suspend it.
If I switch from a game to a browser to look something up, being able to switch back to the (paused) game 5 minutes later is a feature, not a bug.
Apps that obey backgrounding and stop doing work (e.g. burning CPU/Power) are fine.
Oreo and the /vendor partition may help with this some. Still, it's a far cry from the Linux/PCs days of the 90s. I've written about this before:
Sounds like arcade cabinets. Maybe we need something that does for Android ARM devices what MAME does for those: specifies each device as an abstract wiring diagram of pins to bits of patched kernel acting as ROMs. And then make that whole thing into a kernel virtualization-provider module, which uses the stock kernel for anything not masked over by ROMs.
(Also, Wintel machines are very much random pins soldered to random crap, they just do a better job papering over it with ACPI AML bytecode)
If I buy a Dell laptop or a Lenovo laptop, it will come with a bunch of useless junk installed that nobody in their right mind would ever want, like Lenovo's useless gigantic Wi-Fi icon in Windows (last observed by me in a T520). But not only can I uninstall all of that junk software, I am still running real Windows. And that means I can update it normally.
Compare that to an Android device. You get a phone from a company like Samsung and you cannot uninstall the Facebook app no matter what you do. You get a phone from HTC and maybe they decide to push an update from 7.something to 8.0 and 8.0 introduces a new issue. That is fixed in 8.1 but you can never actually upgrade to 8.1 because it's not the real version of Android it's the HTC version of Android and they have ordained that your device shall never go past 8.0 and they pushed some firmware "security" update that prevents you from installing any other OS on your device. Additionally, some software seems to be dictated by your mobile carrier, which would be like allowing Comcast to control what you run on your PC.
So whatever fragmentation there is on Wintel (or LinAmd), it is not nearly as hostile to the user as the Android ecosystem.
To be clear, I don't think this is a failing of open source. The problem is that Google allowed phone manufacturers to release practically anything they wanted based on the Android code base under the name "Android" and to ship with the common market (Google Play).
Frankly I don't think they should have allowed any modifications, making Android closer to how Firefox is distributed. (Anyone can edit the source code of Firefox, and even release a fully built binary based on that edited code, but you can't call it Firefox.) Maybe fewer manufacturers would have bought in at the outset, or maybe some would have tried to fork Android, but it's easy to forget what a desperate situation they were in. Outside of Apple and maybe Blackberry, the mobile OS market was in shambles because nobody was ready with high quality smartphone software. Android was a huge win and probably saved multiple companies from bankruptcy, and I think they would have eventually bought in to a more strictly defined OS out of necessity.
Isn't the reason entirely technical? 64-bit apps can use 64-bit only instruction sets, which are newer and usually faster, resulting in a performance improvement. BTW, apple did the same thing years ago on iOS and is planning to kill 32-bit apps on MacOS soon.
Apple did this years ago.
I'm complaining different issue, though. I researched the platform requirements before investing time into android development. I shared my work for free because Google doesn't allow developers in my country to charge money for their work. I kept updating the app following the user feedback. I will lose the product because of this. This feels like rug being swept under my feet :(
So the "non-technical" reason here is that you don't want to provide a build for users with 64-bit devices?
I don't care about 64-bit devices. I'm fine with them not being able to install or run the app, if that's how it is. People with 64-bit devices can easily afford better products that my app tries to replace. I don't own device to test the 64-bit version, and I don't know anyone who does.
I care about existing users. I kept minimum SDK version as low as possible so that my app might reach all the cheap phones in poorer parts of world. It actually works today across many different devices, so what has changed?
Xcode is always bumping versions too.
> The second thing is recent requirement to provide 64-bit version of each app.
iOS had this issue too.
FWIW, Apple did exactly this a while before Google did.
And as I replied to another comment, that is only one example among many.
I could write about Java 12 support, audio API, the constant changes in background processes, the multiple reboots on the UI framework, how NDK is handled and plenty others.
So very much a mass market product :)
As stated above, what we did was that when we decided to "drop support" for an API level, what it meant was that we would freeze an apk that would be delivered to these older devices and have a higher min api level for the new app versions.
The burden might higher on the backend people not to break the old endpoints than for us.. these old apks need to continue working. Technically we were supporting these frozen legacy apks, but since we have chosen particularly stable app releases for this, in practice we never touched them.
Weird corner cases/devices were indeed a bit more of a concern. And to be explicit, that was never a significant amount of our time. I was part of the more senior team that had to (among many other things) deal with that, and I don't think it has been more than 5% of my time (and 5% of the time of 2 other colleagues, whereas the 20 others not in our team did not have to deal with it at all).
As far as I can tell it is the result of :
- at this scale, if something can break, it will break. when you have millions of daily users, all of your app issues will be uncovered (and to be honest, there was a ton of these... we inherited some very awful code in some crucial areas)
- mass market means that you will see all kind of devices connecting to your service, including weird no names chinese devices that have not been certified by google. So they did not have to pass the compatibility test suite that devices shipping with the play store have to satisfy. This has been getting better and better year after year but at first you could see some "exotic" behaviors.
- mass market also means that people will try everything in order to use your product for free. Although to be honest 99% are refreshingly naive. Like somebody distributing a "cracked" apk letting you get one month of premium for free. We decompiled that version and could not figure out what had changed .... until we tried it and.. oh man, so that "hack" is just that we we offering a one month free trial at that time .. Nothing nefarious here, just the same free month you would have gotten for a new account by downloading the official apk from the play store.
That's an interesting way of thinking about it, getting 20% of 100 is more than getting 80% of 10. I think the problem you'd run into is that some users with androids would be upset they can't install your app when their friend that has an android can install it just fine.
Sure. But if you are making an app for say a government service that has as a requirement to reach 98% of mobile users, and you reach the goal if you count compatible devices (not people who choise not to upgrade) then it helps.
To be fair, one is not entitled to free upgrades forever.
The bootloader, knox, e-fuse thing I agree is consumer hostile. They are free to ship them locked but should include an override option for supposed owner of the device.
Could Windows 95 run on a computer from 1985?
My 2009 era Core 2 Duo Dell E6500 - that I still own (https://www.notebookcheck.net/Review-Dell-Latitude-E6500-Not...) had 8 GB of RAM, gigabit Ethernet, a 1920x1200 display, 160GB hard drive, etc. Besides the processor, those are still decent specs for today and even the processor is good enough
The iPhone of 2009 was a 3GS - 320x480 display, 256MB of RAM,802.11G, with a single core 400Mhz processor and slow video graphics by today’s standards.
Compare that to the specs of even the low end $475 iPhone 7.
The Core 2 Duo was already a 64 bit processor. The iPhone didn’t ship with a 64 bit processor until four years later.
For hardware, I believe that 100%. I am talking about "regular" android apps that don't need deep access to the hardware. By deep I mean something harder than recording something (e.g. taking/picking a picture is delegated to the default system app, not the one you build) or displaying the current position with a mapping sdk.
Bluetooth in particular I can believe. It is amazingly complex and adding the OEMs customizations on top must be a total pain.
It still misses the whole point though.
Again, the global numbers are pretty meaningless for app developers.
Even if your app is called gmail, at some point you will see that you have 0.01% of your users on a very old version of Android. And you are not going to cut them off, just freeze an apk that will be their last version.
And for almost all apps, your useage stats won't look like these global numbers.
We are doing everything we can to increase our user numbers .. if it meant lowering the min supported version, we would do it but it is just not something that would help us.
However, as with the arctic machine, the incentives are misaligned - they actively don't want to be commoditized.
A mid range Android phone CPU will choke quite hard on modern Javascript-heavy web pages. Now think about a low range phone...
Contrast that with the world of PCs where I can still run recent versions of Linux on devices 10-20 years old.
The iPad 3 was quite problematic as a device in that it was very RAM- and CPU-limited. With a 1GHz dual-core A9 and 1GB RAM, it was not going to handle future iOS updates well.
The next version, the 2012 iPad, runs iOS 10 and is still useful -- I still have one lying around for when I need an iPad (and I do have 1Password on it). And the 2013 iPad Air runs the latest iOS and I expect this to continue as iPad tech plateaus.
Lack of OS updates isn't unique to Android, but Android manufacturers collectively have a very blasé attitude to updates, much worse than Apple and Microsoft.
[1] https://discussions.agilebits.com/discussion/comment/408090/...
It looks to me like for the past 3 years every single mobile ARM CPU released has been 64-bit, and even for 2 years before that roughly half of them, the market share of these must be much larger https://dev1.notebook-check.com/index.php?id=149513&sort=&ty...
And since Android 1, have made OS updates a requirement of the Android licence contract for Google services.
> made OS updates a requirement of the Android licence contract
Now you're being contradictory. You want to force manufacturers to always update to the new Android versions. But you ALSO want to make Android 7 require specific hardware features. How could these requirements work together?
With care it is possible to make mobile web apps run at a reasonable speed even on low end devices. I personally like to aim to make things work OK on shitty old devices, that way I know it works well on newer devices. Also our code (custom) was originally written for IE6 so we started light, which helped.
A framework that appears to be good on low end devices is svelte.dev: "Last month, a developer in Brazil shared that [Svelte is] being used for point of sale systems in Brazil. There are like 200,000 of these devices in the wild. His job is to build this interface for the point of sale system. They're working with a very outdated version of WebKit on extremely memory constrained and performance constrained hardware. They tried a dozen different frameworks and none of them were up to the task. You would press a button on this interface and, half a second later, it would respond, which is kind of an awful user experience because you're more likely to press that button twice and end up overcharging your customers or something like that. They tried it with Svelte and it worked smoothly, so that is an example of what you can do when you have a framework that has a very, very low memory footprint and very good performance. Another example, we have a guy using it in the context of smart televisions, which also tend to be quite constrained devices." From: https://shoptalkshow.com/episodes/349/
Those minimum requirements aren't set in stone, and OEMs seem to comply with them, strangely.
is in direct disagreement with
> Have made it compulsory on Android 7
which is my point.
OS updates always work with fallbacks, and minimum hardware specifications get revised every few years.
Google can ask Microsoft how to do it.
But, big but, the OEMs are free to decide when and how those updates are made available to users.
10 sure, but not 20. 20 years ago the devices had 32 bit CPUs, the support for them is being phased out. The last 32-bit Ubuntu LTS is 16.04.6, from 2016.
While you might not get the latest kernel with it, as far as I can tell, there is nothing in its package manager that doesn't run on hardware from 2016. Unkike typical Android devices from the same era.
Right, but 20 years ago was 1999. I won’t be surprised to find out many packages won’t work: that CPU doesn’t have SSE2, the RAM limit is 512 MB, and typical systems usually had 64 or 128 MB.
The official page says recommended minimum requirements for Ubuntu 16.04 are 2 GHz dual core processor with 2GB RAM. 20 years old PCs don’t fit.
Yes. But I think it’ll only a matter of time before they stop, too.
> using 64-bit has little value if you have less than 8 Gb of RAM.
Address space brings much value. No need to worry about address space fragmentation, also you can safely use memory mapping, even for large files.
Extra registers also very nice performance-wise, both general purpose r8-r15 and vector xmm8-xmm15.
Finally, when you code AMD64 you can rely on having at least SSE1 and SSE2 SIMD, their support is a requirement.
Same happened with mobile devices, where designers and manufacturers were looking for the ideal recipe of a mobile phone.
I got my daughter a newer device later that year, so don't know if it still works. I've lost track of it again.
It will probably take at least 5-10 years before all major distributions will stop and their support periods will be over.
Once we are there, there is still NetBSD and OpenBSD. Heck, NetBSD still supports VAX.
I wonder about the level of VAX support. Do they just have old code lying in the repository, do they build it, or do the devs actually have a working VAX machine and they test new builds?
a) build.sh allows cross compilation, which helps with build validation (although openbsd built native until they dropped vax ~3y ago)
b) there are a few dedicated devs on vax. these pretty much do the work as a hobby, and things are best effort, but generally in sync with the rest of the tree. most of these own a vax or three, but you can also run on SimH and probably other vax emulators.
c) really, the system source is modular enough that adjusting device drivers for well documented hardware which has existed for years, and tweaking a few already-implemented since the 80s macro primitives is most of what is needed to keep things running -most of the adjustments to the system itself happen higher up the stack (e.g in the generic c portion of the kernel, or in the c library). Granted, this does mean knowing the ISA and HW in and out, and having skills to debug/reason about low-level instruction/hardware sorts of issues, but, hey, that's who codes open source os'es anyway.. Besides, if you are a true VAX BSD UNIX hacker, you've been tweaking your kernel sources since you manually toggled in the 3BSD bootstrap in 1979 :b
