Decoding Play Policy AMA

All right.

Thanks, everybody, for joining us for this panel on decoding Google Play policy.

I'm Jan Kleinert, developer relations engineer on the Android for Cars team.

And I'll be the moderator for the panel today.

I'm going to turn it over to our panelists, Bohdan and Paul, to introduce themselves.

And Bohdan, let's start with you.

Hi, folks.

I'm Bohdan, and I work in Google Play trust and safety.

I've been here for over four years and in the tech trust and safety industry for over a decade.

I like seeing how tech, and industry, and culture interact, and how events encourage new apps to be developed, and I like events like these where we can do our best to help set developers like yourselves up for success.

Hello, everyone.

My name is Paul.

I work in the same team as Bohdan, and I've been in trust and safety for roughly the same period as Bohdan, a decade now, and majority of it is with Google Play T&S.

So, I'm very happy to be on stage here today, and let's get going.

All right, thanks.

So, to set the stage before we kick off the panel, I'm going to hand it back over to Paul.

He's going to start with a brief overview of policy resources, info on best practices and things like that to help prepare your app for a smoother, more efficient policy review.

Yeah.

So, what do we even mean by Play policy?

These are the foundational rules that developers must adhere to when publishing and maintaining mobile applications on the Google Play Store.

We provided some short links on the screen for Play policy resources.

The first link takes you to the developer policy center.

If you click Recent updates at the top of the page, you can read the detail about new policies, as well as updates or clarifications to existing policies.

If you're a more visual or audio learner, the second short link will take you to a playlist of our Policy Bytes.

It's videos where we talk through the policy updates.

And finally, the third link will take you to a page where you can learn more about the Play policy insights in Android Studio, a feature that's intended to provide helpful pre-review guidance delivered as lint checks in Android Studio.

All right.

And there's also an Android skill to help audit Android apps against these Google Play policies to help you verify compliance across permissions, account deletion, and data safety.

And you can install this skill using the Android CLI just like any of the other skills.

android skills list
android skills add play-policy-insights

And then finally, before getting started with some of Jan's panel questions, we wanted to share some best practices for working with Play policy and app reviews.

The first one, provide login credentials for reviewers.

It seems like a simple one, but a very common reason for delay or rejections is inaccessible content.

If your app requires a login, or has gated content, or has credits, or subscriptions, then you need to provide test credentials.

For some apps, it means providing login credential-- tials just at the very start of the app, and then for others, you might have different sections, like the paid content that I had mentioned.

You can do that in Play Console, the provide these login credentials for our our reviewers.

It used to be called App access, but now it's called Sign-in details, and that's in the App content section.

And then you want to make sure that the credentials bypass any kind of do-- two-factor authentication, captchas, paywalls, etc.

Yeah, deactivate old version codes.

So, developers often experience what we call, colloquially, rejection loops, because they upload a clean, compliant production build, but they often forget that an older, non-compliant version is still active on the Play Console on another track, whether that be open testing, closed testing, etc. So, even if it's an app bundle is in an old testing track, it is subject to Play policy review, Play policy.

So, if it requests restricted permissions or uses outdated vulnerable SDKs, it's still going to be subject to review.

So, make sure you ensure that you replace or deactivate all obsolete version codes across all tracks before you hit that submit button.

Third, allow ample time for reviews, and use managed publishing.

So, app reviews and publications can take seven days, or sometimes more, to go live, especially if it's a new app or an app requesting a sensitive permission.

And so, you want to give enough lead time.

Provide Make sure that if you have a major launch, you're submitting that new app at least a couple of weeks before the actual launch date.

And then you can link that with managed publishing.

Managed publishing is a feature that allows approved updates to be held until you are ready to release them, preventing unexpected delays during marketing campaigns or other sensitive launches.

And then as you're doing that, you want to make sure that you avoid resubmitting the app once it's already been submitted for review.

Because if you do that, the clock starts over.

