OpenGApps is a relatively young project. If you check our domain information, you’ll see we registered opengapps.org at June 27th 2015, so that is only 3 months ago! But the project has been received quite well by the community, and each day we keep attracting more people to our website, and more stargazers at GitHub.
Currently we have around 12.000 daily visitors at opengapps.org, in the weekends even more. Around 45% of those go directly to our website, so probably our loyal group of flashaholics who bookmarked the website :-) The other visitors are referred to us from a varied set of Android related websites. As to be expected, XDA Forums is the largest, but also many non-English forums and various ROM hosting websites refer their visitors to Open GApps.
Our number of daily downloads is even a little bit higher than the amount of visitors on opengapps.org, because some users (e.g. those using Pushbullet) directly browse to our releases section on GitHub, without ever going through our website.
We gathered some download statistics over the period of 17th of July to the 23rd of September and created some graphs to give more insight into which packages are most popular.
First we can have a look at the most popular platforms. Unsurprisingly ARM is the most popular, taking around 91.3% market share. But is interesting to see that ARM64 is already 6.1%, while the amount of 64 bit devices is relatively limited. With the new set of high end Android devices to be announced this fall we expect this number to increase.
Another interesting graph is the set of Android versions that are chosen. 5.1 is clearly dominating, with most custom ROMs being based on the latest Lollipop release. What surprised us though, is the amount of 5.0 downloads. With 6.7% the market share is not large, but with Google itself having released 5.1 very quickly after 5.0, to fix some serious issues, it is surprising to see that any ROM is still 5.0 based. Especially considering that CyanogenMod’s 12 (=5.0) branch did also never really mature before switching to 12.1 (=5.1) and e.g. lacks important (security) fixes.
Our final graph is the set of variants chosen. The discontinued fornexus variant is left out of the graph since its functionality is now embedded into the other variants (and it had less than 1% anyway). As you can see the stock package is the most popular, probably helped by being the default choice when visiting opengapps.org without any preset parameters. But all packages have quite some serious share, which shows that there is demand for all the flavours. Not shown in the graph, but important to notice, is that the variant preference varies by Android version. E.g. the devices with Android 4.4 tend to have a small
/system/ partition, resulting in the smaller packages being more popular. While for 5.1 the larger packages like stock and aroma are popular choices.
In normal ‘educated’ computing practice, no one in their sane mind would download a random executable-file from some unknown person on the internet, grant it all administrator rights to your system and happily keep using the device for banking and other confidential and trusted purposes.
But still, this is what almost everybody with a Custom ROM does… First they download a ROM created by somebody on XDA and put it on their device. Then they download a GApps package, probably also from XDA, and again they just install it on their device. Then they set up their Google account, install their banking app etcetera. No one seems to worry about possible security vulnerabilities in that process, let alone possible malicious intents…
Luckily, for the ROM there are already relatively good solutions in place. Most ROM developers publicize their development work in a Git repository already. One can review their code, clone the repository and compile their own ROM from these sources. Creating their own safe-to-install version, that can be trusted not to have malicious content (only if you have the time to check all the code, though).
With the GApps, that is more difficult. First of all, the GApps themselves are not open source, neither will they probably ever be. But at least most people have good faith in Google and trust them not put some malicious code within their applications. But still, how could one know that an app in a GApps package is really from Google?
System APK Verification
First the bad news: The Android platform itself will not help you in verifying an APK that is going to be installed on
/system/. None of the applications that is installed on
/system/ will be verified for having a correct signature. That is why one should always be very careful when flashing any ZIP package from recovery.
Open Source GApps Packaging
So how could one generate a trusted GApps package? Well, key is that the generation process of the GApps package has to be open and reproducible, which is a key aspect of our project. Because only if you can perform (or fully check) all exact steps yourself, one can trust the outcome. We at Open GApps care about this and therefore trying to give you the tools to do so. In the meantime, we also try to improve our own build process to have more safeguards for the integrity of our packages. We try to achieve this by integrating more automated checks for certificate and integrity checking of the APKs that are used in our source repositories and GApps packages.
As second the good news: a simple cookbook to a safe GApps Package:
- Download a trusted Google Nexus Image and extract a Google APK from it, or download a trusted Google Application from the Google Play Store.
META-INF/CERT.RSAfrom the APK, extract the key that is used for this certificate (e.g. command:
openssl pkcs7 -inform DER -print_certs -text) and store it in a keystore with the
- Download the Open GApps source from GitHub and review the code. Also review the code that is used from third-party tools, like the SignApk.jar and if necessary compile them yourself or choose not to use them.
- Adapt the Open GApps build process to only let it use the keystore you created earlier.
- Check if the certificates of the APKs that will be used to build your GApps package all match the keystore you created earlier.
- Run the
makecommand and create your own trusted GApps.
By completing these steps, you have your own trusted GApps package (as long as you trust Google).
We are still busy trying to improve in this field, if you are interested, please take a look at our tracking issue #92
OpenGApps.org currently enjoys a nice Material Design Lite layout. But it did take some effort to get there…
Material Design Lite
The moment Google released their new Material Design Lite Project and mfonville and raulx222 got directly interested, the toolset was simple and it allowed to adapt a simple HTML page into a full Material Design compliant website with near-native look and feel for a webapp easily.
We decided to go live at one moment though, because it was good enough of an improvement over the initial site and we have received a lot of positive feedback.
We will keep adding small improvements to the site, especially when Material Design Lite gets updated. We especially look forward to their 1.1 update which is planned for October, which will include even more Material Design components like Snackbars and Toasts, which we plan to use for e.g. the obligatory cookies warning.
I hope you guys like the website and we have a small tip for you: If you open the website in Chrome on your Android Device, you can add the website to your homescreen. When doing so, the website will behave completely like a native Material Design Android app. In the future we will expand the features of this app, when technically possible (there are still some GitHub limitations) with e.g. push messages for updates.
Last week was quite a hectic one for the packagers and developers of Open GApps. Google released a new stable branch of Chrome into the Play Store using their own forked ‘Crazy Linker’. At first this was unknown, so when the new Chrome got committed to the repository suddenly different errors started to appear.
So, what happened and what went wrong? An application like Chrome is stored in an APK, which is a kind of ZIP-file. Normally, when preparing an APK to be included on the
/system/ partition of your device, all files that are part of the lib-folder within this APK are extracted and stored separately in a
/lib/-folder next to the APK. The APK itself is stripped from this lib-folder.
But when Chrome started to use this special linker application, this has changed. Suddenly we should not extract everything from
/lib/, but exclude
crazy.libchrome.so from extraction. They have to be kept within the APK in a special non-compressed manner.
So this had to be implemented in the code of the Open GApps scripts, which was done in a quick (and dirty) code fix that had to be ready within a few hours, so that everything would be in place for next day’s release.
In the end, everything worked out, and you as user might not have noticed anything. But for us it were some hectic hours, trying to find the source of the errors and fixing it!