Final Project¶
Pull Requests
Android App Bundles¶
During this summer, I have been working on adding the feature to export MIT App Inventor projects as Android App Bundles, the new format that Google introduced just two years ago. With this new format, it is expected to improve app delivery through Play Store, reducing resources and bandwidth.
MIT App Inventor has a Community where they gather feedback from their users and provide support. So, I created a topic there to keep users updated on the progress of the project and to provide input about it:
A design document was published, where both staff members and users can give feedback on the approach to be taken for the project. This document was published in Google Docs, as thanks to the comment feature, feedback can be provided easily.
In addition, while coding during summer, Google made an announcement saying that Android App Bundles will be the only supported format in Play Store somewhen in the future. This is really great, as App Inventor will be prepared when the moment comes.
Finally, this project was fully finished earlier than the expected deadline, and
a test server was deployed so users could test the feature before it gets merged
into App Inventor sources. Also, an usage document was created so users can get
started with App Bundles, explaining some concepts.
NOTE: The Test Server will go offline after the Pull Request gets merged and deployed.
Implementing Android App Bundles was quite challenging, because App Inventor aims to support as many devices as possible, starting with Min SDK 7 [Android 2.1]. It is a bit old already (2009), so adding a new format that was introduced in 2018 was a bit challenging. Some things like the Android Asset Packaging Tool needed to upgrade to a newer version, but at the same time without breaking anything.
As the project was finished earlier than the deadline, the project got extended including a refactor of the current App Inventor compiler.
Buildserver Refactor¶
After finishing the implementation of Android App Bundles, I started to work in the
App Inventor Compiler refactor. App Inventor currently has in the buildserver/
folder all stuff related with converting block-based projects into real apps that
smartphones can understand. This project has two input files: BuildServer.java and
Main.java, of which the first one starts a Web API service and the second one in
command line.
Then, ProjectBuilder.java is called and triggers the build process, by creating a
Compiler instance. This file is the actual compiler, converting projects into apps.
It had nearly 3,000 lines of code, and it was a bit hard to maintain. So, my job
consisted in refactoring it, modularizing it to improve its future development. Also,
this was done thinking about the upcoming iOS version for App Inventor. Initially,
App Inventor only export APK files, but now with AABs and upcoming IPAs, it was a
good idea to start looking forward, and prepare the Compiler for those formats.
The main idea for the new Compiler was to be modular, so each "step" will have its own
class file, implementing the Task.java interface. So, these tasks can be re-used with
any new build type. These tasks can be added to an Executor.java object, that will
run each of them in the order they get in (a queue list).
This Executor instance will get a Context object from ExecutorContext, which specifies
all details for the build, including the build type.
See the new usage in action:
// Just pass all parameters to Compiler, and automatically run all steps
boolean success = Compiler.compile(
project, componentTypes, componentBlocks, console, console, userErrors,
isForCompanion, isForEmulator, includeDangerousPermissions, keyStorePath,
childProcessRam, dexCachePath, outputFileName, reporter, isAab
);
// Initialize the Reporter object
// It will log all important stuff, including errors
Reporter r = new Reporter(reporter);
// Initialize the ExecutorContext
// It contains all the data for the build
ExecutorContext context = new ExecutorContext.Builder(project, ext)
.withTypes(componentTypes)
.withBlocks(componentBlocks)
.withReporter(r)
.withCompanion(isForCompanion)
.withEmulator(isForEmulator)
.withDangerousPermissions(includeDangerousPermissions)
.withKeystore(keyStorePath)
.withRam(childProcessRam)
.withCache(dexCachePath)
.withOutput(outputFileName)
.build();
// Create an Executor object
Executor compiler = new Executor.Builder()
.withContext(context)
.withType(ext)
.build();
// Add the needed tasks for the build
compiler.add(ReadBuildInfo.class);
compiler.add(LoadComponentInfo.class);
compiler.add(PrepareAppIcon.class);
compiler.add(XmlConfig.class);
compiler.add(CreateManifest.class);
compiler.add(AttachNativeLibs.class);
compiler.add(AttachAarLibs.class);
compiler.add(AttachCompAssets.class);
compiler.add(MergeResources.class);
compiler.add(SetupLibs.class);
if (BuildType.APK_EXTENSION.equals(ext)) {
compiler.add(RunAapt.class);
} else if (BuildType.AAB_EXTENSION.equals(ext)) {
compiler.add(RunAapt2.class);
}
compiler.add(GenerateClasses.class);
compiler.add(RunMultidex.class);
if (BuildType.APK_EXTENSION.equals(ext)) {
compiler.add(RunApkBuilder.class);
compiler.add(RunZipAlign.class);
compiler.add(RunApkSigner.class);
} else if (BuildType.AAB_EXTENSION.equals(ext)) {
compiler.add(RunBundletool.class);
}
// Create a single thread Java Callable object
// to run our Executor
Future<Boolean> executor = Executors.newSingleThreadExecutor().submit(compiler);
// Run it, and wait for the output
boolean success = executor.get();
As it can be seen, this new Compiler is way more modular, which makes it perfect to support multiple build types. However, this project is still a work-in-progress, as it will need a lot of testing to make sure all edge cases are tested and work. And also, it will need documentation, so developers can get used to the new system easily.