Sessão de perguntas e respostas sobre as políticas do Google Play

Certo.

Agradecemos a participação de todos neste painel sobre as políticas do Google Play.

Sou Jan Kleinert, engenheiro de relações com desenvolvedores na equipe do Android para carros.

Serei o moderador do painel de hoje.

Vou passar a palavra para os nossos palestrantes, Bohdan e Paul, para que eles se apresentem.

Bohdan, vamos começar com você.

Olá, pessoal.

Meu nome é Bohdan e trabalho na equipe de confiabilidade e segurança do Google Play.

Estou aqui há mais de quatro anos e trabalho no setor de confiabilidade e segurança de tecnologia há mais de uma década.

Gosto de ver como a tecnologia, o setor e a cultura interagem e como os eventos incentivam o desenvolvimento de novos apps. Também gosto de eventos como este, em que podemos fazer o melhor para ajudar desenvolvedores como vocês a alcançar o sucesso.

Olá!

Meu nome é Paul.

Trabalho na mesma equipe que o Bohdan e estou na área de confiabilidade e segurança há mais ou menos o mesmo tempo que ele, uma década, e a maior parte desse tempo foi com a equipe de confiabilidade e segurança do Google Play.

Estou muito feliz de estar aqui hoje. Vamos começar.

Certo, agradeço.

Para preparar o terreno antes de começarmos o painel, vou passar a palavra de volta para o Paul.

Ele vai começar com uma breve visão geral dos recursos de política, informações sobre práticas recomendadas e coisas do tipo para ajudar a preparar seu app para uma análise de conformidade com a política mais tranquila e eficiente.

Sim.

Mas o que é a política do Google Play?

Essas são as regras básicas que os desenvolvedores precisam seguir ao publicar e manter apps para dispositivos móveis na Google Play Store.

Mostramos alguns links curtos na tela para recursos de políticas do Google Play.

O primeiro link leva à Central de políticas para desenvolvedores.

Se você clicar em "Atualizações recentes" na parte de cima da página, poderá ler os detalhes sobre as novas políticas, bem como as atualizações ou os esclarecimentos sobre as políticas atuais.

Se você prefere aprender com recursos visuais ou de áudio, o segundo link curto leva a uma playlist dos nossos Policy Bytes.

São vídeos em que falamos sobre as atualizações de políticas.

Por fim, o terceiro link leva a uma página com mais informações sobre os Insights relacionados às políticas do Google Play no Android Studio, um recurso que oferece orientações úteis antes da revisão, na forma de verificações de lint no Android Studio.

Certo.

Também há uma habilidade do Android para ajudar a auditar apps Android em relação a essas políticas do Google Play para verificar a conformidade com permissões, exclusão de conta e segurança dos dados.

É possível instalar essa habilidade usando a CLI do Android, assim como qualquer outra.

android skills list
android skills add play-policy-insights

Por fim, antes de começar com algumas perguntas do painel de Jan, gostaríamos de compartilhar algumas práticas recomendadas para trabalhar com as políticas do Google Play e as revisões de apps.

A primeira é fornecer credenciais de login para os revisores.

Parece simples, mas um motivo muito comum para atrasos ou rejeições é o conteúdo inacessível.

Se o app exigir login ou tiver conteúdo limitado, créditos ou assinaturas, você vai precisar fornecer credenciais de teste.

Para alguns apps, isso significa fornecer credenciais de login apenas no início do app. Para outros, pode haver seções diferentes, como o conteúdo pago que mencionei.

Você pode fazer isso no Play Console e fornecer essas credenciais de login para nossos revisores.

Antes, ela era chamada de "Acesso ao app", mas agora se chama "Detalhes de login" e fica na seção "Conteúdo do app".

E, em seguida, você quer garantir que as credenciais ignorem qualquer tipo de autenticação de dois fatores, captchas, paywalls etc.

Sim, desative os códigos de versão antigos.

Por isso, os desenvolvedores costumam passar pelo que chamamos de loops de rejeição, porque eles fazem upload de uma versão de produção limpa e em conformidade, mas geralmente se esquecem de que uma versão mais antiga e não compatível ainda está ativa no Play Console em outra faixa, seja ela de teste aberto, fechado etc. Portanto, mesmo que um pacote de app esteja em uma faixa de teste antiga, ele está sujeito à análise de conformidade com a política do Google Play.

