Hello everyone! It’s been a while. You may have noticed that our website has undergone some changes. Today we’d like to share what has been going on with the hosting situation at GitHub and shed some light on our decision to transfer our releases to the SourceForge.

The problem

In the previous post we’ve descibed the nature of problems with GitHub and how we had to move the APK repositories to our Gitlab instance.

This summer GitHub gave us a new restriction - we had to remove the ZIP packages from the releases, since they were taking up a lot of space and generated enormous amount of traffic. Having around 700,000 visitors per months is quite a load for the hosting.

We considered many options:

• selfhosting releases, like we do with our Gitlab instance (Hetzner);
• using some kind of S3-like storage (Backblaze, Wasabi) under the CDN (CloudFlare, KeyCDN);
• using a full hosting solution with mirrors (SourceForge).

The solution

After the long discussion and testing within the group and the community we’ve decided to choose SourceForge.

This gives us a few benefits:

1. Cost - other options are very costy and we just can’t afford them in the longterm;
2. Speed - SourceForge automatically mirrors your files, giving you the best mirror available for the download;
3. Simple transition - we were able to transfer most of our releases from the GitHub repos without any issues, lowering the amount of work;
4. Release process - SourceForge has a lot of options regarding the creation of the new releases, in our case we’ve picked rsync.

There was a drawback though. GitHub has a very rich API which we (and many other people) were using, so we had to compensate for that by creating our own package API written in Go - this allowed our website to continue operating in the same manner.

The result

So far, most of the migration work has been finished. Our buildserver is already pushing the packages to our SourceForge project, and we use it to host the releases from the main page. Feel free to test this all out and let us know if there are any issues.

All our new releases can now be found at https://sourceforge.net/projects/opengapps/files. They are splitted by the architecture and the release date, somewhat alike to what we had on GitHub. Older releases are mostly already there, we’ll eventually fill in the missing packages.

Thanks again to the SourceForge - guys are doing amazing job, giving home for the massive amount of the opensource projects, and we’re happy to become a part of that community too.

We are also thankful to GitHub for giving us the time and opportunity to move the releases, even though we had exceeded the deadline multiple times, and for still hosting our website and main repositories.

Consider making us a small donation @ PayPal - this will help us with the increased server costs and allow us to continue developing this project.

See you all in the next post!

Hello everyone! My name is Ilya Danilkin aka @nezorflame. You may know me from my work on the unofficial Oreo/Pie OpenGApps builds at XDA and the support group in Telegram.

On the behalf of the OpenGApps team I’d like to explain the recent problems with our website being unable to serve downloads and the takedown of our application repos at Github.

The project structure

To understand the problem, first we should take a look at how the OpenGApps are structured and built. We have multiple repos hosted on Github at https://github.com/opengapps which are being used by the buildserver to automatically produce the builds.

The current structure consists of two parts: script repository and the APK repositories.

Script repository (/opengapps)

This is the main repo with all the scripts needed to compile an OpenGApps flashable package. At the /sources folder we have 5 subrepos which are being pulled before the build, thus downloading the necessary APKs for the preferred architecture (let’s call those subrepos as APK repos). E.g. to build an ARM64 package, we’d need /all, /arm and /arm64 repos as some of the apps don’t have 64-bit version yet.

APK repositories (/all, /arm, /arm64, /x86 and /x86_64)

These are the repositories which are holding all the required APKs. They are being automatically extracted from the Google Pixel factory images every time they get updated.

These repos are huge in size:

• all: 4.99 GB
• arm: 147.47 GB
• arm64: 93.81 GB
• x86: 67.17 GB
• x86_64: 26.61 GB

The problem

Last week (starting February 10th) Github has closed all our APK repos on the account of breaking the ToS. Namely, the paragraph C. Acceptable Use at 4. Services Usage Limits part. Turns out, they weren’t happy with us storing all these big APK files inside of the repositories.

To put it simply:

• it’s OK to have a lot of big files at the Releases section so that you can host stuff;
• but it’s not OK to have big files stored at the repository itself, since Git has poor performance and other issues when the repo gets big.

We are thankful to Github for hosting us for so long, and even though the repositories were big for a long time already, support representatives were still constructively looking into our problem for possible solutions. After the discussion with @mfonville and @nicholasbuse, they’ve agreed to the next conditions:

