Plugins do Google Play para Unity: Instale pelos Novos Repos Git

Introdução

O Google mudou a forma de distribuir os plugins do Google Play para Unity. O antigo repositório monolítico google/play-unity-plugins, que juntava vários plugins, foi dividido em repositórios individuais. As novas versões são publicadas por plugin, e você instala tudo direto do Git usando o Unity Package Manager (UPM).

A migração em si é simples depois que o layout dos repositórios fica claro — mas alguns detalhes derrubam quase todo mundo e geram erros confusos no UPM, como package.json cannot be found ou uma falha de rename EPERM no Windows.

Neste guia você vai aprender:

• O que realmente mudou nos plugins do Google Play para Unity
• Instalação manual via .unitypackage vs. instalação via Git, e por que o Git costuma ganhar
• As URLs Git corretas, incluindo por que o ?path= é obrigatório
• Como funciona a cadeia de dependências entre Common, Core, EDM4U e In-App Review
• Como migrar um projeto existente que usava OpenUPM
• Onde o packages-lock.json entra na história
• Como resolver Repository does not contain a package manifest e o EPERM do Windows
• Um prompt pronto para um agente de IA fazer a migração por você

Todas as URLs e números de versão abaixo refletem os manifests atuais dos pacotes no momento da escrita. Sempre abra o package.json do próprio pacote para confirmar antes de fixar uma versão.

O Problema: O Pacote Não Está na Raiz do Repositório

Antes, vários plugins ficavam em um único repositório:

google/play-unity-plugins

O novo modelo usa um repositório por plugin:

Google Play Common     https://github.com/google/play-common-unity
Google Play Core       https://github.com/google/play-core-unity
Google Play In-App Review  https://github.com/google/play-in-app-reviews-unity
External Dependency Manager for Unity  https://github.com/googlesamples/unity-jar-resolver

E aqui está a pegadinha. Quando você aponta o UPM para uma URL Git, a Unity clona o repositório e procura um manifest em:

repository-root/package.json

Mas o Google Play Common guarda o pacote dentro de um subdiretório:

com.google.play.common/package.json

Então instalar https://github.com/google/play-common-unity.git falha com:

Repository does not contain a package manifest:
The file .../clone/package.json cannot be found

O repositório está perfeitamente válido. O pacote UPM é que não está na raiz.

A Solução: O Parâmetro ?path=

O ?path= diz à Unity qual subdiretório tratar como o pacote. Em vez de:

https://github.com/google/play-common-unity.git

use:

https://github.com/google/play-common-unity.git?path=com.google.play.common

A leitura é: clone este repositório, mas trate com.google.play.common como o pacote UPM. O package.json dele o identifica como com.google.play.common, atualmente na versão 1.9.2.

A mesma regra vale para todos os repositórios do Google Play — só muda o nome da subpasta.

Instalação Manual vs. Instalação via Git

Opção 1 — .unitypackage manual

O Google ainda publica arquivos .unitypackage nas páginas de Releases do GitHub. Baixe um, importe e pronto. Funciona, mas o custo é a manutenção:

.unitypackage  →  Assets/

O plugin vira parte dos arquivos do projeto em vez de ser gerenciado pelo UPM. Atualizar depois significa achar a nova release, importar, reconciliar arquivos existentes, apagar os antigos e checar assemblies duplicados e conflitos de dependência toda vez.

Opção 2 — Instalar via Git (recomendado)

Se o seu projeto já usa UPM, instale direto dos repositórios Git oficiais:

https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review

Vantagens:

• A instalação fica toda descrita no Packages/manifest.json
• O pacote fica fora da pasta Assets
• As dependências transitivas são declaradas pelos manifests dos pacotes
• A configuração se reproduz limpa em outra máquina ou em CI/CD
• Um agente de IA consegue modificar o projeto de forma determinística

As URLs Git Corretas

Google Play Common

https://github.com/google/play-common-unity.git?path=com.google.play.common

Com versão fixada:

https://github.com/google/play-common-unity.git?path=com.google.play.common#v1.9.2

{
    "name": "com.google.play.common",
    "version": "1.9.2"
}

Google Play Core

https://github.com/google/play-core-unity.git?path=com.google.play.core

Com versão fixada:

https://github.com/google/play-core-unity.git?path=com.google.play.core#v1.8.6

{
    "name": "com.google.play.core",
    "version": "1.8.6"
}

Google Play In-App Review

https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review