Portanto, se ele solicitar permissões restritas ou usar SDKs vulneráveis desatualizados, ainda estará sujeito à revisão.

Por isso, substitua ou desative todos os códigos de versão obsoletos em todas as faixas antes de clicar no botão de envio.

Terceiro, reserve tempo suficiente para as revisões e use a publicação gerenciada.

Portanto, as revisões e publicações de apps podem levar sete dias ou mais para serem lançadas, especialmente se for um app novo ou que solicita uma permissão sensível.

Por isso, é importante dar tempo de lead suficiente.

Se você tiver um lançamento importante, envie o novo app pelo menos algumas semanas antes da data de lançamento real.

Depois, você pode vincular isso à publicação gerenciada.

A publicação gerenciada é um recurso que permite reter as atualizações aprovadas até que você esteja pronto para lançá-las, evitando atrasos inesperados durante campanhas de marketing ou outros lançamentos importantes.

E, ao fazer isso, evite reenviar o app depois que ele já tiver sido enviado para revisão.

Se você fizer isso, o relógio vai reiniciar.

Acho que os desenvolvedores às vezes se esquecem disso e, quando estão na metade do desenvolvimento do app, se lembram: "Ah, preciso fazer essa pequena mudança".

Eles reenviaram o anúncio, e ele voltou ao início do processo de revisão.

Certo, verifique suas declarações.

Portanto, as declarações de conteúdo do app, como a seção "Segurança dos dados", a Política de Privacidade ou as permissões de foto/vídeo, por exemplo, precisam corresponder ao manifesto do app de pacotes ativos ou códigos de versão em todas as faixas.

Por exemplo, se o manifesto do app solicitar acesso à localização exata, mas o formulário de declaração de permissões não divulgar a finalidade, o app poderá ser, e provavelmente será, sujeito a restrições.

Por isso, verifique se os SDKs de terceiros não estão exfiltrando dados que você não declarou.

Mesmo que o app não use um dado específico, se você integrar um SDK que use, isso pode levar a uma restrição.

Por isso, confira o SDK Index do Google Play para ver insights sobre mais de 100 dos SDKs comerciais mais usados.

Gostaria de interromper com uma pergunta rápida antes de continuarmos.

Então, quando você diz "restrições", o que quer dizer especificamente?

O que esse termo significa?

As restrições podem ser qualquer ação adversa, desde avisos até rejeições, ou até mesmo restrições mais graves, como remoções, suspensões ou até mesmo banimentos de contas.

Portanto, quando falo em restrições, estou me referindo a essas ações adversas.

Legal.

Nossa equipe agradece.

Sim.

Por fim, use recursos.

Não envie a mesma versão novamente após uma rejeição.

Além disso, rejeições repetidas pelo mesmo problema em um curto período podem acionar um sinalizador algorítmico que leva a restrições mais graves, como remoções ou suspensões.

Se um app for rejeitado, não o envie novamente sem fazer mudanças, adivinhar ou resolver o feedback.

Você vai receber comunicações na caixa de entrada do console e nos e-mails associados que forneceu sobre a violação exata e as orientações.

Se você não concordar com uma rejeição, conteste.

Se você acredita que foi um falso positivo, use o link fornecido na comunicação para contestar.

Essa é uma primeira etapa melhor do que apenas reenviar o app sem fazer mudanças.

E o mesmo vale para o caso de você receber as comunicações e elas não fazerem muito sentido para você, talvez sejam muito prolixas, talvez tenham muitos parágrafos, seja o que for, não há problema em voltar para as contestações.

Ao fazer isso, você vai trocar e-mails com uma pessoa real.

Embora haja limites para o que eles podem comunicar, geralmente é possível conseguir mais detalhes sobre o motivo da rejeição.

Em outros casos, a equipe de contestação entende que as comunicações podem ser bastante longas.

Assim, eles podem destacar ou colocar em negrito as seções que se aplicam especificamente a você e ao seu app.

Então, sim.

Agora, vou passar a palavra para o Jan.

Certo.

Nossa equipe agradece.

Por isso, coletamos perguntas de desenvolvedores em vários canais e fontes diferentes.

