Repository navigation
Align asset storage with underlying platform #16015
Description
Moving over @tvolkert's comment from #11019 :
We should be moving towards the goal of storing our assets in the locations that the underlying platform would otherwise store them. e.g. for Android,
res/
drawable/
drawable-hdpi/
drawable-mdpi/
drawable-xhdpi/
drawable-xxhdpi/
drawable-xxxhdpi/
There a suites of tools for packing, optimizing, and so forth an app's final bundle that gets distributed through app stores, and they all assume a certain layout of assets. Our current layout, harking from the days of FLX, doesn't play nicely with these tools. But now that we've gotten ourselves away from FLX, we should have more flexibility here.
e.g. for Android, they're moving towards a model where you don't upload an APK to the Play Store, but rather upload all the constituent parts of your APK, and when a user installs an app, the store cleverly constructs the thinnest APK it can ship to the user, containing only the assets that make sense for that user's device-pixel-ratio, locale, etc.
Activity
lukef commentedon Mar 28, 2018
There is a secondary issue that will need to be addressed. Some assets will be iOS specific and some will be android specific so flutter should provide a mechanism to isolate platform specific assets before copying/migrating to the resource locations. Otherwise, all assets will be available on all platforms for no real reason. There will be an issue if you try to "emulate" iOS on Android and it is missing assets but this could be dealt with by the developer and seems like it is an unlikely end-user scenario anyway.
tvolkert commentedon Mar 28, 2018
@szakarias do you think this fits in with the other M3 work, or is it post-M3?
szakarias commentedon Apr 5, 2018
Post-M3 as discussed.
Albert221 commentedon May 31, 2021
I just wanted to bump this issue. Having Flutter's resolution-aware assets is really nice, but it would really improve on end-user's app size if they would be included for certain pixel densities in AABs.
jonahwilliams commentedon Sep 18, 2024
We don't plan to do this
Albert221 commentedon Sep 18, 2024
Just to fully understand here: we can only use resolution-aware assets at the expense of the app size and that's intended and by design? Or does the Flutter team have another idea for how to optimize keeping many resolution-aware assets in asset-heavy apps? Or would we like to have this implemented but the Flutter team doesn't have the capability for this in the foreseeable future?
jonahwilliams commentedon Sep 18, 2024
Its not possible to change the existing asset system to align with how android resolution aware assets work. A second android specific asset system would need to be written, which we don't plan to do. Instead, we're working on better platform interop so that it is easier to depend on platform specific code/assets
github-actions commentedon Oct 2, 2024
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.