I think developers sometimes forget about that, and they have an app halfway through, and they forget, "Oh, I got to make this little change."

They resubmit it, and then it goes back to the start of the review process.

Right, check your declarations.

So, your app content declarations such as data safety section, privacy policy, or photo/video video permissions, for example, must match the app manifest of active bundles or version codes across all tracks.

So, for example, if your app manifest requests for access fine location, but your permen-- permission declaration form does not disclose its purpose, the app may, or and very much will be enforced.

So, make sure you ensure third-party SDKs aren't exfiltrating data that you haven't declared.

Even if your app doesn't use a specific piece of data, if you choose to integrate an SDK that does, it could tee-- lead to an enforcement.

So, check the Play S-- so, check the Google Play SDK Index to see insights about over 100 of the most widely-used commercial SDKs.

I'd like to interrupt with a quick question here before we move on.

So, when you say enforcements, what do you mean by that specifically?

What does that term mean?

Enforcements it could be any adverse action, so they could range from warnings to rejections, to even more egregious enforcements such as removals, suspensions, or even account bans.

So, when I say enforcements, these are the adverse actions I'm referring to.

Cool.

Thank you.

Yeah.

And then finally, use appeals.

Don't just resubmit the same version after a rejection.

Also, repetitive rejections for the same issue in a short period of time could trigger an algorithmic flag that leads to the more severe enforcements that Paul mentioned, like removals or suspensions.

And so, if an app is rejected, don't just resubmit, you know, kind of right off the bat without making changes, guessing, or addressing the feedback.

You'll get communications both in the console inbox and the associated emails that you provided for the exact violation and guidance.

And then if you disagree, or maybe don't understand, but let's say you disagree with a rejection, appeal, right?

If you think that it was a false positive, then you can use the link provided in the comms to appeal.

And that's kind of a better first step than just rushing to resubmit without making any changes.

And the same goes for the for if you get the comms and they don't quite make sense to you, maybe it's very wordy, maybe it's too many paragraphs, whatever whatever it is, it's perfectly fine to go back to appeals.

And when you do that, you will be emailing with a real person.

And while there may be some limits with what they can communicate, you can often get additional details about the cause of the rejection.

Other times, appeals understands that, like, the appeal team understands that the comms can be quite lengthy.

And so, what they'll do is they can highlight or bold the sections that are specifically applicable to you and to your app.

So, yeah.

With that, I'll turn it back over to Jan.

All right.

Thank you.

So, we've collected questions from developers across a bunch of different channels and sources.

So, these questions here that we have today kind of represent some of the issues that we hear often from developers when it comes to policy.

So, let's start with this.

What are some of the common reasons that an app might be rejected related to permissions?

And how can developers avoid those rejections that are related to, like, permission policy violations?

All right.

Permissions, I'll take that one.

So, yeah, permissions, namely the sensitive permissions, must be core to the critical critical purpose of the advertised purpose of your app.

So, if you have like an ancillary feature or some some feature that's not even in the app that's not even advertised, it's very likely that the app will be rejected.

So, ensure that the declaration matches what the use case of the app is.

Additionally, many times an app is rejected because the video links that you provide in the declarations are just inaccessible.

Our review team needs to be able to, you know, access the app, video links that you provide, anything within the app to, you know, fully review the app in full.

So, just make sure everything's acc- accessible within the app, the manifest, and within the declaration.

So, ensure that those three items are done, and very likely well, I don't want to say very likely, but it's going to be a smoother process.

Cool.

All right.

So, more app developers are starting to use third-party platforms for AI-generated content within their apps, right?

If those platforms produce content that's either inappropriate, or factually incorrect, or something like that, can it lead to a rejection of the developer's app, and who's really responsible in cases like that?

Yeah.

Yeah, that can lead to a rejection.

Ever since the start of the Play Store, the position has always been, you know, whatever a developer has in the app, or whatever a user can access in the app, is the responsibility of the developer.

And so even though GenAI is a new area, that's the same holds for that.

