Overcoming Google Play Review Challenges in the Face of Sanctions
July 7, 2024, 9:34 am
Google
Location: United States, New York
Hello everyone! My name is Anton, and I am a lead developer in one of the mobile development teams at DD Planet. In this article, I will share my personal experience and our team's experience in passing reviews in the Google Play app store using a real business case.
The consequences of sanctions in modern mobile development in Russia
Modern mobile app development in Russia has faced a number of restrictions and blockages from major app stores such as Google Play and Apple Store. After the imposition of anti-Russian sanctions, apps from many Russian companies were removed from these stores. Among the removed apps were, for example:
- apps from sanctioned Russian banks such as "Sber", "Tinkoff", "Alfa-Bank", and others;
- apps from airlines like "Aeroflot", "Utair", "S7";
- other services like "Russian Railways Passengers", "SberMarket", "CityDrive".
The list of removed apps is constantly growing. In this regard, companies are paying attention to alternative app stores, such as the well-known Huawei App Gallery or the emerging RuStore, but their market share is still small. People still find it more convenient and familiar to use apps from giant stores, and this trend is unlikely to change soon.
We have been publishing apps in Google Play for many years, but only recently we encountered a new Google policy and the threat of forced removal of our client app from the store despite fully addressing identified violations. Fighting with Google and new requirements for app updates. Cases where updates may not be approved. Our case.
Over the past few years, Google has periodically tightened requirements for app updates. In addition to the requirement for regular upgrading of the target Android API version, there is now the requirement to fill out a Data Safety form. Here, developers must provide detailed descriptions of the data they request from users, store in the app, transmit to third-party services, and for what purpose.
For each type of data, such as:
- authentication data,
- photos/videos,
- contacts,
- geolocation,
- payment data, etc.,
a detailed description is required. There are also stricter requirements for app permissions. For example, if an app requests access to confidential information or permissions with a high level of risk (such as access to SMS or call logs), you will need to fill out a "Permissions Declaration" form and get approval from Google Play.
Usually, when a new requirement is added to Google Play Console on the app page, there is a banner warning about the need for changes. Otherwise, the app will be blocked or its next update will be rejected during review.
Let's consider an example with geolocation data
Imagine your app requests user coordinates, and you did not mention this fact in the data safety form. If Google detects a discrepancy, the update will not be approved, and you will see a warning banner.
In one of our large apps with tens of thousands of active users, an outdated but working version of the Yandex Metrica AppMetrica SDK library was used for a long time. At the time of review difficulties, the app had been in the store for five years. It had survived hundreds of releases, and the presence of this library version had never before raised any questions from Google.
However, during a recent release, we found that the update was rejected. According to Google, our app was aggressively collecting user geolocation data in the background without notifying them or asking for permission. We investigated and found that in the old versions of Yandex Metrica, geolocation tracking was indeed enabled by default. Starting with the native version 5.0.0 of the library, it was disabled by default by the developers.
But since our app was not native but written on the Xamarin cross-platform framework, we used the latest official version of the wrapper over Metrica - 2.3.0. However, even in this version, we quickly found a way to explicitly disable geolocation tracking in the code and rebuilt the app, confident of our imminent victory.
But it was not to be. After some time, Google rejected it again, citing that we were collecting user geolocation data. Google's email explicitly mentioned Yandex Metrica, suggesting we remove it from the app or update it to version 5.0.0.
Updating the Metrica library for Xamarin became a separate technical task to create a wrapper over the corresponding native library. After completing this task, we integrated the library into the app and ensured its functionality. We then built and submitted a new build for review.
And once again, we received the same rejection email, asking us to update or remove Yandex Metrica. But the app already had the updated version.
Experience with Google Play Support. Is there a chance of success in appealing?
At this point, we stopped understanding what Google wanted from us and decided to contact Google Play support for clarification. There are two ways to do this:
- online chat with an operator,
- email support.
As practice showed, the online chat was unstable, often with no available operators. Moreover, we had previously had an unsuccessful experience with an operator on another issue - we couldn't resolve the issue in the chat. The specialist answered all our questions and arguments with the same template phrases.
So this time, we decided to appeal directly via email. We wrote a detailed email, stating that we had updated Yandex Metrica to the required version 5.0.0 and asked for clarification on any other changes we needed to make to comply with Google's policy.
We quickly received a response. It was almost identical to the previous emails. It again suggested updating the Yandex Metrica SDK or removing it altogether.
We decided to test the hypothesis: perhaps Google really didn't like the SDK itself. We completely removed Yandex Metrica from the app and all mentions of it. We rebuilt the app and waited for review. After some time, we predictably received the same email about the presence of the SDK, which was not the case.
At this point, we filed a new appeal. In the email, we explained in detail that with this update, Yandex Metrica was completely removed from the app. Thus, our app did not collect user geolocation data in any way.
And again, we received an email with the same text. At this stage, we realized that we would not achieve anything with just appeals and started digging deeper.
Reasons for build rejection. How Google Play analyzes the .AAB file and what it may not like.
We had a new hypothesis: perhaps we were not completely removing Yandex Metrica, and some parts/metadata left in the build were pointing Google to its presence. Google Play automatically analyzes the build file, finds these instructions, and rejects the build.
In the case of updating Yandex Metrica SDK to version 5.0.0, perhaps some remaining metadata indicated the old version. Or Google was not satisfied with the wrapper over the native library for Xamarin.
To try to find such metadata, we decided to delve into the build's internals. We used the publicly available apktool utility for decompiling the .APK file.
After decompiling the file, we found a folder with the build's internals. Among other things, there was an assemblies.manifest file containing information about the libraries used in the app. In the build with Yandex Metrica, we found the corresponding metadata, but it was absent in the build without it.
From all the above, we could draw the following conclusions:
- the build with removed Yandex Metrica did not contain any traces of it;
- the build with the Metrica wrapper for Xamarin contained all the necessary files and configuration settings for its operation.
The threat of app removal. An unexpected step: voluntarily removing the app from publication. The final decision.
Meanwhile, while we were experimenting, the threat of our app being removed from Google Play loomed. A banner appeared on the app page in Google Play Console, warning us to make corrections within 14 calendar days, or the app would be removed from the store. It turned out that Google Play not only did not like our update in any form (with Metrica version 5.0.0 or without it), but also did not like our Production version of the app due to the presence of the outdated Metrica version 2.3.0. From that day on, the Production version was also flagged as a violator of Google's policy and subject to removal. To save the situation, we needed an update, which Google was not approving for the same reason. A vicious circle.
It is worth noting that throughout this story, we actively alternated technical research and communication with Google support, which ultimately led to success.
Once again, faced with a technical dead-end, we could not think of anything better than to submit another appeal. Fortunately, we could appeal each rejected update an unlimited number of times. In our email, we once again described the work done, clearly pointed out Google's policy that our app now complies with, and asked a series of additional questions. We asked Google to confirm whether our app had ended up on some "blacklists" that triggered automatic rejection of our new builds without reviewing their content.
After some time, we received a response that was slightly different from the standard previous emails. It still mentioned a violation of the Location Permissions policy due to the presence of Yandex Metrica SDK in the app.
But this time, the focus was on the Production version of the app, which we were trying to update:
"Before resubmitting your app for further review, please make sure to deactivate the non-compliant App Bundle Version: 649, Track: Production and increment the version code of app bundle in the Production / Open test / Closed test / Internal test track".
The email suggested deactivating the non-compliant Production version of the app and uploading the compatible update to all tracks in Google Play:
- open testing (alpha),
- closed testing (beta),
- internal testing.
But based on our many years of app publishing experience, we knew that in Google Play terminology, deactivating a build occurs after the update passes review. After approval, the new build replaces the old one and becomes available to users. The old build is then deactivated. Here, Google was asking us to deactivate the build before review, which seemed strange to us.
After researching, we found in the documentation the option to voluntarily remove the app from publication:
- We will remove the app from publication ourselves, thereby deactivating its Production version.
- The app will no longer be available to users.
- We will upload the update (build without Yandex Metrica SDK) to all Google Play tracks for review.
- Once the build passes review, we will republish the app in the store.
At this point, it is important to note that initially, this decision did not have the support of the business. What happened was that after weeks of fighting to keep the app from disappearing from the largest store, we suddenly gave up and voluntarily removed it. And we even positioned this approach as the final solution to the problem!
The business asked for guarantees that our solution would work. What happened was that for several weeks, we fought to keep the app from disappearing from the largest store, and then suddenly we gave up and voluntarily removed it. And we even positioned this approach as the final solution to the problem!
The business asked for guarantees that our solution would work. What happened was that for several weeks, we fought to keep the app from disappearing from the largest store, and then suddenly we gave up and voluntarily removed it. And we even positioned this approach as the final solution to the problem!
We explained that during the removal from publication and the review of the new build, the app would continue to work for those users who already had it installed. And in the end, we got the green light.
The app was removed from publication, and during the review of the new build, it was no longer available to new users. At some point, managers from the business side began to sound the alarm, but the entire review process took no more than a day. The review was successfully passed, and we republished the build without Yandex Metrica in Production. Later, we submitted a new build with the required Metrica version 5.0.0, and it also passed review within a day.
Nearly a month of our struggle with Google ended in success!
Conclusions and recommendations for passing reviews in Google Play:
- It is essential to track changes in app update requirements and active Production builds. Pay attention to informational messages in the form of banners that appear in Google Play Console.
- If a build is rejected during review or warning banners appear, immediately contact support. Typically, Google gives developers from a few weeks to a few months to address such issues.
- Be prepared to write to support frequently and repeatedly, filing appeals, possibly repeating yourself. Different employees may respond on the other end, and their answers to the same questions may differ or contain additional information.
The consequences of sanctions in modern mobile development in Russia
Modern mobile app development in Russia has faced a number of restrictions and blockages from major app stores such as Google Play and Apple Store. After the imposition of anti-Russian sanctions, apps from many Russian companies were removed from these stores. Among the removed apps were, for example:
- apps from sanctioned Russian banks such as "Sber", "Tinkoff", "Alfa-Bank", and others;
- apps from airlines like "Aeroflot", "Utair", "S7";
- other services like "Russian Railways Passengers", "SberMarket", "CityDrive".
The list of removed apps is constantly growing. In this regard, companies are paying attention to alternative app stores, such as the well-known Huawei App Gallery or the emerging RuStore, but their market share is still small. People still find it more convenient and familiar to use apps from giant stores, and this trend is unlikely to change soon.
We have been publishing apps in Google Play for many years, but only recently we encountered a new Google policy and the threat of forced removal of our client app from the store despite fully addressing identified violations. Fighting with Google and new requirements for app updates. Cases where updates may not be approved. Our case.
Over the past few years, Google has periodically tightened requirements for app updates. In addition to the requirement for regular upgrading of the target Android API version, there is now the requirement to fill out a Data Safety form. Here, developers must provide detailed descriptions of the data they request from users, store in the app, transmit to third-party services, and for what purpose.
For each type of data, such as:
- authentication data,
- photos/videos,
- contacts,
- geolocation,
- payment data, etc.,
a detailed description is required. There are also stricter requirements for app permissions. For example, if an app requests access to confidential information or permissions with a high level of risk (such as access to SMS or call logs), you will need to fill out a "Permissions Declaration" form and get approval from Google Play.
Usually, when a new requirement is added to Google Play Console on the app page, there is a banner warning about the need for changes. Otherwise, the app will be blocked or its next update will be rejected during review.
Let's consider an example with geolocation data
Imagine your app requests user coordinates, and you did not mention this fact in the data safety form. If Google detects a discrepancy, the update will not be approved, and you will see a warning banner.
In one of our large apps with tens of thousands of active users, an outdated but working version of the Yandex Metrica AppMetrica SDK library was used for a long time. At the time of review difficulties, the app had been in the store for five years. It had survived hundreds of releases, and the presence of this library version had never before raised any questions from Google.
However, during a recent release, we found that the update was rejected. According to Google, our app was aggressively collecting user geolocation data in the background without notifying them or asking for permission. We investigated and found that in the old versions of Yandex Metrica, geolocation tracking was indeed enabled by default. Starting with the native version 5.0.0 of the library, it was disabled by default by the developers.
But since our app was not native but written on the Xamarin cross-platform framework, we used the latest official version of the wrapper over Metrica - 2.3.0. However, even in this version, we quickly found a way to explicitly disable geolocation tracking in the code and rebuilt the app, confident of our imminent victory.
But it was not to be. After some time, Google rejected it again, citing that we were collecting user geolocation data. Google's email explicitly mentioned Yandex Metrica, suggesting we remove it from the app or update it to version 5.0.0.
Updating the Metrica library for Xamarin became a separate technical task to create a wrapper over the corresponding native library. After completing this task, we integrated the library into the app and ensured its functionality. We then built and submitted a new build for review.
And once again, we received the same rejection email, asking us to update or remove Yandex Metrica. But the app already had the updated version.
Experience with Google Play Support. Is there a chance of success in appealing?
At this point, we stopped understanding what Google wanted from us and decided to contact Google Play support for clarification. There are two ways to do this:
- online chat with an operator,
- email support.
As practice showed, the online chat was unstable, often with no available operators. Moreover, we had previously had an unsuccessful experience with an operator on another issue - we couldn't resolve the issue in the chat. The specialist answered all our questions and arguments with the same template phrases.
So this time, we decided to appeal directly via email. We wrote a detailed email, stating that we had updated Yandex Metrica to the required version 5.0.0 and asked for clarification on any other changes we needed to make to comply with Google's policy.
We quickly received a response. It was almost identical to the previous emails. It again suggested updating the Yandex Metrica SDK or removing it altogether.
We decided to test the hypothesis: perhaps Google really didn't like the SDK itself. We completely removed Yandex Metrica from the app and all mentions of it. We rebuilt the app and waited for review. After some time, we predictably received the same email about the presence of the SDK, which was not the case.
At this point, we filed a new appeal. In the email, we explained in detail that with this update, Yandex Metrica was completely removed from the app. Thus, our app did not collect user geolocation data in any way.
And again, we received an email with the same text. At this stage, we realized that we would not achieve anything with just appeals and started digging deeper.
Reasons for build rejection. How Google Play analyzes the .AAB file and what it may not like.
We had a new hypothesis: perhaps we were not completely removing Yandex Metrica, and some parts/metadata left in the build were pointing Google to its presence. Google Play automatically analyzes the build file, finds these instructions, and rejects the build.
In the case of updating Yandex Metrica SDK to version 5.0.0, perhaps some remaining metadata indicated the old version. Or Google was not satisfied with the wrapper over the native library for Xamarin.
To try to find such metadata, we decided to delve into the build's internals. We used the publicly available apktool utility for decompiling the .APK file.
After decompiling the file, we found a folder with the build's internals. Among other things, there was an assemblies.manifest file containing information about the libraries used in the app. In the build with Yandex Metrica, we found the corresponding metadata, but it was absent in the build without it.
From all the above, we could draw the following conclusions:
- the build with removed Yandex Metrica did not contain any traces of it;
- the build with the Metrica wrapper for Xamarin contained all the necessary files and configuration settings for its operation.
The threat of app removal. An unexpected step: voluntarily removing the app from publication. The final decision.
Meanwhile, while we were experimenting, the threat of our app being removed from Google Play loomed. A banner appeared on the app page in Google Play Console, warning us to make corrections within 14 calendar days, or the app would be removed from the store. It turned out that Google Play not only did not like our update in any form (with Metrica version 5.0.0 or without it), but also did not like our Production version of the app due to the presence of the outdated Metrica version 2.3.0. From that day on, the Production version was also flagged as a violator of Google's policy and subject to removal. To save the situation, we needed an update, which Google was not approving for the same reason. A vicious circle.
It is worth noting that throughout this story, we actively alternated technical research and communication with Google support, which ultimately led to success.
Once again, faced with a technical dead-end, we could not think of anything better than to submit another appeal. Fortunately, we could appeal each rejected update an unlimited number of times. In our email, we once again described the work done, clearly pointed out Google's policy that our app now complies with, and asked a series of additional questions. We asked Google to confirm whether our app had ended up on some "blacklists" that triggered automatic rejection of our new builds without reviewing their content.
After some time, we received a response that was slightly different from the standard previous emails. It still mentioned a violation of the Location Permissions policy due to the presence of Yandex Metrica SDK in the app.
But this time, the focus was on the Production version of the app, which we were trying to update:
"Before resubmitting your app for further review, please make sure to deactivate the non-compliant App Bundle Version: 649, Track: Production and increment the version code of app bundle in the Production / Open test / Closed test / Internal test track".
The email suggested deactivating the non-compliant Production version of the app and uploading the compatible update to all tracks in Google Play:
- open testing (alpha),
- closed testing (beta),
- internal testing.
But based on our many years of app publishing experience, we knew that in Google Play terminology, deactivating a build occurs after the update passes review. After approval, the new build replaces the old one and becomes available to users. The old build is then deactivated. Here, Google was asking us to deactivate the build before review, which seemed strange to us.
After researching, we found in the documentation the option to voluntarily remove the app from publication:
- We will remove the app from publication ourselves, thereby deactivating its Production version.
- The app will no longer be available to users.
- We will upload the update (build without Yandex Metrica SDK) to all Google Play tracks for review.
- Once the build passes review, we will republish the app in the store.
At this point, it is important to note that initially, this decision did not have the support of the business. What happened was that after weeks of fighting to keep the app from disappearing from the largest store, we suddenly gave up and voluntarily removed it. And we even positioned this approach as the final solution to the problem!
The business asked for guarantees that our solution would work. What happened was that for several weeks, we fought to keep the app from disappearing from the largest store, and then suddenly we gave up and voluntarily removed it. And we even positioned this approach as the final solution to the problem!
The business asked for guarantees that our solution would work. What happened was that for several weeks, we fought to keep the app from disappearing from the largest store, and then suddenly we gave up and voluntarily removed it. And we even positioned this approach as the final solution to the problem!
We explained that during the removal from publication and the review of the new build, the app would continue to work for those users who already had it installed. And in the end, we got the green light.
The app was removed from publication, and during the review of the new build, it was no longer available to new users. At some point, managers from the business side began to sound the alarm, but the entire review process took no more than a day. The review was successfully passed, and we republished the build without Yandex Metrica in Production. Later, we submitted a new build with the required Metrica version 5.0.0, and it also passed review within a day.
Nearly a month of our struggle with Google ended in success!
Conclusions and recommendations for passing reviews in Google Play:
- It is essential to track changes in app update requirements and active Production builds. Pay attention to informational messages in the form of banners that appear in Google Play Console.
- If a build is rejected during review or warning banners appear, immediately contact support. Typically, Google gives developers from a few weeks to a few months to address such issues.
- Be prepared to write to support frequently and repeatedly, filing appeals, possibly repeating yourself. Different employees may respond on the other end, and their answers to the same questions may differ or contain additional information.