The very first initial Open GApps’ buildscript was published at May 2nd 2015. That means we can celebrate our first anniversary!
Start of the project
At very beginning the project was not yet branded as Open GApps, but released as a very rudimentary prototype of what could be done using shell scripts to rebuild a legacy PA GApps package. There was no separation of build-scripts, sources and processed APK storage yet. Neither was the code of the high quality and many errors existed at that point. But we have come a long way. By a lot of testing by the community, feedback and reading through many debug logs most bugs have been squashed.
Improving Open GApps
All code for the build-scripts have been overhauled since that first version, to find the a durable design that could be scaled well. We have come a long way, from supporting only stock 5.1 packages to supporting all variants, AROMA support, becoming the first GApps that supported building for non-arm platforms and currently supporting all platforms and all major Android versions. Even support for flashing updated GApps on stock Nexus ROMs is supported! But next to all these variants and platforms support, a lot of development goes into extending features. Both device-side, where we could build further upon the foundations laid by Osm0sis and TKruzze to introduce new features. But especially on the build-side, where the build-scripts and tools used have been greatly enhanced. E.g. the APKCrawler project by MNBooze has been of great value. Open GApps is the prime supplier of GoogleAPKs to APKMirror because of it, and the pre-built OpenGApps.org packages are always having the very latest APKs thanks to these great scripts. But also other features, like verifying APKs for authenticity, re-packaging Marshmallow APKs but also automatic detection whether a SetupWizard is made for phones or tablets has all been automatized and is now a matter of mere seconds!
Also the project has greatly benefited from registering OpenGApps.org to make the project more visible and offering convenient downloads to users. This would not have been possible by help from many various contributors who all thought of possible improvements and took the initiative to provide a better user experience!
So what is ahead? Currently we are busy overhauling the build environment, to improve the speed of the building process. That will allow for continuous integration and automatic testing to provide the build quality and faster release of new builds. Also dynamic builds will become feasible with this new build environment, enabling the possibility to build packages that can be flashed on any platform. Also we are still busy with developing a package for Android TV, but because I (mfonville) lack an Android TV device myself, I can’t test which makes it hard to debug some issues.
Since November 2015 Google updates their Google Dialer application via the Play Store. The Open GApps scripts already supported the inclusion of Google Dialer as a package already before that, in October 2015. But the Google Dialer app faced many problematic issues at the time. I.e. before Google released their Play Store version, installing the Google Dialer would not work on any custom ROM. Because of these issues Google Dialer was not included in the regular Open GApps packages.
In March 2016 we finally enabled, after some testing with the Play Store version, the Google Dialer as an optional extra. Using the
DialerGoogle keyword users could install with the dialer to experiment on their device. The feedback from users was that on Nexus devices it worked, but on almost all non-Nexus devices there were problems. But even on Nexus devices, it was obligatory to manually set Google Dialer as the default Phone app, otherwise the device would reboot when making or receiving a phone call.
Instructions how to set the Google Dialer as default phone app
Fast forward to April 2016, and more changes have been applied to
DialerGoogle. It ain’t a special keyword anymore, but now acts as a regular include/exclude keyword. Also
DialerGoogle has been split into a supporting
DialerFramework package, that includes the Framework-files. While
DialerGoogle is only in stock and larger, these Framework-files are included in all package variants. The Framework-files are required to be able to install Google Dialer from the Play Store, without them any device is deemed incompatible. The
DialerFramework is obligatory if you want to install the
DialerGoogle package (if you are using a
DialerFramework is only installed on white-listed devices, currently this white-list only includes Nexus Devices. You can override the white-list using the
It is important to note, that the
DialerFramework only receives any security updates if you update your Open GApps installation and not via the Play Store. So make sure to update your Open GApps installation at least once a month, after Google’s monthly security updates are added to the Open GApps repository.
It was time to crunch again some updated numbers from the opengapps.org website and the pre-built packages downloads. To gather the stats I wrote some better tools (Python instead of my old shell scripts) that fetch the data from the GitHub API, so future updates will be more easy.
The average amount of unique daily visitors at opengapps.org is according to Google Analytics around 55k. The amount of ad-blockers used is way over 50%. No surprise there with our tech-savvy crowd, luckily some people do contribute by donating instead, for which I am very grateful! By multiplying the amount of downloads of each package variant with its size we were also able to find out how many bytes of packages are downloaded everyday: 30TiB, happy to be hosted by GitHub’s cloud! So, what packages are being downloaded? I compiled two sets of data, lifetime stats and those of March 2016, below.
In this chart we see the architectures. Clearly ARM is still most popular. But ARM64 is gaining ground and also x86 is becoming more frequent. x86_64 Doesn’t exist that long and has such little share that it is marked as Other by Google Fusion Tables.
It is visible that 6.0 gained ground very quickly in the total number of downloads. One major reason is that opengapps.org is still quite young (less than a year old) and 6.0 was released when the project was still gaining popularity. The 5.1 high tide has been missed.
Super has been introduced more recently and is still not as popular as the other packages. Easily explained by the fact that it is only meant for power users that want to use a gapps-config with some of the more exotic applications.
March 2016 Architectures
In the March architectures overview you can see there are no major shifts compared to the lifetime stats, but ARM64 is very slowly growing.
March 2016 APIs
In the March APIs it is visible that 6.0 is now the de-facto standard for ROMs. 5.0 is shrinking. Also 4.4 is becoming less popular.
March 2016 Variants
In the March variants overview it is visible that the smaller pico and nano packages are gaining. It seems that the growing size of Google’s apps makes stock not always fit on
/system/ and leads to people switching to smaller packages, especially compared to the popularity stock had on 5.1 in September last year. Also aroma did shrink compared to September 2015, very probably caused by the unmaintained ‘AROMA Installer’ and the more frequent issues it poses on various devices and recent recoveries. You can read more about that in Raul’s post.
Earlier I used to build busybox on my Android device itself, but it soon posed an obstacle, as I could only support ARM architecture. So I decided to delve in the cross compiling business. I use custom-built buildroot toolchains using uClibc C-library to get the smallest and full-featured busybox binaries possible. This helped me support all the Android architectures available.
Open GApps busybox integration
Initially mfonville reached out to me for building a
busybox binary with lzip support included as he was trying out lzma compression over xz, because xz embedded in the busybox binary wasn’t fully functional. Finally it was decided that the installer will stick with xz as lzip was much slower and provided almost the same level of compression compared to xz. But the xz-embedded code that is part of the busybox source tree, was more of a hindrance because of its limitations and errors. So I was asked if I could also build an
xzdec binary for the Open GApps project.
Bugs and Issues
Then came up an issue on github where Tegra 2 device owners were getting “illegal instructions” error. Soon we realized that NEON support was the culprit here. Apparently even a modern SoC such as Tegra 2 lacked something as subtle as NEON support in their devices. The toolchain I built was configured to have VFPV3 support with NEON by default. So as simple as it may sound the solution was to build a toolchain without NEON support and using that to build busybox which was much easier said than done.
I also assisted the project by building the infozip’s
zip binary for advanced APK manipulation. Soon there was a hiccup in the working of this zip binary. MFonville and I invested a lot of time in bug hunting and it all came down to a nasty little variable
$ZIP that was misleading the zip program. It was also addressed by XDA member osm0sis in his post.
Head over to my XDA thread for more information about my busybox binaries and their latest version.
For any readers visiting this post on or after April 2, check the post date before continuing :)
The Hague, Apr. 1, 2016 - The Open GApps Team is very excited and proud to announce it’s been acquired by Google Inc. Google’s CEO Sundar Pichai explains how this latest acquisition is part of Google’s updated strategy as an Alphabet company: “By strengthening the Android division we can encapsulate even more of the Android market share, by acquiring Open GApps we directly gain over 90% marketshare of the AOSP-based installs and is proof of our commitment to ‘be together, not the same’.”
The Open GApps developers are very happy with the acquisition. MFonville is tasked with heading Google’s new shell-scripting division and a GSoC-project for developing a new “gsh”-shell. Also MNBooze is very content: “I will be relocated to the Google Campus and will be creating a Python based crawler that searches the Google-Docs department to find their newest APKs. This will enable us to release APKs even before they will reach the Play Store!” Raulx222 will join the Material Design Lite Project to bring MDL to the AROMA Recovery.