Veja por que você não pode fazer o sideload de atualizações para a Câmera e o Gravador do Google

click fraud protection

Se você viu um erro de “falha na verificação” ao transferir uma atualização para os aplicativos Câmera ou Gravador do Google, leia isto para descobrir o motivo.

Quando o Google lançou o Pixel 5 em outubro, ficamos entusiasmados em colocar as mãos em seus novos aplicativos. (O próprio telefone é muito legal, também.) Com o lançamento do Pixel 5 vieram novas versões de a Câmera do Google e Gravador Google aplicativos que compartilhamos com a comunidade. No entanto, quando muitos usuários de dispositivos Pixel mais antigos tentaram fazer o sideload das atualizações, encontraram um erro (mostrado acima). Estranhamente, nem todos tiveram problemas com a instalação das atualizações. Alguns conseguiram instalá-los perfeitamente, enquanto outros tiveram que redefinir os padrões de fábrica apenas para poder instalar as novas versões. Devido à natureza aparentemente aleatória desse problema, muitos o consideraram um bug. Estamos bastante confiantes agora de que esse problema não se origina de um bug, mas sim do uso de uma nova API pelo Google no Android 11 para bloquear o carregamento lateral de atualizações.

Se você tentar fazer o sideload do Google Camera 8.0 ou posterior ou do Google Recorder 2.0 ou posterior em um dispositivo Pixel com Android 11, você verá uma mensagem de erro informando que a verificação não foi bem-sucedida. Mesmo se você tentar fazer o sideload do APK usando um comando shell, não obterá um motivo mais específico para a falha na instalação. O código de retorno da instalação que você receberá é "INSTALL_FAILED_VERIFICATION_FAILURE", o que infelizmente não explica por que a verificação não foi bem-sucedida. Examinando o logcat, podemos saber exatamente por que a verificação falha:

AppIntegrityManagerServiceImpl: Integritycheckofcom.google.android.GoogleCameraresult: DENYdueto[Rule: (PACKAGE_NAME EQ com.google.android.GoogleCamera) AND (VERSION_CODE GTE 32045130) AND (APP_CERTIFICATE EQ F0FD6C5B410F25CB25C3B53346C8972FAE30F8EE7411DF910480AD6B2D60DB83) AND NOT (INSTALLER_NAME EQ com.android.vending), DENY]

De acordo com esta mensagem, uma verificação de integridade da instalação da Câmera do Google falhou porque “INSTALLER_NAME” não correspondia a “com.android.vending”, o nome do pacote da Google Play Store. (Eu estava tentando instalar o Google Camera 8.0 usando o aplicativo APKMirror Installer, pelo que vale a pena.) Esta mensagem foi adicionada ao log do sistema por "AppIntegrityManagerServiceImpl", que faz parte do novo recurso "App Integrity" do Android. De acordo com o código no AOSP, o App Integrity foi projetado para fornecer uma camada adicional de verificações além da verificação de assinatura APK existente do gerenciador de pacotes. A API App Integrity parece usar um conjunto de Regras para decidir se permite ou não a instalação. As regras são fornecidas por um aplicativo do sistema – que acreditamos ser o Google Play Services – e são armazenado em um arquivo.

Além disso, integridade de aplicativos também liga outra classe chamada SourceStampVerifier se um "selo de origem" estiver incorporado nos metadados do Manifesto. Por exemplo, aqui está o que acreditamos ser o “selo de origem” do manifesto do aplicativo Câmera do Google:

<meta-dataandroid: name="com.android.stamp.source"android: value="https://play.google.com/store"/>

Pelo que podemos dizer, o carimbo de origem é usado para verificar a assinatura do instalador do pacote. Então, por exemplo, você não pode enganar o AppIntegrity para permitir a instalação, mesmo se você falsificou a Play Store como o instalador.

Além disso, não conseguimos descobrir exatamente como o Google está usando o AppIntegrity e APIs relacionadas para bloquear o carregamento lateral de atualizações para os aplicativos Google Camera e Google Recorder. Um rápido exame do APK do Google Play Services revela que ele está usando essas APIs, mas o código está muito ofuscado para realmente entender tudo. Até encontramos o diretório onde as regras de integridade estão armazenadas — /data/system/integrity_rules — mas foi de pouca utilidade porque contém apenas dados serializados. Também não encontramos uma maneira de desabilitar a verificação de integridade (não parece ser tão fácil quanto simplesmente alterando uma configuração), embora acreditemos que o motivo pelo qual a redefinição de fábrica funciona para alguns é que o Google Play Services não tem a chance de inicializar seu conjunto de regras para bloquear a instalação. A mensagem do logcat e a introdução dessas novas APIs no Android 11 sugerem fortemente que tudo isso é intencional e não um bug.

O Google não comentou publicamente sobre o uso dessas APIs (nem esperamos que o façam) e não respondeu quando contatado para comentar. No entanto, temos algumas teorias sobre por que eles estão bloqueando atualizações transferidas. Primeiro, eles poderiam proteger as pessoas de instalar a versão errada do aplicativo em seus dispositivos. O Google oferece versões específicas de seus aplicativos para dispositivos Pixel específicos. Por exemplo, várias versões do aplicativo Device Personalization Services podem ser encontradas online. Embora todos possam ser instalados em dispositivos Pixel, em determinado momento foi possível perder o recurso Live Captions no Pixel 4 baixando uma versão desenvolvida para um dispositivo Pixel mais antigo. Outro motivo poderia ser “melhorar a rastreabilidade de aplicativos em relação à distribuição não autorizada”, conforme explicado pelo Google na classe SourceStampVerifier.

Até agora, apenas alguns aplicativos do Google que usam o formato de pacote de aplicativos (como Google Camera e Google Recorder) são bloqueando instalações que não sejam da Play Store, mas não sabemos se a empresa estenderá esse comportamento a seus outros aplicativos assim que todos mudarem para o formato AAB. Também consideramos se a mudança para pacotes de apps exigia a implementação do App Integrity, mas descobrimos que o Google já tem uma solução para lidar quando os usuários tentam instalar um aplicativo que não possui todas as divisões necessárias. Seja qual for o caso, não acreditamos que o Google pretenda bloquear todo o sideload de seus aplicativos, embora essas ferramentas certamente permitam que isso seja feito.

Obrigado aos desenvolvedores vvb2060, aviraxp e Quinny899 pela assistência neste artigo e tobrigado à PNF Software por nos fornecer uma licença para usar Descompilador JEB, uma ferramenta de engenharia reversa de nível profissional para aplicativos Android.