App permissions: how we got a removed app back in Google’s Play Store

In November 2019 Google revised and modified its “Google Play Developer Distribution Agreement”. Since then software developers have encountered problems with publishing certain types of Android apps on Google Play. What’s more, Google have removed many apps from the Store without providing any specific explanation of the reason. Thus they make it difficult to understand the true reason and fix the problem. Let us share a story of how Ekreative encountered and dealt with one such challenge.

What happened?

Not long ago, one of our development teams received an email out of the blue from Google support, saying that their app had been removed from Google Play Store. The main reason for the removal was a violation of paragraph 4.8 “Google Play Developer Distribution Agreement”.

Here’s the quote from the original letter:

After review, the App (Version Code 16), has been removed from Google Play because it violates our user data policy and section 4.8 of the Developer Distribution Agreement. This app won’t be available to users until you submit a compliant update.
Your app is uploading users’ contact information to https://apps.applozic.com without a prominent disclosure.

At that moment we had another white-label app of the same client and it was critically important for us to keep its live version in the Store.

Applozic SDK library

Initially, we concluded that the problem was related to the way that we send user information to the servers of Applozic (despite the fact that the apps privacy policy allowed for this). Apploziс is a standalone (with its own server) system that helps developers quickly and easily implement simple chat functionality in an application. Whenever we register a user in the app’s system, we send some information about them to the Applozic server.

First of all, we began to investigate what data we passed on registration and what data the library transmitted. This was the following information:

  1. User’s first and last name
  2. User’s email
  3. Link to user’s photo

Eventually, we decided not to send user email to the Applozic server. We changed the app code and submitted a new version of the App on Google Play, with the hope that this time Google wouldn’t consider it a policy violation. The result was still the same – the updated app was rejected.

Playing with Privacy Policy

After the rejection, we were confused about the root cause of the problem. We were quite confident that we do not distribute any personal information of the user without their consent. And the worst thing was that Google didn’t provide any additional information about rejection reasons. All letters we received from the support team were identical (violation of paragraph 4.8 “Developer Distribution Agreement – Google Play”).

At this point, we decided to run an investigation and try to finally solve the problem. The first thing we did was add a simple link to the privacy policy on the login screen (the app’s users sign up and agree to the privacy policy live, in person, so there was no sign up screen, only a login screen). Once done, we attempted to submit the app once again but it was still rejected.

consent box placement

All further steps were similar. We tried to add a lot of links, consent checkboxes, and explanatory text inside the application. We suspected that in some way Google felt we weren’t meeting their consent requirements. We also sent numerous letters to Google support describing in detail what data we use within the app. But it was all in vain. Every time we submitted, we received another copy of the standard letter from Google without any explanation of the real rejection reasons.

At one point, our login screen began to look clumsy due to all the extra additions we’d made.

bad example

Good Bye, Applozic

After many unsuccessful attempts to return the app to the Store, we realized that it was high time to look for more drastic solutions to the problem. And one way to do this was to completely remove the Applozic SDK from the application. So that’s what we did.

Needless to say, the functionality that this library ensures is critically important for us. Therefore, its removal was not a solution to the problem, but rather an attempt to find out the actual reason for the removal of the app from Google Play Store. This experiment turned out to be successful for us. The app was returned to the store and was downloadable again. A small victory!

Welcome back, Applozic

Removing the library made us aware that the true reason was within Applozic itself. But, as we said earlier, it’s functionality was significant for us. We restored the library to analyse app dependencies and tried to publish a new version of the app. The result was quite unexpected.

library permissions

After uploading the new build in Google Play Console, we received a warning about a couple of new dangerous permissions (location, call phone, read contacts, record audio, and others), added in this version. It became clear that these permissions were added directly by the “Applozic” library since this was the only difference compared with the previous build. As it turned out, Applozic applies those permissions for functionality that we don’t use, but despite this, dangerous permissions remained in the final manifest of the Android application. At that moment, we realized that we had found the real reason for the application takedown.

Solving the problem

Since we didn’t use functionality that required those permissions, we could simply remove them from the final manifest. To do this, you just need to add a few lines to the manifest of the application:

permission denied

After that, you need to thoroughly test the application for crashes, just in case. In our case, the application worked correctly, so we released a new version.

Today, both apps are live in the Google Play Store. Victory!

Findings

Throughout this article, we tested several possible reasons why an app might be removed from the Google Play. As you can now see, it is important to check third-party libraries that you use for any hidden permissions that can eventually get into the final manifest and cause trouble. But while the problem turned out to be simple, the key reason for the delay in finding the solution was that Google would never explain the real reason for blocking applications. If Google’s initial email explained the permissions issue, we could have resolved it that same day.