I think kind of a good parallel to generative AI is user-generated content, because for both of those policies you have to have a lot of the same sorts of a, you know, you have to have, flagging, you know, if something appears that is not quite appropriate.

There has to be a filtering mechanism.

I think that there's I mean, there's other policies of course, that that would apply, but the way I like to look at it is if if you have GenAI content, you've got Google that's reviewing the app, you've got users that are clicking flag if they see see something inappropriate, and then you've got your filtering mechanisms.

So you really have Google and the developer, yourselves, and the users that all kind of work together to help keep the app as safe as possible for everybody.

Okay.

Great.

But generally, do we recommend that, you know, in addition to having mechanisms for users to flag content, should developers be putting some sort Is that what you mean by the filtering mechanism?

To like stop certain types of content from being displayed to users in the first place?

Correct.

Yeah.

So, like during the review process, our teams aren't going to go in and like try to like dig through your code or re- reverse engineer what is your exact filtering mechanism.

They're just going to look to see, hey, can we access anything that's inappropriate?

And if they can, then then we would send some coms back, and then it would be your team's job to kind of figure out how they can make that filtering mechanism more robust.

Got it.

Cool, thank you.

So one policy that exists is called like impersonation, or copycat policy, right?

So if an app is rejected under that impersonation policy, but they believe that to be an error, for whatever reason, what should they do?

And how can they proactively avoid that type of rejection?

Appeal.

Yeah, that was one of the I think that was the fifth best practice that we have up on the board is if you get rejected for that, you should appeal.

And then what you should do is, well, the most common scenarios are going to be that the brand that you're impersonating is maybe it's your own brand, right?

Or, you're making an app on behalf of someone else, and that I would say is probably the most common, where you have blank label developers that are making apps for maybe their fitness facilities, SaaS, you know, some kind of a SaaS solution.

And so, but it's easier to publish those under your own developer account, right?

And so you can file an appeal, and what our team is going to look for is what's called a proof of permission.

And so let's say you have a client called Joe's Chicken, and they have the best chicken, you know, west of the Mississippi.

They're going to give you a proof of permission letter that says, you know, on a company letterhead, official company letterhead with their logo that says, we, Joe's Chicken, are giving permission to ABC Developer to have our imagery and our likeness in their app, and it's best if they put the name of their app, the app package name.

You know, maybe it's com.joeschicken.app or something, and then what you can do is respond to the developer, and give that that documentation.

Okay.

And then, I think the second part was--

Just like is there anything proactively that they could do to avoid that?

So, for example, like can you upload that, I forgot what it was called, proof of something, you know, at the time that you're doing your first submission?

Yes.

Right.

On Play Console, there is what we call the advance notice form that you can can submit, upload you know, these forms of documentation that that associate your account with the other entity.

So, by doing so, you can preemptively protect your app submission from these sort of enforcement adverse actions.

Yep.

Cool.

All right.

So, you mentioned a little bit about using third-party SDKs earlier in the best practices section, but I'd like to get into that a little bit more.

So, when apps use third-party SDKs, it sounds like it's true that app developers are responsible for how those third-party SDKs use things like user data.

So how are developers supposed to know that SDKs are compliant with data safety and user data policies?

Like, how can they navigate that landscape?

Yeah, that's a great question.

I did a lot of work with SDKs with within Google my first 2 years here, and it does kind of go back to that previous question, where we were talking about generative AI and user-generated content, just in the sense that whatever is in your app, you know, is ultimately the responsibility of the developer.

I think Paul mentioned quickly, briefly in the intro that we have something called the Google Play SDK Index, and you can just go on Google, type that in.

It should be the first or second result, Google Play SDK Index, and what you'll get is a webpage that has more than a hundred, maybe several hundred SDKs divided by is it an SDK for monetization, or for ads, or is it for health, or something different?

And that page just pulls publicly available data.

It's something that Google organizes.

