The Epic Journey of Five Google Rejections and One Approval

Topic Tag | Product

The Epic Journey of Five Google Rejections and One Approval

Drivemode would like to extend its gratitude to Developer Advocates and colleagues at Google, the journalists who brought transparency to the situation, and our user community who supported us through this battle and helped us keep fighting, even in the face of defeat—over and over and over again.

In late 2018, Google notified developers with apps on the Play Store that “protecting user privacy” would be guiding app approvals and that apps accessing certain device permissions would no longer be allowed to do so. The spirit of the policy change was a good faith effort to protect users from having their private information mined, specifically the content of SMS messages and calling logs. However, Google’s approach to locking down these permissions impacted tens of thousands of app developers and startups who could be effectively shut down by the new permissions requirements.

Drivemode was one such company impacted by these new guidelines, and in early December we were notified by Google that a driving app was not a valid use case to access SMS or calls and that unless we removed these permissions, our app would be taken down from the Play Store.

With little transparency or visibility into the approval process, Drivemode submitted documentation for exceptions six times between December and March, finally receiving an approval late in March. How did we go from five rejections to live on the Play Store? It was a journey of Tolkien-esque determination, facing unseen enemies and indecipherable riddles and now we share it with you.

When this journey began, the only valid uses of SMS or Calling permissions were if an app was the “default handler” or sole app responsible for those features. However, Drivemode only functions as a handler when a user is driving; otherwise, the native messaging or calling app would be default. With so few apps able to meet that criteria, Google offered “temporary exceptions” to developers that would resubmit their apps meeting a handful of new criteria including being a “task manager” or a “connected device companion app.”

We saw a glimmer of hope in this latter exception and charged on with our banner flying as a “connected device companion app,” first by showing how Drivemode works with a variety of connected controllers and eventually elevating the actual car as the device to which we were connected. We submitted videos of the app in use and revised documentation to fit the guidelines. We received three rejections for the same reason, with no more guidance than the following statement:

Frustration set in as the rejections were due to a difference of opinion which put our users’ most important app feature at risk. All of this was compounded a lack of process transparency and the inability to talk with an actual human about this decision. We could only submit a form and await an automated email decision.

In our fourth submission, we knew that our only hope was logical, humanizing persuasion and we suggested that perhaps the available exceptions were not enough, that perhaps there was a use case that the Google machine had not yet considered, and that perhaps we could help them see that we were not, in fact, the enemy of the people.  To these ends, we circulated a presentation to whoever inside Google would listen to us, making our case with usage numbers of our core SMS and calling features, passionate user testimonials, and logic.

The actual title slide of our presentation deck shared with Google

With our fourth submission, we presented our case with the following points:

  • The new SMS and Call Log policy is fundamentally good. It’s intended to protect users from bad actors who would scam, exploit, or otherwise harm Android users.
  • We aren’t out to scam, exploit, or harm anyone. Our app is literally built to save lives by reducing distraction on the road.
  • We’re 15 people. We don’t have the resources to turn our app into something completely different.
  • Our app has been designed to send and reply to SMS messages since we launched in Aug 2015. It has been the fundamental promise from the very beginning.

And finally, we requested that if we would not be granted an exception under the current guidelines then perhaps they would consider a new category.

“Consider that we may be a new use case as a “Safety Aid”. Our app and other driving apps are meant to aid drivers in reducing distraction. We’ve done fundamental research in driver distraction and even hold a patent (US9898079B2) in the area. The new SMS and Call Log policy as written doesn’t account for Safety Aid apps which provide a net good to users.”

To our disbelief and dismay, we were rejected a fourth time and had only a few days before the absolute final deadline of March 9th; this deadline had been extended several times due to the onslaught of developer exception requests.

Our fifth submission was to be the greatest treatise we could summon on the value of Drivemode. It would be accompanied by a mobilized user community, ready to defend us on social media by any means necessary. And defend us they did.


And as we sat down to write this final dissertation, with the full support of our community behind us, we saw a light in the darkness: without any fanfare, some time between our fourth and fifth submission, a new exception was quietly added to the exception guidelines.

It was the definition of Drivemode and how it was used. We had three days left to submit Drivemode for “In-vehicle hands-free use and projected display” as an app “directly related to core functionalities of driving/mobility (e.g., navigation), especially in situations where a user’s physical interactions with a device(s) are limited.”

We thought for sure we had won because this exception was clearly designed with us in mind.  And then we received our fifth rejection just two days before the final deadline.

Happiest rejection ever

But before our team went berserk, cursing the automaton beast that remained savagely blind to our pleas, we saw the actual reason for our rejection. For the first time in the entire process, it seemed that an actual human was responding to us. We received simple direction to remove one very specific permission on which we did not even rely and did so promptly. With just one day left we were able to submit magic version number six and a week later, our updated app readily appeared on the Play Store as if nothing had ever happened. We made it through the Google gauntlet and survived.

Our team dedicated over twelve weeks to this process and received the same 55 words from Google four times; but we are thankful for every person at Google who forwarded our emails, who considered our pleas, and who finally made a decision based on both logic and humanity. We are also grateful to our community of users who cared enough about our product to voice their support to Google however they could.

If there is one request to make of Google, it’s this:

Please open up more routes for developers to have discussions with the actual people working at Google. As developers, we’re not just your biggest fans, but our livelihoods directly depend on your decisions. Sometimes filling out a form and receiving an automated response works. Sometimes, particularly in times of large policy changes with wide-ranging impact, discussions between people are necessary to clarify, understand, and work together on solutions.

We know firsthand how automation and technological intervention can improve our lives, but it is our hope that companies like Google will keep real people involved in these processes, because in some cases, they are more logical than the machines.