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).
Because of health issues development on the scripts has been a bit slow recently, sorry for that. Nevertheless it was time to blog, so today a small update and a link to the Pokémon Go APK.
Build system overhaul
I have still have some major architectural overhauls for the Open GApps build system queued, but I need more time to fix some last issues with it. When these changes are done, the build system will be much faster and use less disk space during builds, and prepares the way to multi-architecture/dynamic packages.
Moar and moar APKs
As could be read in our previous blogpost our APKCrawler project got some big updates and we are now crawling more intensively than ever before for new APKs. x86_64 tend to also be much more complete now. Also we updated the playstorecrawler to be able to find updates for the Play Store itself directly, a mechanism that is a bit different than regular APKs.
What is up with TVStock?
We are still busy in the process of preparing a package for Android TV. It is not there yet (and first the build system overhaul has to be done). So no ETA yet.
GPG signed commits
Recently I switched to a new GPG key, because my old one was from 2005 and could not be considered safe anymore because of the low amount of bits. Created a new one now and applied the necessary good practice (masterkey offline, various subkeys for daily use). Still in the process of the switch and propagation of the new key. But I hope to include verified commits into our development workflow soon.
Pokémon Go is the biggest application hit ever, it seems. Even the devs are messing around with it (we can tell you it uses Google’s protobuf)! Unfortunately eligibility is geo-location restricted, but using APKCrawler we could get the APK straight from the Play Store! You can download it here There is only an arm version at the moment, so those who have x86 devices might encounter low performance (or it not working at all). Let’s hope Nintendo releases a multi-architecture version soon!
Notice the Pokemon Go APK has been updated several times already and we will try to keep track of the most recent version
When did you start the APKCrawler project?
First commit was on August 5, 2015, but some prototyping began in July 2015
Why did you start the project?
Between the start of the Open GApps project in March 2015 and August 2015 mfonville had compiled a long list of sites to check for new and updated APK files. When I first saw mfonville’s keyboard (below), I knew something needed to be done to automate the process.
What was the first crawler you have written?
The obvious choice then (and still is now) is APKMirror.com. The have the most complete and accessible list of variants (cpu, dpi, sdk) for all APKs. This is probably due to their crowd sourced upload functionality.
What is the most useful crawler?
The AptoideCrawler. It is the #1 source of APKs that we find and then re-contribute to APKMirror! A close second is the new PlayStoreCrawler that mfonville and therealssj have been working on. There is no more reliable source of APKs than the Google Play Store!
What are the benefits?
mfonville has been using the same keyboard for 6 months now, so that is a huge cost savings for him! Seriously though, any software person knows the benefits of automation. Now we can focus family and friends!
Any challenges or issues?
When a site does not provide a usable API, we rely on the Python module BeautifulSoup to parse the site’s DOM to get the APK’s information as well and download the APK itself. The obvious drawback is when sites go through a redesign. Even with an API in place they break from time to time. One of Aptoide’s official API functions is already broken for months now. That is when I found an undocumented API and rewrote the crawler to be much more efficient. As of today it still kicks ass!
Where do we get more info about this cool thing of yours?
Check out our GitHub repository for the latest development (contributions are welcome!)