But what you'll notice is as you're going down these SDKs, on the side of it, some of them will have a badge that says something like registered in SDK console.

So just like you as developers have a Play developer console for your apps, SDK developers have the option of getting access to an SDK developer console.

And they have to go through a similar review process.

They send us their SDK.

Google goes through a couple of different checks, but if it checks out and it's compliant, they get that badge.

Now what that means for you as developers, is you can go into that index and kind of see which SDKs have passed that process.

Now it's not a guarantee that the app is going to be approved or that the SDK is never going to be non-compliant, but I would say it gives maybe kind of two points of confidence.

The first is that there is a much higher probability that the app is not going to be rejected if you're using that SDK.

Just a probability.

The second one, and this is something that I really like about that whole process, is if we end up finding that the SDK does have something that's not compliant in it, we'll take kind of like a two-prong approach.

The first prong is that we'll go to the SDK developer and we'll say, "Hey, we noticed that your SDK is sending user data in some non-compliant fashion."

And so then they'll work to bring their app or their SDK into compliance.

And then at about the same time, or maybe a little bit after, kind of the second prong is our teams will send notifications or warnings to the developers.

And the notification will say something like, "Hey, we noticed that your app is sending that data in a non-compliant fashion and we noticed that it's happening in ABC SDK."

And so, kind of the steps you can take as a developer is to just update the SDK to whatever compliant version they've provided.

If if you want to go more nuclear, you can remove the SDK, or replace it, but I know that that takes a ton of effort and work.

But that's what I like about the Google Play SDK Index.

Yeah.

It doesn't say in the index like which exact policies that it is or is not compliant for, but you do get that badge and that's kind of like I would call it a vote of confidence.

Okay.

Yeah.

Okay, sounds good.

And it sounds like if I inferred from what you said, that if, you know, if we send out messaging to developers saying, you know, "You're using this SDK and it has an issue."

Do we tell them kind of like if they're going to update, do we tell them what version If the developer fixes it, do we tell them like, "Hey, a better version is such and such"?

Or do they just kind of have to do a little bit of that research on their own?

I think it actually does have the version code on there.

Yeah, don't hold me on that, but I do believe it has the version code listed on there that that they can update to.

Yeah, and as for full transparency like I'm not a developer myself, I'm not an engineer, but talking with developers, what I understand is sometimes it's as easy as clicking a button or a couple of buttons, and then you start that update process for the SDK inside of your app.

That's cool.

Cool.

Thank you.

All right.

You talked a little bit about login credentials, which is something that this is a topic I'm at least somewhat familiar with and how important it is to have this information in there.

So, you mentioned things like bypassing two-factor authentication and ensuring a way past like paywalls or access to subscription-based content.

But what other common situations should developers consider?

So, for example, one I've come across is like sometimes apps will have content that's only accessible in certain countries or certain geolocations, or maybe like a messaging app that actually kind of requires two logins to be able to test it.

Are there other situations like that where beyond just providing a login developers might need to go do a little extra?

Yeah.

I mean, I think I was I would always start and end with whatever login credentials you provide for the review team just make sure that it gives them access to all the features in the app.

That section in the Play Developer Console used to be called app access, and I think maybe about a month ago or give or take it was changed to sign-in details.

And so yeah, there's a place you can put in like the username, the password, and then I believe underneath that there's a freeform text field.

And so, you can give instructions on like how do you like what are the steps to log in if it's not very straightforward.

You can also provide a second and a third and a fourth login if you want to users.

And to give you like maybe some insight like when when our teams are reviewing the apps, it's not like someone sitting in a room that kind of pokes around and then just clicks approve or reject.

There is like a lot of teams looking at the different policies and workflows and so it's very likely that you could have your app being logged into by more than one person across multiple devices, sometimes across different regions.

And I get kind of like the difficulty because a lot of safety mechanisms are saying, "Oh, if we see a bunch of logins," then, for the sake of the safety of the user, then it stops puts it back.

