Google can make it easier to identify which apps are taking up space and slowing the system down, so that users will uninstall and developers will respond. I had an Android up until July and the interface for understanding and removing app memory usage was still poor.
Yeah, it would be nice if this was exposed to us. With just three apps open on my iPhone, sometimes I'll go back to one and it has to relaunch. Did it crash, use too much memory, or was it squeezed out by high memory consumption of the other two apps?
Even desktop OS don't go far enough. Would be nice if Windows and macOS came with a top 5 {mem,cpu} consumers drop-down in the global menu bar without having to install a tool or open task manager. We complain about bloated apps but without providing insights to the user, there's no pressure for apps to optimize.
If it seems like too much of a power-user feature, how about your run-tracking app silently closing on a long run because you were also listening to Spotify in the foreground? That's not a good experience. With no insights, all you have to act on is superstition. Do I need to find a run-tracker that doesn't crash or should I try a different music player? No data so who knows.
We still insulate users from this data for some reason even on mobile devices that LRU-close apps when memory is tight. Let the people know, dammit.
It's the OS's fault for silently killing apps that are 'in use'.
An app can already say 'I'm still doing a user visible action' (like logging a run, or playing music). Whenever one of those apps has to be killed to free up memory, a messagebox should be displayed saying "Spotify has quit due to low memory. Spotify was using 647MB and RunGPS was using 1454MB out of 3000MB system memory".
The problem is that device manufacturers employ additional killers and "efficiency managers" because too many app vendors use one of the various workarounds to collect data or whatever the fuck they are doing otherwise.
Google won't do much against it because the worst of the data hoarders are the f2p games that make money for themselves by selling the user data they can get their hands on and make also a lot of money for Google via all the IAP commissions.
Google could still choose to provide a clean and powerful interface on their flagship phones (Pixel) and the Android One certified phones. The existence of the latter program is evidence that Google does (or at least did) recognize the value in protecting the user experience from bad manufacturer incentives for consumers who are willing to pay a small premium.
I'd guess a built-in web browser like Electron apps? But that wouldn't make much sense since I'm sure android has a WebView built in which should use mostly built-in browser libraries / tech.
> Google can't force people to not use frameworks. So they work on the bits they can control.
Couldn't they just penalize app size in play store rankings the same way they penalize slow sites in search results? Obviously for games and some types of applications you can't get around it, but I imagine Google has the resources to work around needlessly punishing those.
That sounds like a very fun project. There is of course the technical work in identifying unused code and resources, a data science framing where statistical questions regarding bloat could be assessed, a process framing component where tooling and dev-platform interactions could be incentivized toward reducing bloat, and and economics framing where structural changes in Play store could change dev strategies toward bloat. Someone in charge of leading such a project has a lot of options available for analyzing and solving the problem, none of them mutually exclusive.
I don't think inherently large apps like games would be a problem on paper. Your game is competing against similarly sized games, not, say, a todo list app.
How does game app size factor into the enjoyment in any way? Android phones aren't like iPhones and most have sd card slots which are dirt cheap nowadays.
shorter novels are better than longer novels? shorter movies better than longer movies? I don't think measuring on number of bytes is really a good metric. Tic-Tac-Toe is pretty small but I'd rather play GTA5
Novels and movies aren’t baked into app binaries, they’re served on demand. And most people looking to download games have specific criteria in mind, e.g. genre, rating, publisher, price etc. It’s very unlikely that Tic-tac-toe and GTA5 fall under the same criteria for any given consumer.
App size is penalized naturally for some classes of apps.
I worked on the main app for a top hotel brand and they wanted convincing why we should take several sprints shaving space off their builds.
They're struggling to get people off their phone lines and into the app.
Say a customer's on a mobile connection or crappy airport wifi trying to book a hotel. When a 30 minute download for your 400 mb app starts, guess what they're going to do?
I get why smaller companies use generic janky frameworks to throw up an app quickly and keep maintenance costs down. But why doesn't Amazon have the most streamlined and elegant app on the planet? They have the resources, expertise, and scale for it to make sense to invest heavily.
Will that 1% stop buying from Amazon, or will they just use the website instead? Gut instinct (and personal experience) says they're not really losing anything here.
Yes, I think people absolutely will buy less from Amazon if the mobile experience is just a bit slower or more annoying. We know from both other companies and Amazon's behavior that reducing friction has substantial impact on amount purchased.
even if they buy less because of the bloated app, you're still balancing dev resources against profit margins. It might just not be worth the effort for that extra tiny bit of revenue the app will generate by being small.
But that's my point about scale: if the revenue-vs-developer-time tradeoff makes it worth it for any company to make a good app, it will be worth it for Amazon. They are so huge that a 0.01% increase in sales translates to many millions of dollars per year.
Everything else they do also scales though. Not proportionally to each other, but I wouldn't be surprised if putting their devs on, say, better product recommendations is much more revenue than app size.
The push to get everyone on the company app will be less so. Why they want everyone on the app I don't understand but whatever those reasons are they won't benefit from it
Again, have you ever in your life wanted to buy a product from Amazon but then didn’t because of their app size? If not, as far as Amazon is concerned you don’t care about the app size in any meaningful way.
I absolutely have given up on trying to buy something from them because their mobile app crashed, which is the kind of thing that could be due to them mindlessly lashing together a bunch of app frameworks rather than building something streamlines. I've also given up when trying to do something really simple like set precise price filters that are bafflingly not available on mobile.
My comment that started the sub-thread you are replying to specifically generalized the question, and I did so because I think app size, stability, and general well-built-ness are tightly connected.
> I get why smaller companies use generic janky frameworks to throw up an app quickly and keep maintenance costs down. But why doesn't Amazon have the most streamlined and elegant app on the planet? They have the resources, expertise, and scale for it to make sense to invest heavily.
Another way to say this: the root reason for app bloat is something that causes general app badness, so the question "Why is the app so bloated?" is not well explained by your implied answer "Because users do not reduce purchases on account of app size".
Fair. And for what it’s worth I would very much like for the app stores to penalize apps that are bloated. Institute a 20MB limit on the app size unless it’s a paid app or has specifically applied for a large app permission and justified why it needs more storage. That would drive developers away from bloat.
But I think large apps and apps that crash frequently is correlated but not strongly. I have never seen Amazon crash. I have seen 4MB apps crash. Bloat by itself just means I have to buy a more expensive phone to fit everything I want, which sucks but isn’t the end of the world.
I don't have amazon on my phone due to the bloat and opt to wait until I get in front of a desktop. Which means probably 80% of potential impulse buys from my phone are forgotten by the time i'm back home and they've missed out on sales. It's lost opportunity that they can't measure and so it will forever be swept under a rug.
You might be the exception here but (a) Amazon.com is accessible from your mobile phone, do you not use that? And (b) “impulse buys from my phone” is indeed hard to quantify. How do we know that you’d make any impulse buys if the app was in front of you? Going to their website on a phone is as easy if not easier than using their app and the content is identical. Yet you don’t say that you make impulse buys that way. 80% of 0 is still 0.
I have a Realme GT Neo2 which comes with 128gig at about 330€.
Of course if it occupies a significant portion, it would be an issue.
On the other hand when I look at the kind of updates that Steam and Playstation are pulling, 200mb feels like nothing.
I'm confident the same question has been asked countless times before when it comes to their website as well. I don't have any answers, I don't know either. Familiarity I guess?
Or even 1MB for the hello world app, I know. But that's because of the AppCompat (and relative) libraries.
If you program using the built in api only (this means the functions available to the target sdk, nothing newer) then your app size will be basically all assets, as code is very compact by itself.
But of course, coding is by far more complex, you are like doing native programming (although easier than c). My apps are small tools, so I can.
Oh, and don't use Kotlin. It's a wonderful language and far better than java, but horribly optimized.
I have no idea what your suggestion is here? Do you want Google to just ban apps which are "too large"? They can't ban everything that's 229MB, that's reasonable for many types of games.
This is user-hostile behaviour and they don't like it, otherwise they wouldn't make the move forward to implement this feature.
I'd love to see them get in their walled garden and clean up the ecosystem. They are doing reviews obviously, so they can/should tackle the bloat, too.
Google knows how many installs you have. I think once an app crosses some threshold, the app requirements should be stricter. If you have 100 million installs, then you better be able to justify the resource requirements of your app. 100 MB of bloat might not seem like much individually, but multiply that by 100 million and it adds up.
The size of apps has gotten so bad Google is now forced to develop 2 versions of their core apps and 2 versions of their OS, one for devices with expendable resources (regular Android) and one for devices with limited resources (Android Go edition).
I have removed most of Google's apps from my phone because of their extreme size.
Looking on my phone it looks like the award for most bloated goes to Google Play Services at 500MB. Wow!
As you can see from the breakdown: 34% of the app is native libraries, another 34% is dex, 23% is resources, and another 8% is assets.
Unfortunately they're still not using AABs, have about 4 MB of download size savings from just image optimization, have 1.1 MB of Emoji gif files , and are not optimizing their Native libraries for the specific architecture (using AABs would solve this)
And it even seems to provide less information than the website.
Yesterday I was looking really hard on who exactly would be the seller for an item. Did not find that information on the app, while it's easily findable in the web version.
Or do I have some quirky version of the app due to some A/B testing?
It explains exactly how it will work. They generate a tiny placeholder app package to replace the application itself on-device.
This way it frees up the space used by the application data, without removing it altogether, so that the associated user data can still remain with it.
It’s the same concept as iOS’ feature to offload unused apps, but this appears to be implemented in a way that is backwards compatible with older devices since the Play Store is able to manage the process of replacing and restoring the app package and not the core OS.
So when we want to use again that 200 MB app we have to wait to download those 200 MB again.
I have many data points for which the main source of clutter on the phones are WhatsApp images and videos received in a lot of chats and groups. I know people that remove them almost daily to let their 16 or 32 GB phone receive another day worth of messages.
The article talks about reducing binary size, not the user data. I think the idea is that the Archival APK acts as a placeholder for the application, so the application is not actually uninstalled, and thus app-specific user data has a place to live.
Storage footprint is not and has never been my issue. Little knowledge of and no control over what bullshit an app may or may not be doing in the background is.
Storage usage / download size and data usage are more important to the average user than many developers think.
I tried reducing all this to a minimum for my app and it helped getting more downloads and less churn. Now at 10MB download size, 40MB storage usage (10MB cache, 10MB data) and 5MB data usage. All this for a heavy user (myself).
It's https://stockevents.app. An investment tracking app. Currently in the process of completely removing all third party analytics for the next version. Should reduce all this even more.
Yeah this is something that has been found before as well; it's why ~10 years ago, AppCode became a Thing (it's a vector image editor whose output is iOS drawing code, because 10 kB of code compiles down effectively and is less than providing 3-4x a png image for different resolutions).
It's also why Apple has pushed some technologies for developers to reduce initial app size; optimized builds per device (you send Apple a bundle with e.g. multiple images at different resolutions, Apple only installs the ones the phone actually needs), dynamically loading content like levels (so the initial download is only the core libraries + the first level, the rest is downloaded and offloaded dynamically), etc.
It's why I never use my 32GB base iPad; install more than a few apps and you run out of space.
Turn iCloud Photos on? Even with "Optimize storage", that'll keep about 3-5GB of local thumbnails on your device, wasting space.
iCloud Notes on? Your 5+GB of notes will all be stored locally; no storage optimization there.
Use Apple Music? It'll use about 7-8GB of local storage, not for any downloaded songs (I haven't downloaded any) but purely for album artwork, cache, and other junk. There is no way to ever delete that Apple Music cache; not even cancelling Apple Music, turning off Cloud Library, or deleting the Apple Music app. The only way, is to reset the iPad completely, and delete the Music app before it can start syncing anything from the cloud. i.e.: you have to switch to Spotify.
These are all Apple apps.
When an iPad has low free storage, it'll delete user data from 3rd-party apps, and those apps have to redownload user data from the cloud every time you open the app. Notability is a good example. Everything's gone, wait 5min for it to resync.
The iPad might be my main device if Apple fixed this, and it would lock me much deeper into Apple's ecosystem, but they don't seem to understand the value of minimizing storage use.
> more important to the average user than many developers think.
On that, the larger your app is the bigger the target. When I run out of space on my phone I sort by largest app and start booting off the worst offenders. Small apps, even if I use them less often, are likely to fly under the radar.
That is literally bloat. Why does Android deviate from UNIX and reinvent the wheel into a wobbly ellipse all the time?
Already, swiping an app away in the task manager awkwardly keeps it open in the background instead of closing. Now we awkwardly keep zombie apps.
Please stop predicting what users want, give them reality. You have 20 background apps, you see 20 apps in the task manager. You install 100 apps, you have to sort and group 100 icons. You either have a usable app, or no app at all.
Then, the user can say "damn, this bloat sucks. Please make things lean and simple, Mr. Corp."
Not related to storage space, don't know if it is app developers or the Android permission system but I hope the storage permission gets fixed in Pixel.
If I try to download a file, an app shouldn't need to get media permission. An app should be able to download files with either a download folder permission where it can write a new file but only read what it wrote unless explicitly given permission to
Based on your link, if they are using MediaStore and targeting Android 9
> Permissions are required for all files on Android 9 (API level 28) or lower
I'm not an expert, but unless I'm missing something, there seems to be a legitimate set of circumstances where the requesting of additional permissions is required to function correctly. It seems overly reductive to deposit this entirely at the feet of app developers.
It won't, the whole point is to take less space. If you archived an app, you can't expect it to be able to be unarchived when you're offline. I fail to see much of a use case for it anyway since most apps require connectivity anyway.
Lets start with actually being able to completely uninstall bloatware. On my Pixel 4a / Android 12 I can only "disable" most pre-installed apps, which are Google apps.
motorola is awesome in this regard. i have disabled all of the stock apps out of habit and i would not touch a xiaomi, redmi, samsung bloat with a 10 fot pole.
Not perfect, though, because on my phone they've still blocked up a few 100 MBs of precious storage space with a completely useless [1] OEM partition.
[1] It contains a file explorer app – given that at least at that time Android didn't really have a proper built-in file explorer this is actually a somewhat sensible idea, but then on the other hand as a power user I still prefer a file explorer of my own choosing (and with root support), so it's still mostly useless to me.
Other than that, it contains what looks like configuration apps for a few American mobile service providers, plus something like some sort of Brazil-specific app store – all completely and utterly useless, especially given that my phone was bought in Europe and is on the European software update channel!
A factory reset must restore the device to an "out-of-the-box" state without needing to re-download anything, so the original versions are still in the system image -- changing the button to read "uninstall" rather than "deactivate" wouldn't make any difference to the amount of user space available.
Google could solve a lot of storage issues just by not allowing device manufacturers to lock apps so they can't be uninstalled. There is a huge amount of bloat on modern android phones and tablets that cannot be removed.
It's particularly frustrating that the lower-end the device, the worse this problem ends up. Someone who can only afford a phone with 16 GiB storage then ends up only have 2-4 GiB for discretionary use because of all the hostile shit the device manufacturer / carrier baked in to the system partition.
That wording is broken; not using a backwards unit like MPG (but rather one like the European l/100km (could also say "cl/km")) would make it much easier (the travel distance is typically a given, and the frequency/expense of tank stops what's being optimized).
If you allowed deleting the pre-installed apps entirely, rather than just disabling them, the device could no longer be factory-reset to the original state. That's not acceptable.
Then the ability to factory reset the phone would depend on having working network connectivity, on the manufacturer of the phone actually hosting those factory reset images, and on them continuing to do so indefinitely. It would stop being a feature you can actually rely on.
I'm almost sure that that is not the case -- for example, it explicitly asks whether to uninstall updates only when those are installed. Though I would love to know what the technical details actually are.
The pre-installed apps are on a read-only partition. And it's not a stub of the app, it is the full app. When you install an update for one of those apps, the device will have both the original version on the read-only partition and the updated version on a mutable one. Uninstalling will only remove the updated version.
There is no explicit factory image stored somewhere, the reset to a factory state is achieved by clearing the mutable storage. This achieves getting the device to a clean state since the read-only storage is guaranteed to be in the same state as to begin with.
(The read-only storage does get updated on an OS upgrade. That's why a factory reset will not downgrade the OS itself.)
Agreed for "bloatware" apps, but allowing users to delete actual system apps is ... a bad idea. Just imagine your kid deleting the "Phone" app, for example. And allowing vendors to flag apps as "not deletable" will only lead to them flagging their own bloatware apps again.
Google could also solve these issue by unlocking its own apps, so they can be removed. For example, I have absolutely no use for google assistant or chrome or duo, yet they take up insane amount of space on my phone.
An even better solution to apps? Web apps. They take up no space (unless using storage API), are always up to date by default, can be added to devices and act like a native app, better permissions in place (typically requests when needing to actually use something, and not granted permission forever), no app store delistings, etc.
App size is really tough to solve and bloat is way more common than you might think. The reason for this is usually that teams are focused on getting out features ASAP, but have no insight into how their changes affect the app's performance.
Our company, Emerge Tools (YC backed) is focused on trying to help devs solve the root cause of performance problems (size, startup time, etc.) by providing continuous monitoring and alerting for regressions directly on pull requests. We already work with some of the best mobile teams in the world (Dropbox, Faire, Life360).
If you have interest in mobile performance we're hiring! shoot me an email josh@emergetools.com
Bad software is being built based on the idea that you don't need to build a great application for users, but that you need analytics to sway potential investors or buyers of your solution. This trickled into becoming the norm, half the apps and websites we use have pounds of code and assets that are there to inform a half dozen 3rd parties of how much time I spent on a web page that I clicked, got distracted, and didn't even read anyways.
Bloatware needs to be punished in app listings and search results before we ever get some sanity back. (go google your nearest orthodontist and take a look at what they are loading into your browser just for you to see a read only web page in 2022)
So when can I use this tool to eat away at the huge chunk of my storage that is reserved by the system? Losing 10gb of my stock 32 is a tough pill to swallow.
This seems like a bad idea, since by the time you come to unarchive an app, it's probably not the current version anymore. It would be better to just retain a bookmark to the app on the Play store, save even more space.
On a tangential note, while it doesn't free up space, App Warden [1] can disable trackers and loggers for all the apps on your device. It's a must-have IMO.
App Warden seems to give a noticeable speed improvement on certain apps on older Android devices since they don't have to engage in the tracker/logger activities.
129 comments
[ 5.3 ms ] story [ 201 ms ] threadThere's probably so much bloat in frameworks, (illegal) telemetry and whatnot under the hood of those apps that should be tackled.
For example: Why is the the Amazon app 229 MB heavy? 195 MB is the app itself, then there's ~61 MB of "data" and only ~26,5 MB of cache.
It's a website, nothing more. How can it take 200+ MB of space? It's sick.
edit: How does Android even calculate those numbers? They don't add up at all...
edit2: see this recent post for reference: "I shaved 187MB off United Airlines' 439MB iOS app" https://news.ycombinator.com/item?id=30442529
I do agree that Amazon's app does seem to basically be their website, so I don't understand why it needs to be so big.
(And the numbers on my phone add up)
Even desktop OS don't go far enough. Would be nice if Windows and macOS came with a top 5 {mem,cpu} consumers drop-down in the global menu bar without having to install a tool or open task manager. We complain about bloated apps but without providing insights to the user, there's no pressure for apps to optimize.
If it seems like too much of a power-user feature, how about your run-tracking app silently closing on a long run because you were also listening to Spotify in the foreground? That's not a good experience. With no insights, all you have to act on is superstition. Do I need to find a run-tracker that doesn't crash or should I try a different music player? No data so who knows.
We still insulate users from this data for some reason even on mobile devices that LRU-close apps when memory is tight. Let the people know, dammit.
An app can already say 'I'm still doing a user visible action' (like logging a run, or playing music). Whenever one of those apps has to be killed to free up memory, a messagebox should be displayed saying "Spotify has quit due to low memory. Spotify was using 647MB and RunGPS was using 1454MB out of 3000MB system memory".
Google won't do much against it because the worst of the data hoarders are the f2p games that make money for themselves by selling the user data they can get their hands on and make also a lot of money for Google via all the IAP commissions.
https://en.wikipedia.org/wiki/Android_One
Couldn't they just penalize app size in play store rankings the same way they penalize slow sites in search results? Obviously for games and some types of applications you can't get around it, but I imagine Google has the resources to work around needlessly punishing those.
SD card is just not nearly as fast as NVMe storage or even UFS 3.
I worked on the main app for a top hotel brand and they wanted convincing why we should take several sprints shaving space off their builds.
They're struggling to get people off their phone lines and into the app.
Say a customer's on a mobile connection or crappy airport wifi trying to book a hotel. When a 30 minute download for your 400 mb app starts, guess what they're going to do?
Cancel it and call in.
It would also be foolish to think we know the answers of how to make amazon more money from our comfy arm chairs.
> I get why smaller companies use generic janky frameworks to throw up an app quickly and keep maintenance costs down. But why doesn't Amazon have the most streamlined and elegant app on the planet? They have the resources, expertise, and scale for it to make sense to invest heavily.
https://news.ycombinator.com/item?id=30613893#30614531
Another way to say this: the root reason for app bloat is something that causes general app badness, so the question "Why is the app so bloated?" is not well explained by your implied answer "Because users do not reduce purchases on account of app size".
But I think large apps and apps that crash frequently is correlated but not strongly. I have never seen Amazon crash. I have seen 4MB apps crash. Bloat by itself just means I have to buy a more expensive phone to fit everything I want, which sucks but isn’t the end of the world.
Given that I'm not sure why I should care as long as it works.
As a dev I agree it's technically interesting to find out why, as a user I think it just doesn't matter.
I can see why jumbo app wouldn't affect you.
I've got 7t on my desktop. Would you mind if chrome automatically updated to 1t. It's not a new computer pre-owned 2015
https://www.gsmarena.com/samsung_galaxy_a32_5g-10648.php
Or just trying to figure out how we can do "smartphone death by a 1000 Amazon apps"? :-))
No idea, but I would also like to know. My apps are so small that once they reported a negative size.
(Found the picture! https://imgur.com/a/KDI9Y4M)
If you program using the built in api only (this means the functions available to the target sdk, nothing newer) then your app size will be basically all assets, as code is very compact by itself.
But of course, coding is by far more complex, you are like doing native programming (although easier than c). My apps are small tools, so I can.
Oh, and don't use Kotlin. It's a wonderful language and far better than java, but horribly optimized.
I'd love to see them get in their walled garden and clean up the ecosystem. They are doing reviews obviously, so they can/should tackle the bloat, too.
Look here for example: https://news.ycombinator.com/item?id=30442529 ("I shaved 187MB off United Airlines' 439MB iOS app (telkins.dev)")
"Google kicked my app off Play because it was too big. WTF?"
I have removed most of Google's apps from my phone because of their extreme size.
Looking on my phone it looks like the award for most bloated goes to Google Play Services at 500MB. Wow!
As you can see from the breakdown: 34% of the app is native libraries, another 34% is dex, 23% is resources, and another 8% is assets.
Unfortunately they're still not using AABs, have about 4 MB of download size savings from just image optimization, have 1.1 MB of Emoji gif files , and are not optimizing their Native libraries for the specific architecture (using AABs would solve this)
I checked mine. 201 MB app, 115 MB "data", 202 MB cache, 518 MB total
Yes, the Amazon app, which literally feels like a webview wrapper around the mobile website, is taking up half a gigabyte of space on my phone.
Yesterday I was looking really hard on who exactly would be the seller for an item. Did not find that information on the app, while it's easily findable in the web version.
Or do I have some quirky version of the app due to some A/B testing?
This way it frees up the space used by the application data, without removing it altogether, so that the associated user data can still remain with it.
It’s the same concept as iOS’ feature to offload unused apps, but this appears to be implemented in a way that is backwards compatible with older devices since the Play Store is able to manage the process of replacing and restoring the app package and not the core OS.
I have many data points for which the main source of clutter on the phones are WhatsApp images and videos received in a lot of chats and groups. I know people that remove them almost daily to let their 16 or 32 GB phone receive another day worth of messages.
Maybe your hobby horse is different to other people's hobby horse, but that doesn't mean that other people's hobby horses aren't important.
This issue probably affects lower income people disproportionately, too.
I tried reducing all this to a minimum for my app and it helped getting more downloads and less churn. Now at 10MB download size, 40MB storage usage (10MB cache, 10MB data) and 5MB data usage. All this for a heavy user (myself).
It's also why Apple has pushed some technologies for developers to reduce initial app size; optimized builds per device (you send Apple a bundle with e.g. multiple images at different resolutions, Apple only installs the ones the phone actually needs), dynamically loading content like levels (so the initial download is only the core libraries + the first level, the rest is downloaded and offloaded dynamically), etc.
Turn iCloud Photos on? Even with "Optimize storage", that'll keep about 3-5GB of local thumbnails on your device, wasting space.
iCloud Notes on? Your 5+GB of notes will all be stored locally; no storage optimization there.
Use Apple Music? It'll use about 7-8GB of local storage, not for any downloaded songs (I haven't downloaded any) but purely for album artwork, cache, and other junk. There is no way to ever delete that Apple Music cache; not even cancelling Apple Music, turning off Cloud Library, or deleting the Apple Music app. The only way, is to reset the iPad completely, and delete the Music app before it can start syncing anything from the cloud. i.e.: you have to switch to Spotify.
These are all Apple apps.
When an iPad has low free storage, it'll delete user data from 3rd-party apps, and those apps have to redownload user data from the cloud every time you open the app. Notability is a good example. Everything's gone, wait 5min for it to resync.
The iPad might be my main device if Apple fixed this, and it would lock me much deeper into Apple's ecosystem, but they don't seem to understand the value of minimizing storage use.
On that, the larger your app is the bigger the target. When I run out of space on my phone I sort by largest app and start booting off the worst offenders. Small apps, even if I use them less often, are likely to fly under the radar.
Already, swiping an app away in the task manager awkwardly keeps it open in the background instead of closing. Now we awkwardly keep zombie apps.
Please stop predicting what users want, give them reality. You have 20 background apps, you see 20 apps in the task manager. You install 100 apps, you have to sort and group 100 icons. You either have a usable app, or no app at all. Then, the user can say "damn, this bloat sucks. Please make things lean and simple, Mr. Corp."
If I try to download a file, an app shouldn't need to get media permission. An app should be able to download files with either a download folder permission where it can write a new file but only read what it wrote unless explicitly given permission to
> Permissions are required for all files on Android 9 (API level 28) or lower
I'm not an expert, but unless I'm missing something, there seems to be a legitimate set of circumstances where the requesting of additional permissions is required to function correctly. It seems overly reductive to deposit this entirely at the feet of app developers.
[1] It contains a file explorer app – given that at least at that time Android didn't really have a proper built-in file explorer this is actually a somewhat sensible idea, but then on the other hand as a power user I still prefer a file explorer of my own choosing (and with root support), so it's still mostly useless to me. Other than that, it contains what looks like configuration apps for a few American mobile service providers, plus something like some sort of Brazil-specific app store – all completely and utterly useless, especially given that my phone was bought in Europe and is on the European software update channel!
It's a bit surprising phones can get away with this.
Conversely, maybe I don't want those pre-installed apps in the first place.
There is no explicit factory image stored somewhere, the reset to a factory state is achieved by clearing the mutable storage. This achieves getting the device to a clean state since the read-only storage is guaranteed to be in the same state as to begin with.
(The read-only storage does get updated on an OS upgrade. That's why a factory reset will not downgrade the OS itself.)
This is an example of google creating and signing a 'placeholder app' with the developers signing keys.
Obviously this example has benefits for the user... but an evil Google could use that same functionality to steal secrets from apps...
Our company, Emerge Tools (YC backed) is focused on trying to help devs solve the root cause of performance problems (size, startup time, etc.) by providing continuous monitoring and alerting for regressions directly on pull requests. We already work with some of the best mobile teams in the world (Dropbox, Faire, Life360).
If you have interest in mobile performance we're hiring! shoot me an email josh@emergetools.com
https://www.xda-developers.com/warden-open-source-app-aurora...