* apps can't simply access the "external" storage (enforces scoped storage)
* apps can't get a list of all installed apps (package visibility, they can specify app names and intent signatures in the Manifest they want to query)
These are welcome changes in my view, but unfortunately they also seem intend to fix SafetyNet and require hardware attestation that the bootloader is not unlocked . When this is enforced for all devices some apps, like the eBay app, won't run on unlocked devices anymore. I've always trusted CyanogenMod/LineageOS more then than a device manufacturer, but after >10 years of using Android I think it's finally time for me to switch to an iPhone.
I'm not trying to go inside Android vs iOS rabbit hole, as it's common knowledge that android's default privacy features pale in comparison to iOS.
But in Android you can leverage the trust of an individual app publisher as well and not forced to 'trust the manufacturer'.
Tasker is trusted, it can automate workflows unimaginable in an iOS ecosystem and when Google's API changes broke some of its features; Google listened to the community and whitelisted it.
Don't trust default messaging app? Let Signal handle messages. If there's an SMS based exploit, rest assured Signal update to patch that would arrive faster than android update.
Got 7 year old android device, which hasn't received any system updates in say (cough) 7 years? But you only use it for web browsing, you can still use latest Firefox for android(with its own engine). Which will support latest PWA API.
This can go on and on without rooting android; none of these would be possible in iOS at least not until jailbreak(which compromises security akin to rooting) and probably until Apple steals couple of tricks from the jailbreak community.
Finally, If you are talented but poor developer from a village in India/Nigeria/any other place you can develop a PWA web app on a Raspberry Pi and release it for the world to see without any additional charges and probably profit out of it; It would work fine on Android, KaiOS, perhaps upcoming suite of pure Linux smartphone OS, but if you want it to function on iOS you'll have to invest hundreds if not thousands of dollars in equipment, pay yearly $99 fee, develop new native app with probably a new programming language, Give 30% cut to Apple when you make money out of it.
(also, iOS Safari has limited PWA functionality. It’s by no means as comprehensive as Chrome / Firefox on Android, but it was enough for me to make my latest site installable.)
Not a troll, I'm really curious.
I love most things about iOS design more than Android, and I've used both, but have stuck with Android over the last 7-8ish years. Mainly because of the amount that I could customize things, freely make little app projects, install custom ROMs, etc. Over the last few years, it's gotten inconvenient to tinker, and I just don't find myself bothering with it anymore. I've run into issues where certain apps stop working because of root.
But also both OS's have gotten much better and need fewer (if any) tweaks anyways to be used effectively. Especially with the upcoming change to allow iOS to use a different default browser (finally).
If the main reason I've been drawn to Android is vanishing more every year, I'd rather use the more elegant OS (Apple), regardless of how closed it is. I have a Pixel 2 that's getting near EOL (only 2 years after buying it), and I'll be getting an iPhone SE as soon as I can justify spending the money.
I guess something that helps too is I've been on a de-googling kick these last few months where I've been switching off all their services because of privacy, another benefit of iOS to me
I get to use Firefox, it comes with nice tracker blocking out of the box, it keeps my history in sync with my other devices and I find the UI to be a little nicer (personal taste).
Of course I'd like the Firefox that's available on Android, with extensions capabilities and web push support. But having the ability to open links from Mail in iOS Firefox would still be nice and I can't wait for it.
Neither situation is perfect, but the browser's rendering engine is surpassed by other priorities when choosing a phone.
I do look forward to the day I can use something like Pine as a daily phone though
- Extensions support, so uBlock Origin, Privacy Badger, the best ad-blocking combination that far surpasses Safari's content blockers, which are pretty shitty; and extensions are useful for more than ad-blocking — e.g. I have another one on my tablet that turns all web pages to dark mode, whether they support it or not
- Web push notifications
- (Up until very recently) webp format support
On Android I wouldn't even install many apps, like Facebook, or Twitter, or Fastmail, I'd simply use them as PWAs (web apps), in Firefox with ads blocking on, because I could.
I still use Firefox on iOS for the history / bookmarks syncing, but it's a shadow of actual Firefox.
Except that for many/most people it's equally important to have a market choice which drives product improvements by competition. Not being able to choose a fully opensource browser engine (not even Firefox!) on iOS is a severe blow to opensource as a whole and browser engine competition in general. It's way worse than it ever was in times of IE6 - you never needed Microsoft's private signing keys to switch to Firefox or Chrome.
You seem to state it as a fact but I believe it is your opinion .
- OS Frameworks are not designed for the next year's IO, rebooting last years best practices, rather have long term roadmaps.
- The build system has stayed mostly the same, instead of having had multiple reboots
- C and C++ are integrated with the rest of tooling instead of feeling like an burden that has to be supported to keep game devs happy
- Everything that matters on iOS development is available in XCode, instead of being a mix of Studio templates, stuff dropped in Github that we are supposed to build ourselves and apparently official APIs (e.g. Oboe, Vulkan)
- Back to frameworks, while iOS offers high level frameworks for common workflows, Android offers Lego blocks that everyone fits in different ways with lengthy discussions on what is good Android code, MVP and whatever is the fad of the month on /r/androiddev
- When Apple does game development sessions, they actually talk about game development tech and do provide related tooling, Google talks about Play Store console and advertising for gamers. Notice that main GDC 2020 theme for the Google talks was to try to show that they are listing and trying to change, pity it came 10 years later.
- Most APIs in iOS seem to have had some though placed into them, in Android you have stuff like Animations that have had multiple instantiations, or others that have deprecated stuff even before reaching a proper release.
- When Google decided to drop Eclipse they had nothing to offer for NDK devs, almost two years later JetBrains decided to create CLion and then they had a solution. Otherwise most likely there still wouldn't exist an alternative to this day.
Did you leave a word out here?
I assume you were going to write default keyboard?
I also have to say that to me, even if apps that require SafetyNet don't work anymore after unlocking, it certainly doesn't make the phone certainly useless. But I don't want to live with the inconvenience of not being able to use some random apps.
I went to Windows Mobile for a while, it had more apps than a non-Google Android phone as it was, but obviously that's dead now as Microsoft has left the consumer space and literally told everyone to go buy Android phones.
Until antitrust happens, iPhone is really all that's left. I've got a PinePhone too, and I'm pretty excited about it, but it'll probably be a while until it reaches Windows Mobile-level of app availability. I've been pleasantly surprised by Apple's pro-privacy moves since I bought it, and if they're opening up changing default apps this year too, really the most problematic limitation is going to be gone.
This is an interesting experience in what a fully functional phone not from Google/Apple can be like. It may not be able to run the usual apps though, unless you install the playstore manually.
As a citizen you have rights guaranteed by the law in your own country. That's the very definition of citizenship. As a citizen you have leverage over your government, even if small, because you can organize yourself with others, e.g. in class action lawsuits, you can vote, you can convince others to vote, etc. Foreign governments and companies couldn't give a shit about your rights, the only rights you have are those defined weakly by trade agreements.
Not only that but data can be traded or leaked. A foreign company thousands of miles away, collecting data about you, could always leak that data to your local organized crime organizations.
N.B. I know that big companies like Xiaomi also have a presence in the US. With a big enough presence, the US government could coerce them just as easily, so if you fear the US government, it's a double whammy.
So this is a non sequitur. Even if you fear the US government, as a US citizen, you should either pick US solutions, or solutions from countries that have a culture and laws for preserving privacy, such as Switzerland or Germany.
Frankly as a US citizen picking products and services from a country with disregard for basic human rights, because you don't trust the US, is just stupid.
True except for some people like protesters or whistleblowers who do not enjoy "rights guaranteed by the law", or at least not reliably.
> Even if you fear the US government, as a US citizen, you should either pick US solutions, or solutions from countries that have a culture and laws for preserving privacy, such as Switzerland or Germany.
Are you aware of any smartphones from those countries without involvement of Apple or Google?
The only difference here is that in Android you can actually separate the two.
>Although most microG components are far from complete, users are amazed by the results.
What users are amazed by what results? And if you read this carefully, it clearly states its missing swaths of the APIs, so its not 1 to 1 compatible and is very likely out of date in at least one reimplementation, per this :
>This is alpha-grade software and not yet ready for production use. Do not use if you don't know what you're doing.
I don't think this would hold up to being what I'd use as a daily driver. I just want my phone to work not fiddle with troubleshooting weird edge cases for apps I want to use.
I applaud the project, but its hardly a simple as saying 'you can replace it' and that's the last you'll have to think about it.
Is its source code available (including for any TrustZone component), maybe as part of AOSP?
I am OK with the concept and I can value it also as a protection against advanced malware, but only if it is totally transparent (to me!) what data it collects and relies upon.
I'm actually fine with that.
I didn't realize it was such an issue. I'll make a note to investigate how difficult it is to migrate away.
The number of times I’ve been laughed out of a product meeting because I’ve advocated for making decisions that don’t require the apps I’ve worked on to be run on google play services systems... it makes me wonder what is actually important in our industry. It’s certainly not the user privacy, freedom, and advocacy that everyone seems to be milking these days... sad times.
Sadly, it's exactly this. It's not for your safety at all. It's for keeping stuff on your phone safe from you.
This seems like a weird policy, though. I can access my bank via a web browser on a desktop computer, which is certainly not even remotely a "pristine, locked-down platform".
Root exploits more common, but bootloader exploits aren't unknown. String them both together and you can remotely root a device, unlock the bootloader, install another OS, and relock the bootloader. All of this without removing apps or data; do it properly (custom recovery for flashing the new OS) and all the user knows is that the device wasn't working for a while (until they notice the giant new notification Google services puts up now, but some users don't even know what notifications are and either won't notice or will ignore it)
Imagine manufacturers having the incentive to issue monthly security updates, else their users get very angry they can't watch Netflix/log into their bank app/use google pay...
Moreover Google devices are the most open modern mobile devices out there now (I am intentionally excluding Librem5 and Pinephone). That is because on a Pixel you are allowed to relock the bootloader and load an image that you self signed!! This has spawned a niche ecosystem of android forks on pixel devices (look for RattlesnakeOS, GrapheneOS, CalyxOS).
E.g. there was a long time after Apple introduced push messages where iPhone battery would drain pretty fast because many telcos would have very short connection timeouts on their routing equipment. This forced the phone to wakeup the radio a lot to reestablish connection.
This was "fixed" by whitelisting Apple/Google endpoints, so I wonder how that would work in federated environment.
Perhaps, but if you can tolerate some latency, you might not have to wake the radio all that much. A huge majority of notification use cases can be delivered "late" (at least if the phone is in sleep mode) and still be useful.
This is extremely valuable in reducing power usage.
(Notifications both exhibit radio usage, but also will typically turn on the display, which is a huge battery sink)
There is a nice model for federating push services, and it worked. If you give apps a push "token" that takes the form of a URI or email-like address, the token can be namespaced by the push server provider. That can be self-hosted. An application can send push messages via websockets or a similar transport to the user's token-defined push server, and the user's apps can listen to it.
The long and short of it was that an app implementing the "push client library" would be able to do push messaging in a power efficient way, and it meant you could still only query 1 source server, that was configured well for long-lived connections. The trade-off is that you need app developers to really want to use it, and be willing to send the push messages to servers identified by the push token/URI.
I really don’t understand why mobile OSes don’t just adopt the Push API wholesale. Android especially. It’s such a mess having each app do its own thing and then have all kinds of problems with power saving measures; why not instead let the OS declare the push service to use (Google phones use FCM, Samsung phones use a Samsung push service, &c.), and apps just use what they’re given?
That would be a killer app for IPv6 if mobile networks were up to it...
The android ecosystem is toxic to the point where software developers are raging a war against their users.
Luckly there are still projects like lineage and microg where the software is still under control of their users, but google is slowly plugging the holes.
I hope that the true linux on phones (pine?) will emerge and stop this exploitation of user rights.
Then your banking app won't be available at all.
So how will perfectly valid use cases like file manager or backup manager work now?
However, this will no longer get you access to Application's own folders, and so backing things up on Android gets even harder and the OS gets more anti-user.
(To be clear, this should absolutely be behind a Permission barrier. But to block off user access entirely is a toxic and unhelpful move that makes the platform less useful).
So much the worse for Android.
> Note: The MANAGE_EXTERNAL_STORAGE permission allows apps to access potentially sensitive data on shared storage. In an upcoming policy announcement, look for Google Play to provide guidelines for apps that need this permission.
Ok, maybe that's more my hope than my guess. We'll see.
Enforcing SafetyNet is probably also a net positive change, and you (and I) are a minority among the general user base. Sadly this was always coming, it was nice while it lasted, I guess.
I'm not quite sure what I will do once my current phone dies. I don't see myself investing in the Apple ecosphere, so either go with the time (do nothing) or have a second phone for "secure" apps (Banking, Netflix) etc.
How so? How does SafetyNet make any end-user even slightly more secure?
It does provide major benefits to app makers who hope to control the user's device.
However, most people do not unlock their bootloaders and install custom ROMs.
For them having an unlockeded system is an indication of something "bad" happening (spying, fraud, theft) and given how central smartphones are becoming in users life, I prefer that my mothers banking app refuses to work if her smartphones chain of trust is compromised.
I also happen to believe that it is impossible to "out-tech" OEMs in the long run and that the path to a fair app ecosystem is through legislation, regulation and anti trust measures.
That approach worked in other aspects of the economy and society.
In real life, the main security issue on smartphones right now is dubious quality stock ROMs and checking the bootloader won't help you with that.
The move should be in the opposite direction, it should be impossible for security reasons to query if the bootloader is unlocked or not from the device itself.
I'm all for more security measures, but not at the cost of giving up my freedom entirely.
Why this would be a useful benefit worth setting up in an SDK across multiple companies and apps, I'll leave to your own imagination.
Will this change make it look more suspicious when apps request access to photos instead of storage? Yes, sure. Will most users care about it and deny access to apps that aren't supposed to have it? Of course not.
The problem with unlocked devices is that it's a legitimate security risk.
With a signed OS and hardware attestation, you can verify with 100% certainty that the foundation of the device's security model is there and fully intact. Upon that foundation you can build features that you might not be comfortable with otherwise, like an OTP app, authenticator app or a payment app. You wouldn't build an "OTP" app for Windows for example because Windows doesn't have a solid security model, it's quite easy for one application to access another application's resources.
Once that foundation is broken, all bets are off. If the bootloader is unlocked, you have no way of knowing what's running on a user's device. For all you know, all of the permission checks have been removed and nothing is secure anymore. Even the APIs you'd expect to interact with a secure enclave could be replaced.
Others are suggesting that this is the user's choice and so perhaps developers should just deal with it but I disagree. A device isn't necessarily unlocked by the user. A device can be unlocked by anybody with physical access and the passcode. For example a malicious party could install a malicious version of Android on your device if they have unattended access to your phone for a while. They could also buy phones, flash malicious versions of Android and then sell them at a slight loss, making profit off the money stolen from their victims.
There's also the problem of malware that gains root privileges. With a locked bootloader, there's limited opportunity for such malware to become persistent. It can't modify the system partition at all. With an unlocked bootloader, it can modify the system partition and permanently modify the OS. Basically, locking the bootloader prevents rootkits.
This is why these features are here. They're not here to make enthusiasts' jobs harder, they're here to provide a solid foundation of security upon which an OS that's secure enough to handle high-value information can be built.
> When this is enforced for all devices some apps, like the eBay app, won't run on unlocked devices anymore.
In some cases (e.g. games), I think this is ridiculous. For apps that deal with finance or other sensitive areas, as explained above, I think this is entirely reasonable.
All that said, I can see a world in which we have custom ROMs as well as security:
- We make custom signing keys  commonplace, not just a thing for Pixel devices.
- Set up an automated service through which a device can submit CTS  results and have its build of Android whitelisted.
Tagged releases of AOSP are the same base code that all the retail distributions of Android are based on, so should be just as safe.
If you have a Pixel device, the RattlesnakeOS project  will allow you to run your own automated AOSP distro, complete with OTAs, on AWS. It also supports adding a few modifications like MicroG.
All but the most recent Pixel devices are also supported by GrapheneOS, which is a security-focused ROM.
Both of these projects support signed builds, so once you flash them to your device, you can lock the bootloader.
This wipes all existing data and notifies the user that the device is not secure whenever it's booted. There's no way that a user would fail to realize this. I agree that it's unrealistic to expect apps that directly deal with money/finance/etc. to be supported on unlocked devices, but aside from that it should be fair game.
I think you place far more trust in an average user than they deserve. If a user saw that their phone was factory reset and had a scary warning, I can easily see many users happily ignoring it and setting up their phone again, assuming it was the result of some bug.
The more tech-savvy HN crowd might be worried and flash it with fastboot to be safe but don't expect that of a random average person.
General computing is waaaay easier today than ever.
That sounds doubtful. What kind of "phones" and what kind of software does the Swedish government require you to use?
Note that I agree with your general point of locking people and power users out of the hardware they are supposed to be the owners of, it's just that part that kind of detracts from the point (I'm going to go ahead and assume phones and software are not actually required).
There is no linux version available (there used to be a few years ago IIRC), and using U2F or other security devices via open standards is not supported.
It's a pretty OK system (for most people) made much worse (for some people) by not supporting standards they should have years ago. Yubikey is a swedish company, BankID is a swedish company, they both deal with identity online, how they have not actually managed to interoperate is beyond me.
Basically it's a system that caters to the masses and does a pretty good job at that but it's very bad for the non-technical (who don't have a smartphone) and the very technical (who might not use the OS'es that they support). I expect more from a system that most people use to pay their taxes.
There are also any number of security questions from the above, but I'll refrain from those.
This comment of mine did not age well: https://news.ycombinator.com/item?id=23560040. I'm curious what the performance impact of the change was?
Really, you just asked a legitimate question, and now today you have a legitimate answer. I'd call that a win!
* rsync (backups, pulling audio files, pushing pictures)
* git/hg (all my notes live in a repo)
* random scripts (ex. When I was losing weight, I tracked calories with some shell scripts. I also have one that uses root and /system/bin/input to automate things.)
* ssh for shell access
* socat + dynamic ssh port forwards
* access android APIs 
* general scripting, also using +
* backups (rsync, pigz)
* ffmpeg to transcode .mov to mp4 from a digital camera on the go
* openssl to debug stuff/inspect certs
* dig for checking dns
Half-jokes aside, keep in mind you can use small Bluetooth keyboards and get a micro-laptopish experience, or connect the phone to a monitor or TV and use a large Bluetooth keyboard to get a more desktop-like experience.
I imagine a terminal could work very well in those settings, if you need one.
Any app that access the Linux features directly just works out of luck, given that there are no compatibility guarantees.
Basically anything Android native is horrible for developers; you can't even get a decent IDE or text editor. You still don't have source control, web servers, programming languages, etc. Termux with a few addons gives you all that.
I wish Google would recognize the value of a real Linux/Unix environment the way that both Apple and Microsoft have in recent years.
Coding on Nokia Communicator (even the latest versions) or Nokia's Linux based phones/tablets was also not the best ergonomics.
Also I don't care about having a Linux CLI or something like Termux, any kind of devenv is ok for me, so to extend my list, if you want to develop Android apps on S6, then install AIDE- IDE, it will surely appreciate those 8GB.
If none of them are good enough, it is like my business professor used to say, market opportunity.
I also own a tablet with keyboard, by the way.
More Playgrounds, less POSIX CLI.
Our hardware is now powerful enough to support all computing models in whatever sandbox you want. There's no reason I have to give up my POSIX CLI. Personally I'd prefer Android native GUI software capable of interfacing with a Linux technology stack that can run programming languages, web servers, etc. This should be obvious and yet somehow it's not available.
No market opportunity because the OS is locked down making all this impossible.
Right now on Android I'm using Termux with an proot Ubuntu userland and running code-server which allows me to run VS Code as a PWA on Android. This is, by far, the best configuration I've found. But soon Google will make even this hack on hack impossible.
Yet you are trying to go back 50 years instead.
> No market opportunity because the OS is locked down making all this impossible.
No it isn't, you just have to free yourself from POSIX chains and embrace Android APIs and architecture models.
I think some Linux desktop users might have issue with that statement.
> No it isn't, you just have to free yourself from POSIX chains and embrace Android APIs and architecture models.
Each app in Android runs completely isolated from every other app (and more so every day). You can embrace Android but you have to throw out literally the last 50 years of technology. And plus, Android itself is kind of awful. It's the most hacked together OS that's been created in the last few decades. New does not mean better.
Are you really expecting developers to basically recreate the last 50 years of software development tools? What makes you think that's viable?
It's not surprising that most pure Android tools suck because they can't leverage everything that has been done and is currently being done on the desktop, servers, etc. Everything has to be recreated almost from scratch or shoe-horned in and it's awful.
It's literally a Linux system. I mean, yeah, Android/Linux isn't GNU/Linux, but there's literally a Linux kernel under there and it's certainly usable enough with termux or such providing a saner userland.
Whatever Linux calls Termux makes use of, they aren't allowed and work by chance.
Here are the official NDK APIs,
Anything else is considered unstable, not guaranteed to work across devices or OS updates, or even selected for SE/seccomp validation.
Android is not Linux, no matter how many think that it is the victory of Desktop Linux.
This is what many seem to fail to understand, Android is not a Linux distribution as such, trying to pretend otherwise will only lead to disappointment.
Just because you aren't supposed to do Linux syscalls directly, doesn't mean there isn't an Android compliant way to achieve the same goal.
For example, you aren't supposed to fumble with Linux networking APIs directly rather use the NDK and Java APIs for the same.
But in this case, they didn't give us Android compliant ways to do any of the stuff they restricted.
That is my very informal and perhaps very obsolete view of it. But I could be misremembering details.
I am curious about the performance impact of this change.
Although native memory allocations can happen via ByteBuffer, HardwareBuffer, image decoders, or native libraries.
So I would expect a well written game to also not be a workload in which you can recognize a poor performing malloc.
Same with media code for similar reasons.
I haven't toyed with files in 11 yet but looks like the MediaStore api covers such an use case :
Alternatively, download from the web or access files in Google Drive?
If I can, I will buy another Android One phone. There is an horror story about an Android One Xiaomi phone, but Nokia delivered the promise with the 6.1, according to my experience
Which one? I had a Xiaomi Mi A1 and nowadays I have a A2, both are fine Android One phones that still receives updates (in the case of A1, only security ones, but the A2 received a Android 10 update).
Yeah, Xiaomi may take a while to update their phones in Android One program, but otherwise it is fine.
They had to stop 3 or 4 times the Android 10 deployment because of bugs and issues found by users after updating on their phones.
Good to know that it was an isolated case
The real secret is to buy one of the devices the real core Lineage developers maintain because they will keep those security patches and major release updates coming to you for free that these billion dollar corporations couldn't be bothered to do.
If the entire Android ecosystem wasn't a disgusting exploitation machine meant to produce more rare earth metal waste than naval warfare by forcibly obsoleting devices every 2 years everyone would be better off. Every company could be sponsoring free software devs to support their phones in something like Lineage in perpetuity while paying a fraction what they do for their large internal dev teams to do it. But the perverse incentives mean they don't want to update phones, which also means making it hard to support their device in a real operating system like Lineage is in their interest.
But it's absolutely necessary. I can't upgrade until I have that. I want full control of what runs on startup and what should be allowed to keep running on background (manually closed by me, I'm not asking for a skynet AI to guess).
Another one is blocking internet access but that will never happen because of their business model and ads. I guess I'll have to risk my personal data by using an open source firewall (not like I'm not going to review all the code) and unlocking bootloader/root.
Android is a disgrace because of these "small" things that they refuse to fix. But I'm glad it's slowly getting better.
I am on Android 9\Pie, and from an app's settings, clicking 'battery', then clicking 'background restriction', I can choose from 'app can use battery in background' or 'restricted'.
But what I originally asking for control over is running at startup.
For example: go to an app like Lyft's settings, Permissions, then "..." in the top-right, and select "All permissions", finally towards the end of the list of all permissions is "run at startup". What I want is to enable\disable "run at startup".
It wasn't mediatized, but there must have been like a new stagefright-like media library bug every 2-3 months since stagefright was first publicized. Glad to see this news.
Also, how are they enabling memory tagging if it's an Arm v8.5 feature and new Arm CPUs, except for Apple's own chips, don't seem to support newer than Arm v8.2? Is it just the software version of memory tagging (with some expected performance penalty)?
From my links above, the TL;DR; snippets are
> Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem.
> Starting in Android R, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support.
And from https://android-developers.googleblog.com/2020/02/Android-11...
> We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps.
For the chips without MTE they plan to configure the kernel to randomly target processes for fuzzing.
> GWP-ASan heap analysis - Android 11 uses a variety of tools to harden security-critical components in the platform and apps. In DP3, we’re adding GWP-ASan as another way to help developers find and fix memory safety issues. GWP-ASan is a sampling allocation tool that detects heap memory errors with minimal overhead or impact on performance. We’ve enabled GWP-ASan to run by default in platform binaries and system apps, and now you can now enable it for your apps as well. If your app uses native code or libraries, we recommend enabling GWP-ASan and testing as soon as possible.
> GWP-ASan is enabled on some randomly-selected system applications and platform executables upon process start-up (or when the zygote forks)
And from ARM official communication, https://community.arm.com/developer/ip-products/processors/b...
> Only recently, Google announced that it is adopting Arm’s MTE in Android. This is exciting news, with Google showing its continued commitment to security in the Android ecosystem. It also shows the strength of our MTE offering, with the article stating that the technology makes “it very hard (if not impossible) to exploit memory bugs.” Alongside the security benefits, the disruption caused by not addressing memory safety bugs reduces user satisfaction and increases the cost of software development. With all these threats to the Android Ecosystem, you can understand why Google has made the commitment to MTE!
So those are the words from Google's Android team and ARM, whatever ARM CPU are being shipped, or alternative CPUs that Android devices might still adopt or be using.
It doesn't make sense adopting support for non-existing hardware.
> GWP-ASan is enabled on some randomly-selected system applications and platform executables upon process start-up (or when the zygote forks). Enable GWP-ASan in your own app to help you find memory-related bugs, and to prepare your app for ARM Memory Tagging Extension (MTE) support. The allocation sampling mechanisms also provide reliability against queries of death.
As stop gap solution until MTE is widespread across all Android devices.
If the phone had bad battery life or was slow to begin with, don't buy it. If it doesn't and it suddenly appears while you're using it... that's user error.
Support: I'm really not sure what kind of support you're expecting, I assume not "how do I take a screenshot" kind of support. I once returned a phone for warranty but the support delay on that was the time it took me to look up a few website pages if I remember correctly. Is that what you mean? Or maybe it's about how long the warranty process takes: it took almost 2 weeks to repair it for me (from the day of dropping off until the day I could use it again), that is indeed quite long for a fairly essential device, but that seems to be the standard for any laptop or phone (unless you bought a service contract, which I guess one implicitly does with Apple given its pricing).
I was also an early adopter of Android with the HTC Hero (Android 1.5/1.6), then the HTC Desire (Android 2.0) then the Galaxy Nexus (Android 4.2/4.3/4.4), but I got fed up of the support timelines too. I don't think my Galaxy Nexus even got an official update to KitKat (4.4). I got it via custom ROMs which were of questionable quality. Battery life and performance were also among my complaints. I eventually switched to an iPhone 6 in 2014 which lasted me 4 years and even then I only had to replace it because the storage capacity wasn't enough for me (16GB). The fact that apps have to ask for each permission also gave me the impression that iOS was more private/secure by default compared to Android. I know it's a moot point in current versions of Android, but it's still shocking to me that it took them so long to address the issue and that it even existed to begin with.