But whatever you choose to do, just know that, you know, we are reviewing the app a lot of-- across a lot of different workflows, and that's, you know, so you may end up seeing that.

So, by providing those multiple logins, that can help.

Yeah.

Cool.

Yeah, I must highlight the importance of utilizing that free-form text in the declaration.

So, if your, you know, demo account is not simply like a username, password, and if there are more steps involved, then you should definitely make sure that our review team understands how to jump into your app.

You might be able to, you know, provide a video to showcase how to do so, just to make sure our team understands how to do it if it's more complex than, you know, username, password.

Yeah.

I mean, I like sometimes we'll look at apps ourselves, and there's some like pretty fancy logins.

Like I've seen ones where, and I'm not making this up, it's like tap in this button 17 times, and then like draw like an X on the screen, and then like the developer mode pops up, and then you have like, you know, 11 other steps to follow, so please don't do that.

Cuz that makes it kind of tough.

One scenario I have heard of is, you know, some apps will only allow you to have like X, you know, successive logins, or logins at the same time with an app before it'll be like, "Oh, you've got to remove one."

So, if that's the thing that your app supports, I think including informations of how to find that page where you can remove access to like previous logins is useful as well.

Yeah.

Cool.

So, when we update policies or come out with new policies, sometimes that might require developers to make changes to their app that could potentially, depending on what it is, take some time to implement.

So, sometimes those come with a deadline, right?

Like, by this date, you need to have done XYZ to comply with some new policy.

If that deadline is approaching, but a developer knows they're going to need more time to be able to comply, what are their options there?

Yeah, that sounds kind of like a warning.

It Yeah, it sounds like a warning.

Yeah.

Yeah, so, with warnings, I mean, the simple one is like, this-- just ask for more time, right?

The way that the process works is usually we'll have like releases of new policies, either the new policies or updates on existing policies, or even just clarifications.

And then, I think Google's generally pretty good about giving lead time.

And that policy might be publicly announced 6 months, you know, before we start taking action.

And then, yes, then the warnings will go out and we'll say, "Hey, your app is violating this policy that was announced," you know, "6 or 12 months ago," or what have you.

But one thing that, and Paul and I kind of push back on this sometimes, but they might say you've got 7 days to make this change.

And it's like development takes a long time.

Like, we get it.

And so, what I would do is just respond.

It's you would do it via an appeal, and you can say something like, "Hey, we understand the policy and how our app is, you know, not compliant.

We're already working on it, or these are the steps we're going to take to, you know, resolve the policy issue, but we need more time."

And so, they'll usually give you a little bit more time.

And if it happens to be another 7 days, then, and you're getting towards the end of that, then you can request it again.

It's not infinite, of course.

But I mean, like I said, Paul and I push back, but that's like on an individual basis, and also on like a higher-level basis.

Like when we know that there's new policies coming down the line, and we know maybe who's kind of working on it, we'll say, "Look, can this be like a 28-day warning inst-- instead of 7 days, or even 14 days at least?"

Yeah.

Right.

If you show good faith in, you know, establishing that you are in good faith making changes to come into compliance, then Google Google Play will work with you to, you know, set a new deadline to establish it.

A better timeline for you.

Okay.

So, it sounds like the appeals are like a multi-prong tool to help with a lot of these situations, as long as they're used appropriately.

Like using an appeal when it makes sense and being and communicating enough detail about why you're submitting the appeal can be a good way to get that consideration and help.

All right.

So, if a developer has got multiple apps under one developer account, which I know happens all the time.

And one app gets suspended for some kind of policy violation, what does that mean for their entire developer account?

Does that put the account or other compliant apps at risk?

How does that work?

It could.

That'd be like your your blank-label developers.

I was talking about Joe's Chicken before, right?

And maybe you maybe that's like, you know, you have clients that are all in that industry.

And so, I think of it kind of as like if you're playing baseball, and you've got like strike outs, right?