• we shouldn’t use these repos to store the APKs the way we did anymore;
• we should shrink the size of the repos, including the commit history;
• the fate of the APK repos isn’t solved yet (whether they’ll be removed or not) - discussion is still open about that;
• we still can store the OpenGApps builds in the Releases section of our repos (not in the APK repos though since it’s not yet clear whether they’ll be removed or not);
• the access will be restored for a week to enable us to do maintenance and to solve the problem once and for all.

It was clear that we had to act in order to solve the problem and to restore our infrastructure to continue the builds.

We had multiple options to choose from, including, but not limited to:

• moving to some other public Git hosting, like GitLab or Bitbucket (this may solve the issue for now, but no one can guarantee that a new hoster wouldn’t have a same rule in the future forcing us to move again);
• hosting the Git repos ourselves (saves us from the ToS nonsense, but leaves us with the hosting problem and the increased costs);
• restructuring the whole APK repository system, like extracting all the APKs to their own subrepos (this may still happen in the future, but it requires a lot of work which we currently don’t have the time for).

The solution

For now we’ve decided to pick the second option, as in to self-host our APK repos with GitLab Community Edition.

This gives us three main benefits:

1. It allows to use the same infrastructure for the buildserver, which will only require to redirect the scripts in the /opengapps repo to the new Git remotes, hence saving the time;
2. We can have better control over the content overall;
3. We can still restructure the project later, in a manner that doesn’t overload the git-architecture and stays within the ToS of GitHub or using some filestorage solution to host the releases (e.g. Amazon AWS S3 / DigitalOcean Spaces) to speed up the traffic and ease the server load.

Thanks to the hosting which we’re now using (BTW, big shoutout for Hetzner, they have really good servers with decent pricing and support), we were able us to accomplish this task without any serious issues.

Here’s the current situation:

• APK repos are now hosted at https://gitlab.nezorfla.me/opengapps which is a public repository group with full Read access.
• You can’t register here as of yet (I’ve disabled the registration for now to ease the load on the server, may re-enable it in the future), so the editing of these repos for now is limited to the main project contributors.
• Since the repos are public yet only in Read mode, you can’t make merge requests (since you have to register to submit a MR). So, in case you have a merge request and we deem it important enough to integrate into our APK repos, you can get in contact with me or one of our maintainers so that we could sort it out.
• These repos are here to stay, at least until we decide how the future infrastructure will look like (e.g. would we use the repository-per-APK method or something else).
• Our main /opengapps repo will still be hosted at Github since we’ve confirmed that it’s not a problem to have it there, and we’ll update it very soon to use the new addresses for our APK repos.
• All OpenGApps releases will still be hosted at Github Releases page, at least until @mfonville will be able to upgrade the buildserver and the website to use something else for the filestorage (and we have an actual filestorage to begin with). We know that it’s slow and sometimes problematic, but we ask you to bear with us for now.

Epilogue

So, this concludes the story of how Github decided to close our repositories. I’d like to mention that even though our main project maintainers have a very little time to contribute to it right now, we’re still positive on the future of the OpenGApps. With the help of the public contributors (like @SpasilliumNexus, @osm0sis and many others, including myself), we look forward to the future release of the Android Q, hoping to face it stronger than ever with the improved infrastructure and timely updates to these Google Apps you’re all craving for :) I hope that this was the last serious issue and we won’t face anything like this for a long time. Consider making us a small donation @ PayPal - this will help us with the increased server costs and motivate us even further to continue developing this amazing project.

See you all in the next post!

A new Android release Pie was released in August. Two Open GApps supporters (SpasilliumNexus and nezorflame) quickly got to work creating pull requests (1, 2, 3, and 4) and hosting unoffical builds. But were happy to launch on September 7th our first 9.0 packages.

Beta Quality

Even though we did do as much as we could, the current builds are beta-quality at best. Users can experience some glitches that were not caught yet.

New Applications

Android 9.0 brought us some new applications and keywords. Action Services and Better Together are in the super package.

Webview and Chrome

Another important change, and giving still some headaches, is the new Google Webview behavior. In 7.0 Google Chrome and its variants (Beta, Dev, Canary) gained the ability to replace the standard Google Webview package as Webview provider. Our developers are currently busy figuring out what patches should be applied to ROMs to allow Webview provider selection on feature-parity with Google’s stock ROMs. When sorted out and patches provided to ROM developers this will probably imply some changes the package selection and logic for 9.0. i.e. when Google Chrome is installed it would be unnecessary to install Google Webview too.