Com versão fixada:

https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review#v1.8.4

{
    "name": "com.google.play.review",
    "version": "1.8.4"
}

External Dependency Manager for Unity (EDM4U)

O EDM4U tem um layout diferente — o pacote UPM fica em upm/:

https://github.com/googlesamples/unity-jar-resolver.git?path=upm

O manifest atual o identifica como com.google.external-dependency-manager, versão 1.2.189.

A Cadeia de Dependências

O erro mais comum na migração é instalar cada pacote de forma independente e atualizar todos para a versão mais nova. Isso ignora o que cada pacote realmente exige.

Para o In-App Review, a cadeia é assim:

Google Play In-App Review
    ├── Google Play Common
    └── Google Play Core
            └── External Dependency Manager for Unity

Mais precisamente, o pacote atual do In-App Review declara:

com.google.play.common = 1.9.2
com.google.play.core   = 1.8.6

E o pacote atual do Play Core declara:

com.google.external-dependency-manager = 1.2.185

Instalar o EDM4U 1.2.189 só porque é mais novo não é automaticamente o certo para esse grafo. O Play Core pede 1.2.185. Trate os metadados do pacote como fonte da verdade, não o "latest".

A Forma Mais Fácil de Instalar o In-App Review

Adicione uma única dependência:

https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review

A Unity resolve o resto:

com.google.play.review
    → com.google.play.common
    → com.google.play.core
    → com.google.external-dependency-manager

Isso é muito mais limpo do que gerenciar quatro pacotes na mão.

E os Outros Plugins do Google Play?

O mesmo conceito de ?path= vale para todos os pacotes do Google Play para Unity. O Google mantém repositórios separados para recursos como:

• In-App Review
• In-App Updates
• Play Integrity
• Play Asset Delivery
• Play Core
• Play Common

Instale o pacote do recurso que o seu jogo realmente usa e deixe as dependências declaradas serem resolvidas. Se você só precisa do In-App Review, não há motivo para adicionar todos os pacotes do Google Play ao seu manifest.

Migrando um Projeto Existente do OpenUPM

Projetos mais antigos costumavam puxar esses pacotes pelo OpenUPM. Seu manifest.json pode ter:

{
    "dependencies": {
        "com.google.play.review": "1.8.4",
        "com.google.play.core": "1.8.6",
        "com.google.play.common": "1.9.2",
        "com.google.external-dependency-manager": "1.2.185"
    }
}

Mais um scoped registry:

{
    "name": "OpenUPM",
    "url": "https://package.openupm.com",
    "scopes": [
        "com.google"
    ]
}

Se você migrar para o Git mas deixar o escopo com.google do OpenUPM no lugar, a Unity pode resolver esses pacotes pelo registry em vez da sua URL Git. Remova o escopo conflitante.

Passo 1: Faça backup primeiro

Copie isto antes de mexer em qualquer coisa:

Packages/manifest.json
Packages/packages-lock.json
ProjectSettings/
Assets/

Passo 2: Identifique os pacotes do Google

Procure em Packages/manifest.json, Packages/packages-lock.json e Assets/ por:

com.google.play
com.google.external-dependency-manager

Passo 3: Remova as dependências antigas do OpenUPM

Apague só as entradas do Google que o Git vai substituir:

com.google.play.review
com.google.play.core
com.google.play.common
com.google.external-dependency-manager

Não mexa em pacotes não relacionados do OpenUPM. Se outros pacotes ainda usam o registry do OpenUPM, mantenha o registry e remova apenas o escopo com.google.

Passo 4: Verifique cópias duplicadas de plugin em Assets/

Este passo importa. Alguns projetos têm os plugins instalados via .unitypackage e via UPM ao mesmo tempo, então você acaba com os dois:

Assets/GooglePlayPlugins/
Packages/com.google.play.core/

Isso gera erros como Assembly already exists, The type X exists in both assemblies ou conflitos de GUID duplicado. Remova as cópias soltas em Assets/ antes de migrar para o Git — mas só depois de confirmar que nada mais depende delas.

Passo 5: Feche a Unity completamente

Feche a Unity e, para uma migração séria de pacotes, feche também o Unity Hub, o Visual Studio e o JetBrains Rider. Isso evita que um processo do Windows mantenha arquivos dentro de Library travados.

Passo 6: Lide com a pasta Library

Library/ é dado gerado. Se o Package Manager travar em um estado ruim, é seguro apagar Library/ e deixar a Unity reconstruir. Nunca apague Assets/, Packages/ ou ProjectSettings/.