As perguntas de hoje representam alguns dos problemas que os desenvolvedores costumam mencionar quando o assunto é política.

Vamos começar com isso.

Quais são alguns dos motivos comuns para um app ser rejeitado devido a permissões?

E como os desenvolvedores podem evitar essas rejeições relacionadas, por exemplo, a violações da política de permissões?

Certo.

Permissões, eu respondo essa.

Portanto, as permissões, principalmente as permissões sensíveis, precisam ser essenciais para o propósito principal do app.

Portanto, se você tiver um recurso auxiliar ou algum recurso que não esteja no app e que nem sequer seja anunciado, é muito provável que o app seja rejeitado.

Portanto, verifique se a declaração corresponde ao caso de uso do app.

Além disso, muitas vezes um app é rejeitado porque os links de vídeo fornecidos nas declarações estão inacessíveis.

Nossa equipe de revisão precisa acessar o app, os links de vídeo que você fornecer, tudo o que estiver no app para, você sabe, analisar o app por completo.

Portanto, verifique se tudo está acessível no app, no manifesto e na declaração.

Portanto, garanta que esses três itens sejam feitos e, muito provavelmente, bem, não quero dizer muito provavelmente, mas será um processo mais tranquilo.

Legal.

Certo.

Então, mais desenvolvedores de apps estão começando a usar plataformas de terceiros para conteúdo gerado com IA nos apps, certo?

Se essas plataformas produzirem conteúdo inadequado, incorreto ou algo do tipo, isso pode levar à rejeição do app do desenvolvedor? E quem é realmente responsável nesses casos?

Sim.

Sim, isso pode levar a uma rejeição.

Desde o início da Google Play Store, a posição sempre foi que o desenvolvedor é responsável por tudo o que está no app ou que o usuário pode acessar nele.

E, embora a IA generativa seja uma área nova, isso também se aplica a ela.

Acho que um bom paralelo com a IA generativa é o conteúdo gerado pelo usuário, porque para ambas as políticas é preciso ter muitos dos mesmos tipos de, você sabe, é preciso ter sinalização, você sabe, se algo aparece que não é muito apropriado.

É preciso haver um mecanismo de filtragem.

Acho que existem outras políticas que se aplicam, mas gosto de pensar assim: se você tem conteúdo de IA generativa, o Google revisa o app, os usuários sinalizam se virem algo inadequado e você tem seus mecanismos de filtragem.

Então, o Google, os desenvolvedores e os usuários trabalham juntos para manter o app o mais seguro possível para todos.

Ok.

Ótimo.

Mas, em geral, recomendamos que, além de ter mecanismos para os usuários sinalizarem conteúdo, os desenvolvedores coloquem algum tipo de É isso que você quer dizer com mecanismo de filtragem?

Para impedir que certos tipos de conteúdo sejam mostrados aos usuários?

Correto.

Sim.

Durante o processo de análise, nossas equipes não vão tentar analisar seu código ou fazer engenharia reversa para descobrir qual é seu mecanismo de filtragem exato.

Eles só vão verificar se é possível acessar algo inadequado.

Se puderem, vamos enviar algumas comunicações de volta, e então será o trabalho da sua equipe descobrir como tornar esse mecanismo de filtragem mais robusto.

Entendi.

Legal, agradeço.

Uma das políticas que existem é chamada de política de falsificação de identidade ou de imitação, certo?

Se um app for rejeitado de acordo com essa política de falsificação de identidade, mas o desenvolvedor acreditar que isso é um erro, por qualquer motivo, o que ele deve fazer?

Como evitar esse tipo de rejeição de forma proativa?

Contestação.

Sim, essa foi uma das, acho que foi a quinta prática recomendada que temos no quadro: se você for rejeitado por isso, deve contestar.

E o que você deve fazer é, bem, os cenários mais comuns são que a marca que você está personificando é, talvez, sua própria marca, certo?

Ou você está criando um app para outra pessoa, o que é provavelmente o mais comum, em que desenvolvedores de marca branca criam apps para, por exemplo, academias, SaaS, algum tipo de solução SaaS.

Mas é mais fácil publicar esses apps na sua própria conta de desenvolvedor, certo?

