Em projetos Android com arquitetura modular, é comum encontrar deasfios relacionados ao gerenciamento de dependências. Um dos problemas mais frequentes e frustrantes é o erro Program type already present, que ocorre quando o mesmo tipo de programa (geralmente uma classe de um JAR) é detectado mais de uma vez no classpath da aplicação. Este artigo aborda uma estratégia para mitigar esse problema em cenários de dependência complexos.

Compreendendo o Cenário de Conflito

Considere uma estrutura de projeto Android com dois componentes principais:

1. Um Módulo de Aplicação Principal (Módulo A): Este é o ponto de entrada da sua aplicação. Ele contém um arquivo JAR essencial, digamos x.jar, na sua pasta libs/, e o utiliza diretamente. Por motivos de arquitetura ou controle de equipe, a estrutura ou o conteúdo deste módulo não pode ser alterado.
2. Uma Biblioteca Android (Biblioteca B): Esta biblioteca é desenvolvida e mantida de forma independente, mas é um requisito para o Módulo A. A Biblioteca B também necessita do x.jar para sua funcionalidade.

A hierarquia de dependências é tal que o Módulo A depende da Biblioteca B.

A Manifestação do Erro

Uma abordagem inicial, porém incorreta, seria adicionar uma cópia de x.jar diretamente na pasta libs/ da Biblioteca B e declará-lo como uma dependência ali. Ao tentar compliar o projeto, o processo de build do Android Studio resultará em um erro similar a:

Program type already present: com.google.protobuf.BlockingRpcChannel

Este erro indica que a classe com.google.protobuf.BlockingRpcChannel (ou qualquer outra classe dentro de x.jar) foi encontrada duplicadamente. Isso acontece porque o Módulo A já incluiu x.jar e, ao depender da Biblioteca B, que também tenta incluir uma versão do mesmo JAR, o sistema de build detecta a redundância de tipos.

Restrições e o Desafio

As restrições do cenário complicam a solução padrão de extrair x.jar para um módulo separado, pois o Módulo A não pode ser modificado. Além disso, introduzir uma dependência da Biblioteca B de volta ao Módulo A criaria uma dependência cíclica, o que é inaceitável.

A Solução: Referência Direta ao JAR Existente

A solução reside em garantir que a Biblioteca B não inclua sua própria cópia de x.jar, mas sim referencie a instância já presente no Módulo A. Isso é feito configurando o arquivo build.gradle da Biblioteca B para apontar para o JAR no diretório libs/ do Módulo A.

No arquivo build.gradle da Biblioteca B, adicione a seguinte linha dentro do bloco dependencies:

dependencies {
    // Outras dependências existentes...
    implementation files('../Module A/libs/x.jar')
}

Nesta abordagem, a Biblioteca B é instruída a usar o x.jar que já reside no diretório do Módulo A, em vez de importar uma cópia própria. O caminho ../Module A/libs/x.jar é um caminho relativo que permite que a Biblioteca B acesse o JAR no módulo vizinho.

Esta solução resolve o conflito de tipos porque o JAR é carregado apenas uma vez, a partir da localização especificada no Módulo A, e a Biblioteca B simplesmente "linka" para essa mesma instância. Embora o Android Studio nem sempre ofereça autocompletar para caminhos de arquivo relativos em dependências, essa técnica é eficaz para contornar problemas de duplicação de classes em estruturas modulares com restrições.