Open GApps logo
Navigation
Some early statistics

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.

architectures

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.

apiversions

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.

variants

Reliable and Trusted GApps?

Hackerz

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.

ROMs

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…

Source code

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).

Proprietary GApps

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.

Do-it-yourself!

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.
  • Extract META-INF/CERT.RSA from 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 keytool command.
  • 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 make command and create your own trusted GApps.

By completing these steps, you have your own trusted GApps package (as long as you trust Google).

Track progress

We are still busy trying to improve in this field, if you are interested, please take a look at our tracking issue #92

Material Design Development

OpenGApps.org currently enjoys a nice Material Design Lite layout. But it did take some effort to get there…

The beginning

The intial website of Open Gapps was made from a GitHub template, with some little changes to the colors and mostly some javascript hacking for the download widget. The website did suffice for the most basic needs, one could easily download a GApps package easily on desktop and mobile. But the website itself was very ugly.

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.

Prototype

So raulx222 hacked away and had within a day a prototyped website ready. Clearly it was not done yet, because there were still some issuse with parts of the layout, but it showed great promise. So MastahF got hacking away at the javascript. This was quite tricky, because several race-conditions appeared between the different javascript objects and libraries that we use. The GitHub API queries are e.g. performed via javascript and this implies that some of layout can only be rendered after an asychronous callback. Meanwhile the Google AdSense banner (that gives our project donation fund some income) is also rendered via javascript to have a responsive layout and Material Design Lite also uses javascript, especially to ‘upgrade’ the ‘normal’ HTML widgets into ‘Material Design’ widgets. The automatic download mechanism can only be run when the Material Design is rendered (because it needs to fetch the selected radio buttons) and when the GitHub API request has returned (so that it can know if the seletions where valid and that it can fetch the URL of the most recent build). These javascripts were all conflicting, e.g. sometimes the AdSense banner was rendered ‘behind’ the layout that was rendered by Material Design Lite, at other moments the website rendered by Material Design Lite did not show the content from GitHub when initially opening the website. Or the download would not activate, or would refer to a non-existent broken URL, or downloads would be triggered twice, or it would block the loading of the AdSense banner, etc.

Javascript hacks

Apparently the javascript needed some small hacks, so that it would give consistently the correct output. E.g. we now let the the AdSense banner rendering-script to first force the Material Design Layout, so that its size can succesfully been detected, applied and rendered. And only if those scripts are completed, the automatic downloads are triggered, or the it would fail at processing the MDL-form. And any response from the asychronous GitHub Query calls force the Material Design Layout to be re-rendered.

Automatic downloads

After this javascript hacking was done, raulx222 fixed the last issues with the layout. Some things could not be fixed though, e.g. we could not let the page open with ‘About’ by default, in combination with the automatic downloads because Material Design would not render the invisible radio buttons which would have to be processed. Meanwhile Material Design Lite does not allow (yet) to hotlink to another tab, so we could not let the automatic download links automatically be switched to the downloads tab.

Going live

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.

The future

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.

Mobile experience

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.

Crazy Chrome

Crazy Chrome!

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.align and 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!

Material Design Website

We updated our website with Material Design! Bookmark it with Add to Homescreen to easily download the latest packages to your device. Small JavaScript issues still have to be resolved, so stay tuned.

OpenGApps.org HomeSupport by DonationSource on GitHubCommunity on XDA ForumManual on WikiFollow via PushbulletDownload Open GApps AppOpen GApps BlogOpen GApps on FacebookOpen GApps on Google+Open GApps on TwitterOpen GApps on YouTubeOpen GApps AppAds help us to keep OpenGApps.org packages freeAds help us to keep OpenGApps.org packages freeAds help us to keep OpenGApps.org packages free