About a year ago, we talked about the fact that Android 15 became page size-agnostic, supporting both 4 KB and 16 KB page sizes. Google was already pushing developers to get their applications ready for 16 KB page sizes, which means recompiling for 16 KB alignment and testing on a 16 KB version of an Android device or simulator. Google is taking the next step now, requiring that every application targeting Android 15 or higher submitted to Google Play after 1 November 2025 must support a page size of 16 KB.
This is a key technical requirement to ensure your users can benefit from the performance enhancements on newer devices and prepares your apps for the platform’s future direction of improved performance on newer hardware. Without recompiling to support 16 KB pages, your app might not function correctly on these devices when they become more widely available in future Android releases.
↫ Dan Brown on the Android Developers Blog
This is mostly only relevant for developers instead of users, but in the extremely unlikely scenario that one of your favourite applications cannot be made to work with 16 KB page sizes for some weird reason, or the developer refuses to support it or some even weirder reason, you might have to say goodbye to that applications if you use Android 15 or higher. This is absurdly unlikely, but I wouldn’t be surprised if it happens to at least one application.
If that happens, I want to know which application that is, and ask the developer for their story.
> This is mostly only relevant for developers instead of users, but in the extremely unlikely scenario that one of your favourite applications cannot be made to work with 16 KB page sizes for some weird reason, or the developer refuses to support it or some even weirder reason, you might have to say goodbye to that applications if you use Android 15 or higher.
What about the applications where one emphatically doesn’t want a newer version due to platform degradation?
I have to imagine that this will break a lot of older games that will just be abandoned.
This, again, I have some purchased Play Store games from before mobile games became microtransaction tarpits (Need For Speed Hot Pursuit, Asphalt 6, Amazing Spiderman), which of course have been long abandoned by their developers, so it will be sad if they stop working.
Yes, I can keep playing them in my old devices, but eventually Play Services will drop support for the Android version of these devices, which means the DRM won’t work (I tried an already-installed version of Need For Speed Hot Pursuit in an Android 2.3 phone and the DRM check failed).
Thom Holwerda,
I’m curious, why do you say it’s unlikely? I see tons of hardware/apps that are no longer being supported and will not be getting any updates. Smart multimeters/smart lights/smart thermostats/solar controllers/etc. I meticulously archive the android software so I don’t loose it, but this will only be useful as long as android doesn’t break compatibility.
I absolutely hate that the defacto standard way to control smart IOT devices is through proprietary android apps. Android apps don’t lend themselves to automation & scripting, which is what I really want. I am currently trying to hack into a smart shunt to break away from the android dependency. (I really wanted to monitor it from an RPI instead). Alas I’m finding that the manufacture is using some secret handshake that I would have to overcome by reverse engineering the android app. Ironically it would probably be easier for me to build my own smart shunt from scratch than to integrate the one I have.
How much I wish we always had a simple API w/source code to control everything without having to reverse engineer proprietary stuff.
This, again. The reason I have zero Internet of Shit devices in my house is that every Internet of Shit device out there relies on a proprietary firmware to function and a proprietary Android app to be controlled, with no promise of security patches or long-term support whatsoever.
Give me the good ol’ “landlord special” white appliances with seven-segment displays and with no “smart” functionality any time of day.
Now, if you must have WiFi-connected home automation, maybe you should look at something industrial? I dunno.
kurkosdr,
A lot of the industrial stuff is still proprietary. While industrial stuff can be supported under contracts ensuring long term support, that can be prohibitive for individuals not made of money. I do some R&D work for proprietary industrial equipment. In those cases I am privy to inside information and code due to my position, but normal customers would be reliant on the vendor. Ideally all the code would be FOSS, you know how that goes.
Anyway I agree completely with what you are saying. I’d say vote for products that serve your needs with your wallet, especially vendor neutral standards if possible. Sometimes this seems futile when everyone else is voting with their wallets for apple/google/amazon encumbered products *Sigh*
I am just venturing into home automation, and using Shelly devices. They have an inbuilt web interface, so you can use them with nothing but a web browser.
If your app can’t be updated to be page size agnostic then it’s crap that shouldn’t be on the market, as the developer doesn’t care about code quality anyway. If you don’t use mmap with hardcodec constants and friends then you should be fine.
On the other hand I suspect google and phone manufacturers want to start shoving even crappier CPUs with crappier TLBs into phones if change of page size gives that big of runtime performance difference. In HPC scenarios it will probably make a difference worth pursuing, but in game or file manager, where essentially you either map tons of static data and create lots of tiny objects and user space allocators hide this stuff anyway?
Maybe they should make Rust a first class citizen for app development instead of power hungry Java (or whatever they call this java mutation nowadays)? Constant heap allocations, need to run GC, AOT/JIT overhead, JNI overhead, etc. When Samsung Gear watch was using Tizen (c/c++) the batter life was up to 1 week. After switching to Android, the battery life halved.
pikaczex,
The problem for most software isn’t that code isn’t page size agnostic, but rather that the tool chain itself isn’t. The page size is controlled max-page-size and common-page-size at compile time for both GCC and LLVM…
https://www.man7.org/linux/man-pages/man1/ld.1.html
I found this link, which does a good job covering the topic.
https://easyperf.net/blog/2022/09/01/Utilizing-Huge-Pages-For-Code
“Option 2” links to a project that switches to large pages at run time. It doesn’t actually do any code relocation, it merely instructs the OS to use large pages for memory regions that already happen to span across large page boundaries while keeping small pages for regions that don’t align.
https://github.com/intel/iodlr/tree/master/large_page-c
This is a very interesting approach, and I wonder if it might make sense for the OS to use this method by default. It might be the best of both worlds without eliminating existing software as google are doing.
Edit: This was done with x86, the viability of this approach would need to be demonstrated on ARM.
So, I guess every abandonware Android NDK app will break for Android 15 phones that use 16KB page sizes?
kurkosdr,
t do not know any more than what the article says, my reading is that google play will enforce the restriction but not android itself. If you can side load them they should still work.
It wouldn’t be the first time google has broken software, putting devs in a hard spot…
https://www.xda-developers.com/termux-terminal-linux-google-play-updates-stopped/
In the case of termux, they had no choice but to leave the old version in the app store, bugs and all because google decided to ban the functionality needed by linux shells. Also, android support for legacy API levels only goes back so far. I would predict that these restrictions on play store submissions (including 4kB) will eventually be enforced on new versions of androids in the future.
Maybe emulators can save the day? Even if we can never run the software again on official hardware, it would still be nice to at least be able to emulate it in perpetuity. Something akin to DOSEMU/Box86 for android software. The android emulators I’ve tried haven’t exactly been smooth sailing.
Termux was always skirting the rules, since the Android’s home directory (aka /storage/emulated/0/) should not contain executable files and no files in there can have +x permission (but Termux skirted this restriction by abusing execve()).
I am glad this loophole was closed in the Android 10’s API level (29), since it’s a major security hole: Your Termux app downloads an executable file to the home directory, some other app overwrites the file with a malicious version of the file, then your Termux app executes the malicious version of the file. So, it’s good that this loophole was closed before more mainstream devs catch wind of it. A major design goal of Android is that apps cannot modify the executable files of other apps, and I like that way.
That said, no compatibility was broken: Termux can target API Level 28 and older to get the old behavior. And just because Google doesn’t want new versions of Termux in their store (Play Store), it doesn’t mean you can’t get them from F-Droid, this isn’t iOS where the OS is tied to a particular store. If you care about Termux, you probably know F-Droid exists.
But what we have here with 16KB page sizes is different: Literally every NDK app will break, even if the developer did everything right. Even sideloaded NDK apps will break. Apparently, it will still be possible to boot Android devices with 4KB page sizes (as long as the hardware still supports it), but then you may have the issue of certain pre-installed apps breaking with 4KB page sizes because they only work with 16KB page sizes. Just… great.
I consider this breakage equivalent to moving to a different ISA, since the page size is a hardware feature of the MMU.
kurkosdr,
Termux brings the ability to run a shell to android. The same “security hole” exists on windows and linux computers. Normally owners don’t run untrusted binaries willy nilly. If you want a walled garden device, then so be it, but clearly it’s a disservice to power users who want termux as a shell.
It is a breakage. The syscall no longer works like it does on normal linux.
Yes, and it’s the reason malware in those OSes is so destructive, because a malicious app can “infect” other executables (in the home dir and potentially elsewhere).
A major design goal of Android is that when you remove an app, it’s gone, it can’t inject its code into other executable code and have its ghost haunt your device forever. Sure, it may modify non-executable files in your home directory (for example delete or modify some of your photos), but it can’t inject itself into other executable code (not on an updated device that isn’t “rootable” via security exploits).
See? This is the problem here: the Termux workaround blurs the distinction between trusted and untrusted. Let me guide you step-by-step how the Termux loophole can be abused by more mainstream developers:
1. Developer makes application, but the application they upload to the Play Store is just a downloader, the actual app is hosted on the developer’s server and is downloaded on first launch of the app to the device’s home directory (and is executed via execve)
2. Application is also coded to check periodically for new files on the developer’s server and also download those to the home directory
3. The developer can now push updates to the executables of the app without going through the Play Store review process (and related Bouncer malware scans), also, third-parties can make unofficial “updater” apps that modify the executables in the home directory and potentially inject malware, the possibilities are endless.
And you know mainstream developers will do that to save the time the Play Store review process takes.
Just… NO! The fact some Android apps require non-executable files to be downloaded from a third-party server is bad enough.
By this definition, Android was always a “walled garden”, since it never gave you full root access or the ability to set permissions in directories (for example in the home directory) as you see fit.
Please educate yourself on Android’s API Levels. The whole point of Android’s API Levels is that syscall behavior can change with new API Levels. The syscall works exactly as it did before if you keep using the API Level the app was originally designed for (API Level 28 or older). The fact Google doesn’t want your app in their Play Store is irrelevant. The Play Store is a store, it can choose to not host your app if they don’t deem it fit for their digital store shelves. That’s why alternative app stores like F-Droid exist.
Maybe the misunderstanding here is that you assume when a new API Level is defined (for example API Level 29), it’s impossible to make new versions of apps for previous API Levels (for example 28). This is not true: You can keep creating new apps and new versions of apps that target API Level 28 for as long as you want, and new devices running the latest and greatest Android version will run these apps just fine by emulating the behavior of API Level 28 (including the old behavior of execve). Whether Google considers those apps fit for their store, that’s in their discretion, since it’s their store. You can still publish your APK in other stores (which is what Termux does).
Personally, I want the Play Store to host quality apps that don’t skirt the Play Store review process, thank you very much.
kurkosdr,
This assumes the OS can only lock in one page size at boot time, however page sizes aren’t exclusive at run time. I don’t know how much of this applies to ARM specifically, but on x86 and even sparc multiple page sizes are supported simultaneously.
(had to remove the links so it doesn’t get flagged, sorry)
lwn.net/Articles/423584/
web.archive.org/web/20060312152822/http://www.sun.com/blueprints/0304/817-5917.pdf
learn.microsoft.com/en-us/windows/win32/memory/large-page-support
I am not sure if the kernel itself can do this, but as far as userspace processes go multiple page sizes is not a problem: 16kB can coexist with 4kB. For this reason I don’t think the problem is necessarily as bad as you may be thinking.. It surely depends on google continuing to support both page sizes in android. I don’t have a clear read on their intentions for the future. IMHO they could have just changed the build environment to produce 16kB aligned code by default without any of this “lets prohibit these from the app store” and it would have been “win-win”.
The main caveat I’ve read about in supporting multiple page sizes is fragmentation. I don’t know how bad this gets in practice, but apparently some operating systems reserve large pages…
docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-memory-configuring-huge-pages
i might be ignorant but it seems to me that supporting 4k page size on system with 16k page side sounds trivial, albeit at a significant memory overhead.
yoshi314@gmail.com,
Indeed, I had this very discussion with malxau, here….
https://www.osnews.com/story/140578/adding-16-kb-page-size-to-android/
Of course at a source level, there’s not a problem if you recompile, the main issues stem from precompiled binaries. In principal the loader could make everything dynamically relocatable without affecting the code, and I wrongly assumed this is what PIE code did. In practice though, as implemented on linux, sections of a binary are not relocatable with respect to other sections. malxau put it this way…
This was a surprise to me. I had wrongly assumed that PIE binaries worked at the section level such that they could be arbitrarily relocatable without restriction. There is no reason they couldn’t have made them relocatable just like external addresses across shared objects, but it turns out they didn’t implement this. So existing binaries don’t contain the necessary relocation entrees that would be required in order to move sections with respect to each other. This offset information is used by the linker at compile time, but instead of saving it, the linker throws away the information essentially locking relative offsets into place. Because each section has special requirements like readonly, writeable, executable, etc. 16kB pages can’t accommodate multiple 4kB pages being packed into one 16kB page.
TLDR; I felt the same way as you that it should be trivial – but I was operating under the flawed assumption that all sections were relocatable when it turns out linux doesn’t implement this. As a result a binary with 4kB aligned sections might not be properly aligned for 16kB.
Alfman,
Android (used to be) is extremely good on backwards compatibility. And that is why this change is baffling.
They not only had the usual backwards compatibility (so that your Android 15 application would run on Android 10), you could also use forward compatibility for many APIs with AndroidX (Jetpack).
This meant you could use new features, but still target older phones (to a point).
In that context this change makes no sense. They could easily(*) build a compatibility layer with necessary shims to use “fake” 4K pages.
Yes, the new one would be better, but the older would continue to work.
Worse? It would definitely break this forward compatibility. What is the earliest Android that can handle 16 KB pages?
Awesome!
kurkosdr,,
(moved here on purpose on account of wordpress)
Many android devices do support root, but even a non-root user might want to run a shell. Power users go for android over iphone for a reason, we don’t like being caged. Android IS linux and if some owners want to use their device to it’s full potential including a shell then it should be allowed. Personally I would be ok putting it behind a dev permission (along with all the other developer settings).
I’d point out this is the same thing they are doing rejecting apps with 4kB page sizes. It might suck for you because something you wanted is being prohibited under google’s requirement but owners who want to run a real linux shell on android feel the same way about google’s decision to block them.
That’s only true to a point, but the clock is running on those old API levels. Google only allows us to go 10 or so API levels behind before discontinuing them even for users who sideload applications.
(see minimum target API levels)
https://targetsdk.com/
My concern isn’t so much about what google allows in its app store…I don’t even use it. I just need backwards compatibility to be maintained in the android OS itself. While you haven’t agreed with my points, I actually think we’re both in the same boat with applications being rejected from the app store today and potentially getting disabled on android down the line.
Technically true, but most devices don’t support root (and Play Store-certified devices can’t support root), so most Android apps are designed to work without root. Which I consider a good thing, I hate how seemingly every Windows, MacOS, or Desktop Linux app wants root/admin to install and as a result gets to run arbitrary post-install scripts with root/admin access, IMO root/admin should be a well-hidden developer option much like disabling driver signature enforcement is on Windows, but no OS does that. Still, I prefer the Android approach over seemingly ever app demanding root to install.
You can run a shell using something like Terminal Emulator (and many exist in the Play Store), just package a reasonable subset of tools in the APK, and you can run a shell and edit files in your home dir just fine.
But you want to install additional tools (almost) like you do on Desktop Linux, which is a completely different OS. That kind of thing should be done inside an emulator or virtualizer, not native binaries.
It’s not the same thing, that’s what you consistently fail to understand: Your API Level 28 apps (for example Termux) will run perfectly (even API Level 28 apps that will be released in th future), my API Level 28 NDK games that don’t receive updates anymore won’t run on Android 15 devices with 16KB page sizes. In fact, even much higher API Level games will break.
That’s what you misunderstood right there: Android is not “real linux” and was never marketed as such. Still, Google has made a promise to support old API Levels in new Android versions (they call it the “API contract”), so your Termux will work as long as it targets API Level 28.
On my case, even NDK apps that target Android 14 and stopped receiving updates yesterday will break on Android 15 devices with 16KB page sizes, this is epic breakage on a massive scale. They broke the API contract in a major way, plain and simple.
There is an adb command to bypass that, in a page conveniently located in the “References” of the page you cite:
https://developer.android.com/about/versions/15/behavior-changes-all#minimum-target-api-level
Don’t get me wrong, I don’t like you have to run this adb command, but it’s a soft block, not a hard API breakage like the one they are doing with 16KB page sizes.
kurkosdr,
It doesn’t work fine unless you limit yourself to something like busybox that fakes execution. You want to compile and run your own code like on every other linux system…google says no, too bad. I understand it isn’t your cup of tea, but for certain power users this really sucks especially given how both incumbents keep taking steps to squash owner control. I concede many don’t care, but regardless this situation is bad for open computing.
TBH I still find extremely problematic. Google are even preventing fdroid users from being able to sideload old API levels.
https://forum.f-droid.org/t/force-install-old-targetsdk-apps-using-adb-root/28470
I’m not as confident as you are that google won’t shut down that adb hole as well. After all, the same security arguments apply. I guess we’ll see if this ADB bypass keeps working.
I am also fretting the day when this other restriction prevents me from sideloading an app I need.
https://cybernews.com/news/sideloading-wont-work-for-many–android-apps/
I wonder if an ADB bypass might work there too, and for how long?
You keep saying this, but everything I’ve read only says google play will reject those, not that android won’t run them. Can you point to any confirmation of that? Many operating systems support multiple page sizes, including the linux kernel. so I don’t know whether what you are saying is true. It’s not self evident to me that 4kB page size software will stop working immediately. If you are right and it does stop working immediately, then I agree this will be devastating not just for us but a lot of users. However I think it would be extraordinarily dumb for google to do that.
It’s not desktop linux, but it is “real linux” in the literal sense that I meant it and I see no reason android owners should be prohibited from using linux facilities however we choose. Hide it in the dev screens if it makes you feel better,, but it’s my phone and my business what I do with it. Google needs to take their hands off my phone. I wish we weren’t stuck with a duopoly so I could buy something more friendly to pros without being relegated to a lonely island.
See? This is where the misunderstanding lies: Android was never a Linux system any more than TiVo is a Linux system. It uses a Linux kernel but that’s it, and as a user you don’t interact with a kernel, you interact with the userland. Google can replace the Android kernel with Fuchsia’s Zircon kernel, and as long as they don’t break any userland APIs and limit the new kernel to new devices with compatible drivers, you’d be none the wiser. And OS is its userland, not its kernel, and Android userland is different from real Linux or standard Linux or GNU/Linux or whatever you want to call it. They never promised something like “real linux” or marketed it as such. You can argue semantics and complain about it, but it won’t change a thing.
So, if you want to run a foreign OS, use emulation or virtualization and be done with it, nobody is “prohibiting” you from anything by not making sure Android acts like a another OS.
Yes, I don’t like what Google did there (forcing you to jump through hoops to load APKs targeting old API Levels), but it’s still a soft block, not a hard API breakage.
Of course, Google can lock it completely or even remove sideloading entirely if they want to be evil, they have complete creative control over the OS, and it was always like that. I can’t predict the future, so I can’t comment further on that.
That’s anti-sideloading DRM, paid apps have had anti-sideloading DRM since Android 2.x. Now, I am not glad that free-of-charge apps have anti-sideloading DRM, but it’s up to the publisher to add said DRM, so again, not a hard API breakage, it’s DRM.
Also, it cannot be bypassed with adb since it’s DRM.
The Linux kernel doesn’t support multiple page sizes, so yeah, consensus is that booting in 16KB page size mode will break all compiled native binaries (aka Android NDK apps) that aren’t page-size-agnostic (which is most NDK apps since the tools Google recommended for building NDK apps were creating non-page-size-agnostic compiled binaries).
It’s a hard API breakage like no else. My only hope is that OEMs abstain from it (though unlikely if it gives them an edge in benchmarks) or that we get an option to boot in 4KB page size mode.
And here is my gripe: It’s the first time backwards compatibility with old API Levels will be broken with no adb recourse, and even for very recent API Levels.
More details about 16KB page size breakage in Android here: https://www.reddit.com/r/Android/comments/1ezlo5t/comment/ljos6cu/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
kurkosdr,
No, you are flat out wrong. I shouldn’t have to say this, but “linux” is technically a kernel that does not include a specific desktop software. Even tivo could be jailbroken and you could get a real linux shell working there, which was genuinely useful for power users.
The fact that you personally did not or do not care to use linux as a power user is fine, you do you…but you seem to be too far removed from the linux power user scene to understand the befits to others. And yes shell access is absolutely important to creative power users even on android. Linux on android is not some linux imposter, it IS real linux in the most technically correct sense possible.
Yes, that’s much more powerful than you think. The linux kernel provides common userspace facilities across a world of devices including android. By giving owners nothing more than a basic shell environment, loads of linux functionality is on the table. It could be a router, android phone, tivo, thermostat, smart speaker, whatever. It doesn’t have to be one of the standard desktops that you insist “linux” be. Frankly the position you are arguing from exemplifies a total lack of creatively, which is fine for your needs But it doesn’t make you right about other people’s needs. Whether you’ll admit it or not having unrestricted shells on linux devices is extremely empowering. Having google or anybody else take this away from the linux community is a major setback. Maybe not for you personally, but for power users, absolutely.
Not only does it, but you seem to have ignored all the links I’ve already posted about it.
kurkosdr,
Thanks for the link. It explains more about google’s plan. I am in agreement with you that things could get ugly. It still doesn’t really answer my specific questions though. I can’t tell if ARM is limited to all or nothing large pages. On other architectures multiple page sizes are supported.
See, this is the misunderstanding right there: In order to use those kernel userspace facilities, you have to go through the OS’s userspace, which can restrict the kernel userspace facilities.
You are free to hack things as much as you want, but there is no guarantee that an OS’s userspace as shipped from the factory will act similarly to the GNU/Linux userspace unless it was specifically promised so.
Seriously, the “Android is Linux” people are annoying: Android never pretended to be similar to GNU/Linux, even though it uses the Linux kernel. Also, Richard Stallman was right all along for correcting people using the term “Linux” to refer to GNU/Linux.
On a related note, the whole philosophy of Android is that apps should be self-contained: all Dalvik code or native code should come packaged in the APK and installed by the Android Package Manager. This makes it easy for stores and APK download websites to scan applications for malware and exploits by scanning the APK. It also makes it possible for the Package Manager to scan the application for malware and exploits by scanning the APK before installation. Allowing APKs to download native code at runtime from a third-party server to the home directory and execute it goes contrary to that.
In other words, the userspace of Android has been designed with Android users in mind, not GNU/Linux people who have made GNU/Linux the way it is (a mess of byzantine dependencies vulnerable to supply-chain attacks). This is why I find the “Android is Linux” people annoying: The userspace of Android has no obligation to act like GNU/Linux so you feel “empowered” or “not restricted”, no such thing was ever promised. In my opinion, the execve loophole should have been treated as a security exploit from day 1 and patched, because it allowed native executable code to bypass the Package Manager.
And this also ties to my either gripe: Google has so far gone to extreme lengths to maintain API Level compatibility, from keeping the execve loophole around for old API Levels to keeping some ill-advised APIs from the Android 1.x era that allowed an app to take over the screen (although they finally introduced some handling code that overlays the nav bar), and now they are breaking API compatibility even for NDK apps targeting Android 14. Just weird.
my either gripe = my other gripe
kurkosdr,
That you keep repeating this does not make you right about it. Our disagreements don’t stem from misunderstanding.
You need a shell. Nothing particularly complex, just provide an interface to the underlying linux system. Root access is nice, but not always necessary.
Just because you personally can’t see the value and potential for linux devices without “GNU/Linux” or other desktop linux environments doesn’t mean it’s not there.
I guess I am fine with that if you insist on thinking that way, although honestly I wish you could open up your mind and see how much genuine potential there is in the hands of power users when the platforms don’t try to deprive us of access to our own devices. But I do understand that not everyone cares about it. Power users are in the minority in a world where the duopoly caters to the masses.
This is what you don’t understand: It’s not that Google can’t give you that shell in Android, they don’t want to and they don’t have to.
See? That’s what you refuse to understand: The purpose of Android as an OS is not to fully realize the potential of the Linux kernel underneath, the purpose of Android as an OS is to support an app economy. And for that to happen, the apps need to be self-contained APKs that don’t fetch and execute native code at runtime, so that the apps are scanable by APK vendors and by the Package Manager, and so they can’t be “infected” by other apps.
Android was always marketed as an OS running self-contained apps that can’t infect or be infected other apps, it was never marketed as an OS behaving like GNU/Linux.
Again, Android wasn’t marketed as an OS that provides full access to the underlying device (or the underlying linux kernel), it was marketed as an OS for running self-contained apps that can’t infect or be infected other apps. You are whining about not receiving a potential that was never promised to you in the first place.
And since all that “potential” would act detrimentally to the original mission of Android as an OS for running root-less self-contained APKs (aka what Android is for), do you understand why people like me who bought Android for what it sets out to do find you “Android is Linux” folks so annoying?
BTW I think you should be able to flash whatever unofficial ROM you want on your device so you aren’t deprived of it (and you can actually do that if you choose a device that has an unlocked bootloader), but demanding a certain behavior from the pre-installed OS when that behavior was never promised to you and when it acts against what the pre-installed OS sets out to do, that’s just annoying.
kurkosdr,
Again with this stupid line. Every single time you’ve used it you’ve been wrong to say it. Google could pull an apple if they wanted to – nobody here misunderstands that!
OMG you are a broken record. I don’t have to be told that power users are a niche and how these companies don’t have our back when it comes to openness and granting owners control over their own property. I already know all that. I already know that For god’s sake move on already. My point is that such developments bode badly for power users and that you either have to be ignorant or disingenuous to deny that it’s a problem when both sides of the duopoly take to adding restrictions against owners.
Trust me I try, but you don’t seem to appreciate the challenges that come with going against the duopoly because of their actions.
And my point is that catering to power users is what made Windows, MacOS, and GNU/Linux they messes are (that is, OSes were seemingly every app needs root to install and uninstallers don’t uninstall all traces of an app), so sometimes, not catering to power users is a good thing, NOT a problem.
You come from the assumption that not being given full access is always bad. I beg to differ. I want my phone to be a platform for running apps, not GNU/Linux, and I bought an OS that does exactly that. It’s not necessarily about control, it’s about enabling certain experiences (like having self-contained apps, and having apps that can’t infect or be infected by other apps). That was the philosophy of Android even before the Google acquisition. Apps in Android were self-contained (and rootless) from day 1.
About the duopoly thing, can all you power users buy that Jolla phone and run a BlueStacks-like app for your Uber/WhatsApp/banking app needs, instead of whining Android isn’t like the OS you want to use?
kurkosdr,
That’s BS though. Giving power users the option to use an unrestricted shell in a dev menu does not create a mess. It’s an idea you’ve conjured up in your head because your not a power user and you don’t care. There are plenty of good ways to handle it without taking owners out of command.