Por isso, você pode contestar, e nossa equipe vai procurar o que chamamos de comprovante de permissão.

Digamos que você tenha um cliente chamado Joe's Chicken, que vende o melhor frango a oeste do Mississippi.

Eles vão enviar uma carta de comprovação de permissão em papel timbrado oficial da empresa com o logotipo, dizendo: "Nós, da Joe's Chicken, estamos dando permissão ao Desenvolvedor ABC para usar nossas imagens e semelhanças no app". É melhor que eles coloquem o nome do app e o nome do pacote do app.

Por exemplo, com.joeschicken.app ou algo assim. Depois, você pode responder ao desenvolvedor e fornecer essa documentação.

Ok.

E acho que a segunda parte foi…

Existe algo que eles possam fazer de forma proativa para evitar isso?

Por exemplo, é possível fazer o upload de, esqueci o nome, comprovante de alguma coisa, sabe, no momento do primeiro envio?

Sim.

Certo.

No Play Console, há o que chamamos de formulário de aviso com antecedência, que você pode enviar, fazer upload, sabe, dessas formas de documentação que associam sua conta à outra entidade.

Assim, você pode proteger preventivamente o envio do app contra esse tipo de ação de restrição adversa.

Isso mesmo.

Legal.

Certo.

Você mencionou um pouco sobre o uso de SDKs de terceiros na seção de práticas recomendadas, mas gostaria de me aprofundar um pouco mais nisso.

Então, quando os apps usam SDKs de terceiros, parece que é verdade que os desenvolvedores de apps são responsáveis por como esses SDKs de terceiros usam coisas como dados do usuário.

Como os desenvolvedores podem saber se os SDKs estão em conformidade com as políticas de segurança e de dados do usuário?

Como eles podem navegar por esse cenário?

Sim, essa é uma ótima pergunta.

Trabalhei muito com SDKs no Google nos meus primeiros dois anos aqui, e isso remete à pergunta anterior, em que falávamos sobre IA generativa e conteúdo gerado pelo usuário, no sentido de que tudo o que está no app é, em última análise, responsabilidade do desenvolvedor.

Acho que o Paul mencionou rapidamente na introdução que temos o SDK Index do Google Play. Você pode pesquisar isso no Google.

Deve ser o primeiro ou segundo resultado, SDK Index do Google Play. Você vai acessar uma página da Web com mais de cem, talvez várias centenas de SDKs divididos por categoria: SDK para monetização, para anúncios, para saúde ou algo diferente?

E essa página só extrai dados disponíveis publicamente.

É um evento organizado pelo Google.

Mas você vai notar que, ao analisar esses SDKs, alguns deles terão um selo que diz algo como "registrado no SDK Console".

Assim como vocês, desenvolvedores, têm um Play Console para seus apps, os desenvolvedores de SDKs têm a opção de acessar um SDK Console.

E eles precisam passar por um processo de análise semelhante.

Eles nos enviam o SDK.

O Google faz algumas verificações diferentes, mas, se tudo estiver certo e em conformidade, o anunciante recebe o selo.

Para vocês, desenvolvedores, isso significa que é possível acessar esse índice e ver quais SDKs passaram por esse processo.

Isos não garante que o app será aprovado ou que o SDK nunca vai deixar de estar em conformidade, mas eu diria que isso dá dois pontos de confiança.

A primeira é que há uma probabilidade muito maior de que o app não seja rejeitado se você estiver usando esse SDK.

É só uma probabilidade.

A segunda, e isso é algo que eu realmente gosto em todo esse processo, é que, se descobrirmos que o SDK tem algo que não está em conformidade, adotaremos uma abordagem dupla.

A primeira é que vamos entrar em contato com o desenvolvedor do SDK e dizer: "Notamos que seu SDK está enviando dados do usuário de uma forma que não está em conformidade".

Depois, eles vão trabalhar para que o app ou SDK esteja em conformidade.

E, ao mesmo tempo, ou talvez um pouco depois, nossas equipes enviam notificações ou avisos aos desenvolvedores.

A notificação vai dizer algo como: "Notamos que seu app está enviando esses dados de maneira não compatível e que isso está acontecendo no SDK ABC".

Portanto, as etapas que você pode seguir como desenvolvedor é apenas atualizar o SDK para qualquer versão compatível que eles tenham fornecido.

