5 ms·
If "optimize[d] download sizes" is the goal, Google could simply release a tool that performed the compression/etc on a bundle (pre-signing) and require[1] that
by pdkl95 5y ago
If "optimize[d] download sizes" is the goal, Google could simply release a tool that performed the compression/etc on a bundle (pre-signing) and require[1] that apps must be processed by the tool before submission.
[1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.
- Gaelan 5y agoThat doesn't work if there's a large and possibly growing matrix of hardware/OS/whatever combinations they're trying to optimize for.
- pdkl95 5y agoI've only mentioned one example of how such a tool could work. There are many ways this typ0e of system could be designed. For an alternative that doesn't depend on the number of output combinations, see GauntletWizard's example[1] that uses a signed manifest of files. [1] https://news.ycombinator.com/item?id=27177425 https://news.ycombinator.com/item?id=27177425
- Avamander 5y agoIf they have the tool, they could give the tool. It's not like it's very often that a totally new arch + DPI + Android version combination appears.
- cwyers 5y agoThe point is, if you build a signed app meant to run on any device, you are going to include code/assets for all of them. What Google wants to do is basically "tree-shake" the APK so that when you download it, it only contains what you need for your device.
- Avamander 5y agoStill, if they can generate the "shaken-down" version the dev could as well.
- izacus 5y agoThat tooling exists for a few years now - I don't think a lot developers opted to use it though.