Passo 7: Instale o pacote do recurso

Para um projeto com In-App Review:

https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review

Não adicione Common e Core na mão a menos que tenha um motivo concreto.

Passo 8: Deixe a Unity resolver e verifique

Abra Window → Package Manager e confirme que os pacotes do Google estão presentes, depois inspecione Packages/packages-lock.json para ver exatamente o que a Unity resolveu.

Entendendo o packages-lock.json

O packages-lock.json importa ainda mais com pacotes Git. Mesmo quando o seu manifest tem uma URL Git, a Unity registra a revisão resolvida no lock file:

manifest.json
    → dependência Git
    → o Package Manager resolve uma revisão
    → packages-lock.json

Quando for diagnosticar um problema de atualização, sempre leia os dois: manifest.json e packages-lock.json. Mudar só a URL não te diz o que a Unity está realmente usando.

Vale Usar URLs Git Sem Tag?

Pode:

https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review

Isso acompanha o branch padrão do repositório. Mas uma URL sem tag não significa "baixar a versão mais nova a cada inicialização" — a Unity ainda resolve e trava uma revisão no packages-lock.json. Só significa que você segue a linha de desenvolvimento atual em vez de uma release específica.

Para produção, fixe uma tag:

https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review#v1.8.4

Para um projeto de hobby ou de desenvolvimento onde a conveniência pesa mais, o branch sem tag é aceitável.

Quando Declarar Common, Core ou EDM4U Explicitamente?

Há casos legítimos:

• Seu projeto usa vários plugins do Google Play
• Outro pacote precisa do Play Core
• Você precisa de uma versão específica do EDM4U
• Seu sistema de build exige uma entrada explícita do pacote
• Você está depurando um problema de resolução de dependência

Nesses casos, use os paths corretos:

https://github.com/google/play-common-unity.git?path=com.google.play.common
https://github.com/google/play-core-unity.git?path=com.google.play.core
https://github.com/googlesamples/unity-jar-resolver.git?path=upm

Sempre leia o package.json do próprio pacote antes de sobrescrever uma versão transitiva.

Corrigindo os Dois Erros Que Você Vai Encontrar de Verdade

Repository does not contain a package manifest

Causa: a URL Git aponta para a raiz do repositório, mas o package.json está em um subdiretório. Solução: adicione o parâmetro ?path= correto antes de tentar qualquer outra coisa.

# Errado
https://github.com/google/play-common-unity.git

# Certo
https://github.com/google/play-common-unity.git?path=com.google.play.common

error code [EPERM] no Windows

Failed to rename [...] to [...]
error code [EPERM]

Isso não é problema de URL Git. EPERM significa que o sistema operacional recusou uma operação porque um arquivo ou diretório está travado. Culpados comuns: Unity ainda aberta, o cache do Package Manager em uso, indexação de arquivos da IDE, antivírus, indexação do Windows Search, um diretório temporário de pacote antigo ou permissões do diretório.

Procedimento de recuperação:

1. Feche a Unity
2. Feche o Unity Hub
3. Feche o Rider / Visual Studio
4. Confirme que nenhum processo da Unity permanece
5. Apague Library/
6. Reinicie a Unity e deixe ela reconstruir Library
7. Tente o pacote Git de novo

Não mude a URL Git quando o erro for EPERM — os dois problemas não têm relação.

Automatizando a Migração com um Agente de IA

A maior parte dessa migração é determinística, o que a torna uma boa candidata para um agente de IA — desde que o agente inspecione o projeto primeiro em vez de sair trocando strings às cegas. Aqui está um prompt para você entregar a ele:

Você está modificando um projeto Unity existente.

Tarefa: migrar os plugins do Google Play para Unity do OpenUPM / instalações
legadas para os repositórios Git oficiais do Google.

IMPORTANTE: inspecione antes de mudar qualquer coisa.

1. Leia Packages/manifest.json e Packages/packages-lock.json.
2. Procure no projeto por: com.google.play, com.google.external-dependency-manager,
   GooglePlayPlugins, ExternalDependencyManager.
3. Determine como os plugins estão instalados hoje (OpenUPM, URLs Git,
   .unitypackage, Assets/, UPM).
4. Faça backup de Packages/manifest.json e Packages/packages-lock.json.
5. Remova APENAS as definições antigas de pacote do Google Play que serão
   substituídas. Não remova pacotes não relacionados.