Se você quiser uma solução mais drástica, pode remover ou substituir o SDK, mas sei que isso dá muito trabalho.

Mas é isso que eu gosto no SDK Index do Google Play.

Sim.

O índice não diz exatamente com quais políticas ele está ou não em conformidade, mas você recebe esse selo, que é como um voto de confiança.

Ok.

Sim.

Ok, parece bom.

E parece que, se eu entendi bem o que você disse, se enviarmos uma mensagem aos desenvolvedores dizendo: "Você está usando este SDK e ele tem um problema".

Se o desenvolvedor corrigir o problema, nós informamos que uma versão melhor está disponível?

Ou eles precisam fazer um pouco dessa pesquisa por conta própria?

Acho que ele tem o código da versão.

Não tenho certeza, mas acredito que o código da versão para a qual eles podem atualizar esteja listado lá.

Sim, e para ser totalmente transparente, não sou desenvolvedor nem engenheiro, mas, conversando com desenvolvedores, entendo que às vezes é tão fácil quanto clicar em um botão ou em alguns botões, e então você inicia o processo de atualização do SDK no seu app.

Legal.

Legal.

Nossa equipe agradece.

Certo.

Você falou um pouco sobre credenciais de login, um assunto que conheço um pouco e sei como é importante ter essas informações.

Você mencionou coisas como burlar a autenticação de dois fatores e garantir uma forma de contornar paywalls ou acessar conteúdo por assinatura.

Mas quais outras situações comuns os desenvolvedores precisam considerar?

Por exemplo, um que encontrei é que, às vezes, os apps têm conteúdo que só pode ser acessado em determinados países ou geolocalizações, ou talvez um app de mensagens que exige dois logins para ser testado.

Existem outras situações como essa em que, além de fornecer um login, os desenvolvedores precisam fazer algo mais?

Sim.

Eu sempre começo e termino com as credenciais de login que você fornece para a equipe de revisão. Verifique se elas dão acesso a todos os recursos do app.

Essa seção no Play Console costumava ser chamada de "Acesso de apps", mas, há mais ou menos um mês, o nome mudou para "Detalhes de login".

Então, sim, há um lugar onde você pode colocar o nome de usuário, a senha e, abaixo disso, acredito que há um campo de texto livre.

Assim, você pode dar instruções sobre como fazer login se não for muito simples.

Você também pode fornecer um segundo, terceiro e quarto login se quiser que os usuários

E para dar uma ideia de como nossas equipes analisam os apps, não é como se alguém estivesse em uma sala, mexendo um pouco e depois clicando em "Aprovar" ou "Rejeitar".

Há muitas equipes analisando as diferentes políticas e fluxos de trabalho, então é muito provável que seu app seja acessado por mais de uma pessoa em vários dispositivos, às vezes em regiões diferentes.

E eu entendo a dificuldade, porque muitos mecanismos de segurança dizem: "Ah, se virmos muitos logins", então, para a segurança do usuário, ele para e volta.

Mas, seja qual for sua escolha, saiba que estamos revisando o app em vários fluxos de trabalho diferentes, e talvez você veja isso.

Por isso, fornecer esses vários logins pode ajudar.

Sim.

Legal.

Sim, preciso destacar a importância de usar esse texto de formato livre na declaração.

Portanto, se a conta de demonstração não for simplesmente um nome de usuário e uma senha, e se houver mais etapas envolvidas, verifique se a equipe de revisão entende como acessar o app.

Se for mais complexo do que apenas nome de usuário e senha, você pode enviar um vídeo mostrando como fazer isso para garantir que nossa equipe entenda o processo.

Sim.

Às vezes, nós mesmos analisamos os apps e vemos alguns logins bem sofisticados.

Já vi alguns em que, e não estou inventando, você precisa tocar em um botão 17 vezes, desenhar um X na tela, ativar o modo de desenvolvedor e seguir mais 11 etapas. Não faça isso.

Porque isso dificulta as coisas.

Um cenário que já ouvi falar é, por exemplo, alguns apps só permitem que você tenha X logins sucessivos ou logins ao mesmo tempo com um app antes de dizer: "Ah, você precisa remover um".

