Open GApps packages are downloaded via the OpenGApps.org website. The user has to select the architecture, the Android-version as well as the variant. Afterwards, the user has to enter recovery and flash the file. Our goal was to simplify these steps even more with our new Open GApps App. While the app still allows to select every possible GApps package, we tried to simplify this process even more, using a wizard.
Using the wizard we can detect the device’s properties and older installations. That enables the app to recommend an appropriate package. It simplifies the process for beginners while still providing all the options to power users.
Another feature of the app that simplifies the life of its users is automatic MD5-Checking as well as automatic flashing via TWRP (if the user chooses to grant root access to the app). With this approach, we can ensure that the zips aren’t corrupt and also help to automate the process of flashing the GApps package. Another thing we did for our power users was including the VersionLog for each package. With the app users can opt in to automatically fetch the VersionLog with their GApps package.
Developing the app was a very challenging but interesting endeavor. I would like to share some background and experiences I encountered during the development.
At the moment I am a student Computer Science. While I already had several programming courses at university, I never had a course for Android Development, neither had I ever programmed an Android app.
I was interested in trying to develop an Android app and first I thought about a Recovery Manager app. I wanted it to have GApps downloading included, so I approached Maarten for permission to automatically download OpenGApps.org packages. He asked me if I’d be interested in developing it as an official Open GApps App. I quickly agreed as I saw this as a huge opportunity. While writing the first few lines of code that I wrote were completely new to me, it also was great fun, as I got into exploring all the details about Android app architecture. Luckily my previous Java experience helped me a lot. Near the final release Ashish joined us and thanks to his experience, we were able to greatly improve some things for this initial release. While 1.0 was mostly my work, he will probably contribute a lot to future versions.
During the development of the app, I had the chance to gather some great experiences that I want to share here
- First and foremost: it was always a pleasure to work with Maarten, Adam and Ashish. All of them were always nice and patient. Especially Maarten always helped me out with good advice.
- It’s a great insight in the internals of Android. While I flashed custom ROMs a lot in the past, I never had the feeling of understanding what’s actually happening
- “Touching” your code gives a great feeling of accomplishment. I was never really impressed by those C terminal applications with plain text, that I wrote. This, however, is a whole different story as you can feel your work
- Having a team that is able to really test the app. When I thought to be close to the 1.0 release, all members on the Open GApps Team tested the app extensively. Many more bugs did pop-up but they were really great in finding out how to reproduce, helping me to find the cause of the bug and fixing it.
The Not So Good
However, also some challenges appear that were hard to tackle for a beginner like me.
- Various side effects appear when the user closes the app, rotates the screen or resizes the app (Thanks to Android N). E.g. all references to the activity suddenly point to null which was especially painful since I implemented a lot of AsyncTasks
- Some libraries look more promising than they are in real world usage. In the beginning, I didn’t look a lot at the libraries I considered to use which leaded to a huge waste of time as I had to redo some things quite often.
- DownloadManager API is a pain to use. It’s lacking callbacks for a finished download, canceled download, etc. And checking the actual status is only possible via a weird implementation with cursors.
- Some Android SDK functions are just not documented at all. E.g. while it was clearly stated that an app needs the reboot-permission to restart the device, it didn’t work out for me first. Only after I’ve seen that a recovery-permission does exist in AOSP, I found that I did have to add it to the app. The documentation doesn’t say a single word about that.
As you saw, I started this project with zero experience in app development. However, thanks to the help of Open GApps Team I learned a lot of stuff and got a lot of experience with android development as well as working in a team. And additionally I was able to contribute to one of my favorite projects out there. I can only recommend everyone doing the same. Find a project you like and ask if you can contribute. It’s a unique experience which you totally wouldn’t get from a regular company via an internship or anything similar.
Android Nougat 7.0 brings a lot of cool new features. One of them is extra flexibility of WebViewProviders.
Besides AOSP WebView and Google WebView, Nougat offers the possibility to use Google Chrome (and its Beta and Dev variants) as WebView provider too. Users have the possibility to select their WebView provider from the Android Settings. This feature is available in stock ROMs, but not yet in custom ROMs without a patch, because AOSP code assumes only AOSP WebView is available.
For ROM developers it is a necessity to include a list of valid WebView Providers in the framework config to expose all possible WebView Providers. On Google’s Nexus devices this list consists of Google Chrome variants and Google WebView. In the upstream AOSP code only AOSP WebView is defined by default.
ROM developers should apply this initial patch and this incremental fix patch to their source tree to add Google WebView and Google Chrome (plus its variants) as valid WebView providers and achieve functional equivalence with stock ROMs.
Users that want optimal WebView experience, please notify your ROM developer of this patch by members of the Open GApps team and ask them to include it in their ROM. In the near future the Open GApps scripts will be adapted to assume the ROM knows about all these valid WebView providers (just like with 5.1 and 6.0 that did work with Google WebView).
30 October 2016 an update for the initial patch has been released, blogpost updated to include it too.
Arrr! Sea dogs an’ land lubbers, th’ Open GApps Team wishes ye a grog-filled talk like a Pirate Day!
To celebrate it in gentleman o’ fortune style we tuned our colors fer ‘tis special tide, we woe ye like it! Success flashin’ yer GAarpphs!
Hearty thanks t’ Yeti fer th’ beautiful artwork.
A brand new Android release Nougat appeared at the end of last month. As Open GApps we quickly got to work and were happy to launch on August 24th our first 7.0 packages, well before any 7.0 AOSP ROMs were available yet.
One challenge is, when there are no AOSP builds in existence, that it is impossible to test the package. So even though we did do as much as we could, the current builds are beta-quality at best. Until we get stable 7.0 ROMs on a device we can test on, users can experience some glitches that were not caught yet.
Android 7.0 brought us some applications and keywords. First of all we got some Google Android Shared Services that are now part of the core package. But we also received the new Google VR Services and the Print Service Recommendation from Google.
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) can 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 7.0. i.e. when Google Chrome is installed it would be unnecessary to install Google Webview too.
APK Signature Scheme v2
Google also decided to introduce a new APK signature scheme with Nougat. If enforced as described in the documents, this could pose serious issues and limitations for installing up-to-date GApps packages on 7.0. It is not clear yet if the strictness from the documentation also applies to all APKs stored on
/system partition. People already report various success with the (smaller) 7.0 GApps packages on XDA, so it might not as bad as feared. But we will later go through the AOSP source code to get a better understanding of these changes.
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!
Good news for those who are still using Android Lollipop and do like Google Calculator!
AOSP app replacements by Google
Google started in recent years to replace various apps that used to be completely in the AOSP project with their own proprietary spins on Nexus and Android One devices. This started with Lollipop (5.X) for Google’s WebView, Google Contacts, Google Dialer, Google Clock and Google’s NFC Tag apps. With Android Marshmallow (6.0) this was also extended to the Google Calculator app.
Google Calculator minimal API level
When the first spins of Google Calculator were released with the Nexus devices of 2015, the APK for Google Calculator were compiled to demand at minimum API level 23, that means Android 6.0. So Open GApps could only offer to install the Google Calculator in the 6.0 packages. Last week Google released an updated version of the APK in preparation for Android Nougat (7.0) and at the same time decided to lower the requirement to API level 21. We don’t know why they lowered the requirement, because in general compiling for a lower API level means that the code has to include more compatibility-hacks. But we tested this new APK on Android (5.X) devices and it works without problems. That is why you can now find Google Calculator also in the (5.0) and (5.1) Open GApps packages (mini and larger).