6. Remova o escopo "com.google" do scoped registry do OpenUPM só se ele estiver
   presente e não for mais necessário.
7. Verifique Assets/ por cópias duplicadas de plugin (Assets/GooglePlayPlugins/,
   Assets/ExternalDependencyManager/). Reporte o que encontrar; não apague
   automaticamente se não estiver claro se algo depende delas.
8. Use os repositórios Git oficiais:
   Common:  https://github.com/google/play-common-unity.git?path=com.google.play.common
   Core:    https://github.com/google/play-core-unity.git?path=com.google.play.core
   Review:  https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review
   EDM4U:   https://github.com/googlesamples/unity-jar-resolver.git?path=upm
9. Prefira instalar só o pacote do recurso que o projeto realmente precisa. Se
   ele só precisa do In-App Review, adicione apenas o pacote review e deixe as
   dependências transitivas resolverem.
10. Leia o package.json de cada pacote do Google envolvido e respeite as versões
    de dependência que ele declara. Não atualize dependências transitivas às cegas.
11. Preserve a versão da Unity do projeto e todas as versões de pacote não
    relacionadas.
12. Não atualize a Unity.
13. Não substitua pacotes que funcionam só porque existem versões mais novas.
14. Garanta que manifest.json seja JSON válido após a edição.
15. Se packages-lock.json estiver desatualizado ou conflitante, apague-o só
    depois do backup e deixe a Unity regenerar.
16. Não edite manualmente arquivos gerados em Library.
17. Se a instalação falhar com "Repository does not contain a package manifest",
    verifique o parâmetro "?path=" antes de tentar qualquer outra coisa.
18. Se a instalação falhar com "error code [EPERM]", trate como um problema local
    de trava/cache de arquivo no Windows: recomende fechar os processos da
    Unity/IDE e reconstruir Library/.
19. Relatório final: pacotes removidos, pacotes Git adicionados, quais
    dependências são transitivas, versões que a Unity resolveu, instalações
    duplicadas restantes, conflitos potenciais.

Não faça mudanças não relacionadas no projeto.

Boas Práticas para CI/CD

Pacotes UPM baseados em Git brilham em builds automatizados. Um ambiente de CI lê o Packages/manifest.json e busca as dependências sem nenhum desenvolvedor importando .unitypackage na mão. Para builds de produção, fixe tags de release em vez de acompanhar um branch móvel:

# Reproduzível
https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review#v1.8.4

# Alvo móvel
https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review

Resultado: A Configuração Final Recomendada

Para um projeto Unity cujo único recurso do Google Play é o In-App Review:

Seu Projeto Unity
├── Assets/
├── Packages/
│   ├── manifest.json
│   └── packages-lock.json
└── ProjectSettings/

Com uma única dependência de recurso no manifest.json:

{
    "dependencies": {
        "com.google.play.review": "https://github.com/google/play-in-app-reviews-unity.git?path=com.google.play.review#v1.8.4"
    }
}

Resolvendo para:

com.google.play.review
    ├── com.google.play.common
    └── com.google.play.core
            └── com.google.external-dependency-manager

Conclusão

Sair do antigo repositório único para repositórios Git por plugin não é difícil, mas muda um hábito importante: você não pode mais assumir que um repo Git instala pela raiz. Os repositórios do Google guardam seus pacotes UPM em subdiretórios, então a Unity precisa do parâmetro ?path= correto.

Para a maioria dos projetos — especialmente quando a necessidade imediata é o Google Play In-App Review — a configuração correta mais simples é instalar só o pacote do recurso:

com.google.play.review

e deixar o Unity Package Manager resolver as dependências declaradas pelos manifests do Google. Instalações manuais via .unitypackage ainda funcionam, mas o UPM baseado em Git te dá um projeto mais limpo, reproduzível e amigável a automação.

Resumindo: use os repositórios Git oficiais, use o parâmetro ?path= correto, respeite as versões de dependência que o Google declara e deixe o Package Manager cuidar do grafo de dependências.

Se você estiver batendo em um erro de plugin do Google Play que este guia não cobre, deixe um comentário ou entre em contato — vou adorar ajudar a rastrear. E se você também estiver no meio de um upgrade de engine da Unity, meu texto sobre migrar InstanceID para EntityId no Unity 6000.5 cobre outra migração cheia das mesmas armadilhas do tipo "parece um rename, mas não é só um rename".