Então, se o app oferece essa opção, acho que também é útil incluir informações sobre como encontrar a página em que é possível remover o acesso a logins anteriores.

Sim.

Legal.

Por isso, quando atualizamos ou lançamos políticas, às vezes os desenvolvedores precisam fazer mudanças no app que, dependendo do que for, podem levar algum tempo para serem implementadas.

Às vezes, eles têm um prazo, certo?

Por exemplo, até essa data, você precisa ter feito XYZ para obedecer a uma nova política de apps de notícias.

Se o prazo estiver se aproximando, mas um desenvolvedor souber que vai precisar de mais tempo para cumprir os requisitos, quais são as opções?

É, parece um aviso.

Sim, parece um aviso.

Sim.

Sim, então, com os avisos, quero dizer, o mais simples é como, isso-- basta pedir mais tempo, certo?

O processo geralmente funciona assim: lançamos novas políticas, atualizações de políticas atuais ou apenas esclarecimentos.

E acho que o Google costuma ser bem generoso com o tempo de lead.

E essa política pode ser anunciada publicamente seis meses antes de começarmos a tomar medidas.

E aí, sim, os avisos serão enviados e vamos dizer: "Seu app está violando esta política que foi anunciada", sabe, "6 ou 12 meses atrás" ou algo assim.

Mas uma coisa que, e o Paul e eu às vezes discordamos disso, mas eles podem dizer que você tem sete dias para fazer essa mudança.

E o desenvolvimento leva muito tempo.

Tipo, nós entendemos.

Então, o que eu faria é apenas responder.

Você pode fazer isso por meio de uma contestação e dizer algo como: "Entendemos a política e como nosso app não está em conformidade.

Já estamos trabalhando nisso ou estas são as etapas que vamos seguir para resolver o problema com a política, mas precisamos de mais tempo."

Por isso, geralmente dão um pouco mais de tempo.

Se o prazo for de mais sete dias, você poderá pedir outra extensão quando esse período estiver acabando.

Claro que não é infinito.

Mas, como eu disse, o Paul e eu nos opomos, mas isso é individual e também em um nível mais alto.

Por exemplo, quando sabemos que novas políticas estão chegando e quem está trabalhando nelas, dizemos: "Olha, isso pode ser um aviso de 28 dias em vez de 7 dias, ou pelo menos 14 dias?"

Sim.

Certo.

Se você demonstrar boa-fé, sabe, ao estabelecer que está fazendo mudanças para entrar em conformidade, o Google Play vai trabalhar com você para, sabe, definir um novo prazo.

Uma linha do tempo melhor para você.

Ok.

Então, as contestações são como uma ferramenta multifuncional para ajudar em muitas dessas situações, desde que sejam usadas de forma adequada.

Por exemplo, enviar uma contestação quando fizer sentido e comunicar detalhes suficientes sobre o motivo do envio pode ser uma boa maneira de receber essa consideração e ajuda.

Certo.

Então, se um desenvolvedor tiver vários apps em uma única conta de desenvolvedor, o que acontece o tempo todo,

E um app é suspenso por algum tipo de violação da política, o que isso significa para toda a conta de desenvolvedor?

Isso coloca a conta ou outros apps em conformidade em risco?

Como ele funciona?

Pode ser.

Isso seria como os desenvolvedores de marca branca.

Eu estava falando sobre o Joe's Chicken antes, certo?

E talvez você tenha clientes que estão todos nesse setor.

É como se você estivesse jogando beisebol e sofresse um strikeout, sabe?

Infelizmente, há usuários de má-fé que tentam entrar na Google Play Store, e esse é um dos motivos para termos restrições que vão desde as mais leves até as mais pesadas, como remoções, suspensões e até banimentos de contas.

Se você tiver um cenário em que há vários apps semelhantes na Google Play Store e um deles for suspenso, digamos que…

Mm-hm.

Você é um usuário de má-fé, certo?

Então você corrige o problema e, um mês depois, tenta colocar o conteúdo de volta.

E aí nossas equipes descobrem e você é suspenso de novo, certo?

E aí você remove o recurso do app e o adiciona de novo um mês depois. Agora temos um padrão de comportamento repetitivo, e você está na sua vez de rebater, já teve três eliminações e agora está fora do jogo, certo?

