I will be bringing the option to export the current MIT App Inventor projects as Android App Bundles (.aab), in addition to current APK files. This format was designed by Google to optimize apps delivery through Google Play Store by automatically generating platform-specific APKs. It does not replace APK files as they cannot be directly installed, and they just allow to produce more âprofessionalâ apps in the platform.
In the document below you can find an implementation proposal with more details about this new format, its advantages and how it can be implemented. Any kind of comment and/or suggestion is very welcome to make the final implementation as straightforward and understandable as possible.
As you can see, there are two main sections: one for app developers and another for core contributors. Most of the work in this proposal resides in the backend and is non-visible, so sorry in advance for the lack of images you may find compared with other proposals.
It would be really appreciated if the possible choices stated in the document could be discussed (here or in Google Doc comments), as there is no âperfectâ solution for everything.
And feel free to point-out any thought or question you have.
Thanks everyone for checking my project and making App Inventor better!
To get things straight⌠for me and maybe others. Please correct me if i am wrong.
A user would still have to build an APK or has to use the companion to test his app on his phone locally?
The AAB option is only useful when you put your app on Google Play.
You can not install an AAB package directly on your phone. Google uses it to install only the necessary parts of the app on your device saving bandwidth and space on your phone. In essence you are still installing an APK but then composed by Google from your AAB.
When you want to use the AAB option you have to enroll in the app signing program by Google Play.
I think maybe there could also be another benefit in using AAB instead of an APK and that could be âsecurityâ, but correct me if i am wrong. When you choose to put your APK on Google Play or any other website you have the chance your APK will be taken with the possibility that your APK could be modified to serve ads or maybe assets can be changed.
What i understand from your proposal and how AAB works, when you install the app you get an APK that is tailored for your phone. So if you would generate the APK again locally, if that is even possible, then you would get an APK that will work best on your phone but could give problems when installed on another phone?
Or I think Iâd like the download now button at the very bottom with the <hr> directly above it.(I couldnât figure out how to achieve this on my phone)
You got it right. Just mentioning one thing: from the AAB you can also generate the corresponding APK files through the command line using bundletool. With that, you can technically test the AAB, because you would be generating the same APKs as Google Play will generate when distributing it.
The logic Google placed in AAB files is something like: "why should developers generate platform-specific APKs, when we could actually do it from the universal APK by modifying it a bit?". And as the APK is already compressed and signed, they designed the AAB for this.
Humm, I don't really think so. Security will be improved right, but it's not the main point in AAB. Talking about modifying its source code, the only advantage the AAB will give is that people that decompile and re-distribute modified apps will have to do more work. They will not get a single APK that works in all devices; they will only get the APK that works in the same type of the device they have. Or what is the same: they will only get a version compatible with a few devices.
All sites that distribute modified APKs will have to show plenty of possible APK combinations if they want to support all devices. And as they said in the presentation, there are 960 possible APK configurations (ignoring the possible locales, it is 24). So, they will have to modify at minimum 24 APKs if they really want their mod APK to support all devices.
The problem would appear if someone could get their hands in the AAB, as they could just open it, modify the dex files and use bundletool to generate all possible combinations.
Humm, I don't really get what you mean with "generate the APK again locally". You are right saying that you get a specific APK that works with your device configuration (let's say, arm64 xxhdpi). But that is only when you install the app from Google Play Store. They deliver just the correct APK to your device.
Working locally, you can build the AAB using MIT App Inventor, and then use bundletool to build all possible combinations, and you can just pick the appropriate one for your device. Or you can add the --universal flag in the command line, and you will get the classic universal APK that works with all smartphones.
Right, it may be another interesting possibility. I also want to test what Evan suggested, by placing them horizontally, so it gains visibility.
I'll share screenshots as soon as I have them.
So, i guess this is not something the online version will do? It would have to produce 24 APKs and that would put a strain on the AI buildservers. But what if i know which one i should need especially for my phone. Would it be possible to just build the one i need, or if i give my phone details, App Inventor knows which one to build?
Maybe this is outside the scope of your GSoC project but just fantasizing.
Oh, okay. Yes, you are right. Users will only get the APK that is compatible with their device. So, that APK will only work with devices that have the same screen density and the same processor architecture.
Yeah, it would probably collapse buildservers. Imagine having 100 students building each of them 24 apps at the same time.
Humm, technically, it is possible to detect the configuration your device has, and generate the appropriate APK. You can just plug-in your device to the computer, and using --connected-device flag will make bundletool to just build the APK that suits your device.
It is out of GSoC, but I will also probably be working on the refactor of the Compiler, so I could maybe consider writing a little tool for App Inventor with the most common usages of bundletool for users. It may be useful for users who aren't used with command line, but they want to work with AABs in their computers.
Just thinking out loud...
I would rather we just generate the universal APK, which would be in line with what we do today. This way people would not have to run bundletool on their machines (which seems antithesis to App Inventor's design goals).
Edit: I would point out we don't know anything about the type of device people have. Some people also have iPhones, so...
I think we were talking abort how distribution from Google Play Store works (not working locally in a computer, it is about working locally referring to apps that are installed in end-users' phones). When you upload an AAB to Play Store, they build all possible APK combinations. When an user requests to install an app from Play Store that was uploaded from an AAB, Play Store delivers the specific APK version for that device (else there is no reason for AABs, as the delivered app was not optimized).
Correct me if I'm wrong, but I think Peter meant what happens when an user tries to get an APK from the installed app from Play Store. And as Play Store delivers the specific APK for that device (so bandwidth and resources can be saved), users will be able to extract only that specific app (because the universal and others are not delivered).
It doesn't have anything to do with how App Inventor handles the implementation internally. It's about how Play Store works with AAB to deliver only the required source files to the correct devices, saving bandwidth and resources.
If Play Store delivered the universal app, this image would not make sense:
The overloaded APK file would be delivered, without optimizing anything at all.
Iâm not talking about how Google Play does it. Iâm concerned about your claim in that post, specifically about App Inventor end users building specific APK versions for their devices. Iâd rather we not go down that route at all and just encourage people to use the APK build option instead.
Humm, okay, sorry for the confusion, it was just a suggestion. Maybe some people would want to build APKs themselves from the AAB, so maybe providing a tool could help.
But you are right, it can bring complexity and confusion to users who are not familiar with that, and coming down with lots of questions like âwhy do I get the parsing package errorâ or things like that.
Sorry if i caused confusion with my questions. I was asking those to understand how AAB works and what it does and what it would bring to App Inventor when implemented.
At least in the documentation you will have to explain what it does and how it works like i commented below.
Iâve just run some tests after applying Evan and Bekaâs suggestions for the dialog to avoid banner-blindness. I personally really like this layout:
The âDownloadâ button gains importance, right above the link in case someone shares a screenshot of the dialog to a partner. The QR/barcode image goes to the right, but gets its own space, by moving the âwarningâ label right below to the link with a bit of upper margin. The warning label has been changed from âthis barcode is onlyâŚâ to âthis barcode and link are onlyâŚâ to also mention that both link and QR code expire.
I have considered adding a separator between both sides, but I felt like it was de-linking the warning label to the barcode, like if it were not related to that.
Also, with this layout the dialog is much more balanced when talking about width-height ratio, as the other alternative was quite taller.
One minor suggestion, rather than having âDownload .apk nowâ as the button text, make the button have an image of a big download icon, such as the Cloud Download icon from https://material-ui.com/components/material-icons/ and have the title of the button be the download message (for accessibility). This way we can scale the download button to be the same size as the QR code so it gets equal visual weight.
Iâve run a few tests with an icon in the button, and this may be the one that I like more:
The button gains attention thanks to the icon, and it is not as big to âsaturateâ the interface. Also, it has text, which makes it easier for the user to know what they are downloading, rather than having to wait for the title to appear. See also the title changed from âDownload .apk for $appNameâ to âAndroid App for $appNameâ. Thereâs also an alternative layout below with a vertical alignment inside the button.
Click to show alternative layouts
I have tried to set a button with the same height as the QR code, but it feels like the QR code has more importance because it has more black area than the button, so it seems like the button is just a static icon, that users have to click the link to download. All layouts without the text in button have the HTML attribute title="Download .apk now" that appears when hovering, but I felt like it was not intuitive for mobile devices
Text below in big button | Warning in container panel | Updated title This one seems to be fine, but I personally preferred the horizontal layout rather than the vertical one
No text in small button | Warning in left panel | Original title This one seems to have a too-small button
No text in big button | Warning in container panel | Original title This one seems like the button is static, just a plain icon, that users have to click the link to download the app. It seems like the link gains more attention for being blue, and the download button pointing there
Since the button and the link effectively serve the same purpose, couldnât we just combine them? For example, if the button were actually an <a> tag styled to look like a button, youâd still get all of the benefit of the link (shift+click to open, right click to copy the URL, etc.) without needing to have two elements that duplicate the interaction?
Right now my preference visually is for the button with the icon and text arranged vertically. Possibly add a vertical bar as a divider between the button and QR code with the text or vertically centered, and under the QR code add the text âScan with barcode scanner to installâ underneath to mirror the download text.
Now, both button and image have the same dimensions. Well, the same âvisibleâ dimensions because the image actually has a big white area around it.
There is also a vertical thin line as a separator between the download button and the barcode download link.
Also, now there is no <button> element. Instead, it is an anchor <a> tag with the same styles as a button, so you can actually right-click the fake button to get a download link:
As it can be seen as well, there is no link. Instead, users should get this link by using the right-click (or long-click in mobile devices), as it is easier for someone to get a text link rather than an image with a link which they cannot copy-paste into the browser. Moreover, now the layout gets more symmetric as there are the same elements on both sides.
And finally, the âwarningâ label gets updated by adding bold text with information on how to use the dialog.