Support and Questions

As usual, if you experience any issues with these packages, please report them in our XDA thread and don’t forget to attach debug logs and a logcat!

For any readers visiting this post on or after April 2, check the post date before continuing :)

Today we introduce a new Open GApps variant with groundbreaking technology: the femto package!

After developing in close collaboration with various government agencies and its contractors, we can now share with you a great new technology that makes it more easy to install the latest Open GApps on your device! Instead of downloading the large flashable zip packages, the femto package is a small universal installer, compatible with all devices. It only includes a very minimal installer that activates the ELF (Extremely Low Frequency) antenna in your mobile device (as long as it is not wrapped in tin foil).

Using the ELF antenna it can then automatically download the latest GApps broadcasted by the United States HAARP service into the ionosphere. Downloading can take up to 10 minutes, depending on weather conditions. Take note, the wireless service is currently restricted and only available for those in the northern hemisphere.

We are very excited to test this service now with a greater audience, after a successful beta test by world and tech industry leaders at Davos last January.

The Open GApps Team wishes you happy GApps flashing today!

Hello everybody, I’m Ashish Shekar a.k.a. CodekidX and I’m the new member of the Open GApps App developers team. I’ll be listing all the things that I did for this 1.1 update and also who I am and what inspired me to join the team.

Changes in version 1.1

Version 1.1 of the Open GApps App brings many new changes, listed here below.

Storage Chooser

One of the new feature that you’ll note right off-the-bat (if you were waiting for ExtSD support) is the new Storage & Download Directory Chooser, it’s open source and if you are a developer you can include it in your app here.

I thought of the things that the user would like to see in a storage chooser, like the “Quick Overview” of the available disk space on a storage volume, so that you can decide where to download the Open GApps packages depending on the available space in your volume.

The design of the storage chooser is unlike any other similar library out there. It’s material design, for real. It follows the guidelines and I added some spice to it to look unique. Also you’ll be greeted with a smooth transition of the chooser that is provided by the library.

Day/Night Mode

The feature that has become one of the must have things in any app is a night mode theme. It’s a lot darker and way better looking than the proprietary dark colors and better integrated with all the other aspects of the app. It took some time for us to perfect it, but I think we did!

Keep older packages

From 1.1 onwards the app will support more advanced cleaning up old Open GApps packages for you. All you need to do is set the number of packages in the settings to keep track, it’ll detect and delete old packages which will keep your device neat and clean. While offering you the option to always retain back-ups, if any issue with a new package version might arise.

Winter is coming!

With the 1.1 update you have the opportunity to find the new Easter Egg created by me, I made it a bit challenging so good luck finding it.

Personal Background

I am an Electronics Engineer with a keen interest in Robotics, yeah there’s no relation with coding and development of an app but 3 years ago I needed an app for my own Home Automation System (yes I did beat Google to it) with voice recognition and stuff. I built the whole circuitry and the app from scratch and integrated in my home. Also you can find some of the things that I did as pet project for learning here. If you would be interested in a video or guide on how to do these projects yourself, I would be happy to share it!

Joining the team

The “how” is one of the things that I can’t forget because of how funny it will sound in just about a minute. One fine day I decided to change the ROM of my device and it ended up being soft-bricked for some crazy reason (that I still couldn’t figure out despite of my 6-7 years of flashing experience). So I flashed the whole firmware to get everything working and the thing is I didn’t have GApps on my device which was a pain to get up and start up the PC (lazy to download it again on my laptop), sideload the GApps and then boot the device. So I decided, “Let’s make an app” so that it’ll always stay on my device no matter what. I designed everything, from the UI, UX; then it hit me that I need to ask permission from the Open GApps developer and guess what? The app was already in the process of being made by Christoph a.k.a beatbrot and was in the end stage, well, that was a bummer, but Maarten was kind enough to give a link to a beta version of the app for me to test in our first conversation itself and have look at the app. Since it was the first android app for Christoph I already had some suggestions how we could improve the performance of the app.

Wrap up

This was my first experience with the open-source community and it beats me that I was able to also create a useful library for the community. This made the experience unique and fun. In the near future I’ll help as part of the Open GApps App developers team in any way that I can. Also, if your feature is not included in this version, it might already be in development for our upcoming versions, because we have taken many suggestions into consideration. But all thoughts about new features and possible improvements are very welcome in the comment section below. It will make the app even more awesome!