Mas digamos que você esteja criando um PPA para um restaurante de frango, que não vai ter conteúdo mal-intencionado nem nada, você só está tentando levar comida deliciosa para as pessoas.

Digamos que você envie todos esses apps ao mesmo tempo com um pipeline de CI/CD ou algo assim e receba 10 apps com essa rejeição ou suspensão ao mesmo tempo. Vamos considerar isso como uma única violação, porque entendemos que você está fazendo muitos apps ao mesmo tempo.

Mm-hm.

Interessante.

Acho que essa é a resposta para a pergunta.

Sim, adorável.

Nossa equipe agradece.

E tenho mais um para nós aqui.

E esta é talvez… Muitas dessas perguntas foram mais para desenvolvedores estabelecidos, talvez, mas esta é mais sobre quando você está começando a configurar o Play Console.

Digamos que seu perfil para pagamentos do Google Play tenha sido verificado, identifique… Nossa, que nome comprido.

Os erros de confirmação de identidade desapareceram, e agora só resta a verificação de número de telefone.

Por exemplo, o que um desenvolvedor faz nesse caso específico para garantir que a conta de desenvolvedor esteja pronta para publicar apps?

Às vezes, você está juntando as peças do quebra-cabeça, mas se eles não souberem como concluir o processo em um caso como esse, o que podem fazer?

Sim, recebi uma pergunta parecida há pouco tempo em outro evento. Acho que isso é verdade para novos desenvolvedores, mas muitos dos desenvolvedores atuais tiveram que fazer essa verificação novamente.

Isso foi há mais ou menos um ano, certo?

Não me lembro.

Muitos foram verificados automaticamente, mas alguns que não foram precisaram fazer isso.

Ok.

Ou talvez se o endereço e o perfil da Dun & Bradstreet não corresponderem, como…

Certo.

Certo.

O perfil do Google.

Ok.

Sim, então digamos que seja o número de telefone.

Vou responder à pergunta de duas maneiras.

Ok.

Uma delas é que, muitas vezes, ao seguir essas etapas, você vai receber notificações no Play Console.

Você receberia uma notificação dizendo: "Ei, chegou a hora de registrar seu número de telefone".

E essa é bem simples.

Insira o número de telefone no formato internacional, como +1 408, seguido pelo número.

Você vai fazer uma verificação por SMS ou ligação telefônica e seguir as etapas.

Mas, às vezes, você tenta fazer isso e recebe uma mensagem de erro ou algo assim, porque tivemos desenvolvedores que passaram por isso ou não receberam o código por SMS.

Vou mostrar as etapas para você falar com a equipe de contestações.

Essa é uma equipe, mas na verdade existem, não sei se meia dúzia ou duas dúzias de outras equipes que…

Will.

Responda às perguntas no Play Console que você realmente tem acesso, e isso é feito pelo menu de ajuda.

Agora que a interface mudou um pouco.

Antes, ela ficava em um menu no lado esquerdo da tela inicial.

Na parte de baixo, havia um botão de ajuda.

Isso desapareceu, mas agora, se você rolar até o final de qualquer página, vai encontrar o botão de ajuda no rodapé.

Ao clicar nele, você verá um pequeno botão azul que diz "Criar tíquete de suporte".

Acho que é isso que está escrito.

Mm-hm.

Sim.

Depois, você verá alguns menus suspensos para fazer perguntas.

E há uma série de menus suspensos que levam direto ao número de telefone. Acho que já decorei quase tudo, mas é algo como "verificar sua conta de desenvolvedor". O segundo menu suspenso é bem parecido, e você vai encontrar vários botões de opção.

Uma delas é especificamente para a verificação de número de telefone.

E talvez você esteja recebendo um código de verificação por SMS ou um bug esteja aparecendo na tela quando você tenta passar por esse processo.

Você pode fazer isso para verificação de número de telefone, mas também para muitas outras dúvidas que possa ter sobre sua conta de desenvolvedor do Google Play.

Na maioria das vezes, o Play Console é muito bom em mostrar as próximas etapas para a verificação. Basta seguir as instruções e pronto.

Ótimo.

Legal.

Bem, nosso tempo está acabando, então agradeço a todos por participarem deste painel.