There are unfortunately bad actors that try to make make it into the Play Store and that's one of the reasons we have these kind of we have light enforcements that go all the way to the heavy-handed ones like removals, suspensions, and then even account bans.

And so if you have one of those scenarios where you have a ton of apps on the Play Store that are all similar, and one of them gets suspended, let's say that…

Mm-hm.

You are a bad actor, right?

And so you fix it up and then a month later you try to slip it back in.

And then our teams catch it and then you get suspended again, right?

And then you take it out of your app, and then you put it back in like a month later and then, okay now we've got like a repetitive pattern of behavior, and you're you're you're at bat, you have gotten three strikeouts, and you're kind of like you're out now, right?

But let's say you're you're making an app for a chicken restaurant, which is like it's not going to be malicious content or anything, you're just trying to get you know delicious food to people.

And so, let's say you're submitting all these apps at the same time with like a CI/CD pipeline or something and you get like 10 apps that all get this rejection or suspe- suspension at the same time, we would only look at that as like one strike out cuz we get it like you're doing lots and lots of apps at the same time.

Mm-hm.

Interesting.

So I think that was the answer to the question.

Yeah, lovely.

Thank you.

And I've got one more for us here.

And this one is maybe A lot of these questions have been more for like established developers maybe, but this one's kind of more about like when you're first getting set up in Play Console.

So, let's say that your Google Play payment profile's been verified, identify Ooh, that's a mouthful.

Identity verification errors are gone now, and only like the phone number verification remains.

Like what does a developer do in that specific case to make sure their developer account's ready to publish apps?

Like sometimes, you're like picking off these individual like pieces of the puzzle or if they don't know how to finish the process in a case like that, what can they do?

Yeah, I had a similar question not too long ago at a different event, but I think like I know that's obviously true for new developers, but I think a lot of the existing developers had to do that verification again.

This was maybe a year so, is that right?

I can't quite re- recall.

A lot of them were automatically verified, but some that were not had to do it.

Okay.

Or maybe like if their address and their Dun & Bradstreet profile didn't match like…

Right.

Right.

The Google profile.

Okay.

Yeah, so there's so let's say it's the phone number.

There's there's I'll answer the question kind of in two ways.

Okay.

One is like, okay, so a lot of times when you're going through these steps, you're going to have notifications that appear in your Play Developer Console.

And so you would just have a notification that says, "Hey, it's time for you to you know register your phone number."

And that one's pretty simple.

You put it in an international phone number format, plus 1 408, whatever the number is.

You'll do like an SMS or a phone call verification and follow the steps there.

But sometimes you end up maybe you have tried to do that, and you're getting like an error message or something, cuz we had developers where that happened as well, or they weren't getting like the SMS code.

I'll give you like the steps to get to see you mention the appeals team.

That's one team, but there's actually like if I don't know if it's half a dozen or two dozen other teams that…

Will.

Answer questions on Play Developer Console that you actually have access to, and it's through the help menu.

Now that was that UI changed a little bit.

It used to be on a menu on the left side of your home screen.

At the bottom, you had a help button.

And that has disappeared, but if now if you just scroll to the bottom of any page in the footer, you'll see that help button.

When you click that, you'll see a little blue pill button that says create support ticket.

I think that's what it says.

Mm-hm.

Yes.

And then you get some drop-downs that you can ask questions.

And there's actually a series of drop-downs that'll get you straight to the phone number, which is I think it's I've got this almost committed to memory, but it's like verify your developer account, the second drop-down is pretty similar, you'll get a bunch of radio buttons.

One of them is specifically for phone number verification.

And then maybe you're having an SMS verification code, or there's a bug that's appearing on your screen when you're trying to go through that process.

So you can do that for phone number verification, but also for a lot of other questions you might have related to your Play Developer account.

And the majority of time, Play Console is very good at ex- exhibiting what the next steps are for verification, so just follow the steps and you'll be good to go.

Awesome.

Cool.

Well, we are just about at time, so thank you all so much for joining us for this panel.