Instant Apps são um recurso importante do 10, por isso é essencial que funcionem corretamente. Os Instant Apps são instalados implicitamente, portanto, eles têm um conjunto restrito de recursos e são executados em uma caixa de proteção de segurança mais restritiva. Devido à natureza abrangente dessas restrições, qualquer parte do sistema corre o risco de não funcionar corretamente com Instant Apps. Um subconjunto de teste CTS é criado para garantir que os comportamentos permitidos pelos Instant Apps estejam funcionando. A ideia-chave é minimizar o crescimento de tamanho do CTS isolando o conjunto mínimo de testes para transportar. A execução do CTS no modo Instant Apps significa instalar o APK de teste como um Instant App e executar os testes.
Restrições de aplicativos instantâneos
Instant Apps não são instalados pelo usuário, portanto, são executados em um sandbox restrito com as seguintes restrições:
- Pode conter apenas determinadas permissões.
- Não é possível ver outros aplicativos, a menos que esses aplicativos estejam marcados como visíveis para Instant Apps.
- Pode acessar apenas determinadas configurações do sistema.
- Pode acessar apenas determinadas propriedades do sistema.
- Não é possível expor serviços/provedores.
- Pode receber e enviar com regras especiais sobre transmissões.
Além disso, os Instant Apps precisam permitir que a nova caixa de proteção de segurança adicione mais restrições. Essa ampla gama de comportamentos especiais em torno dos Instant Apps abrange toda a plataforma, portanto, deve haver uma maneira de validar se os Instant Apps funcionam conforme o esperado para todos os dispositivos no ecossistema.
Testes em execução no modo Instant Apps
Nem todos os módulos CTS possuem testes aplicáveis a Instant Apps. Se a funcionalidade testada pelo módulo tiver interação com o servidor do sistema, então esses testes devem ser executados no modo Instant Apps. Por exemplo, os testes OpenGL não estão interagindo com o servidor do sistema e, portanto, não há necessidade de executá-los no modo Instant Apps enquanto os testes de acessibilidade interagem com o servidor do sistema, mas é necessário executá-los no modo Instant Apps.
Além de identificar quais módulos são aplicáveis, os usuários precisam determinar quais testes nesses módulos são relevantes. Por exemplo, testar comportamentos específicos de serviço para uma arquitetura conectável (por exemplo, AccessibilityService) não é aplicável ao modo Instant App, pois os Instant Apps não podem expor serviços a outros aplicativos (incluindo a plataforma), enquanto os testes de validação de comportamentos do lado do aplicativo são aplicável ao modo Instant Apps. Outro exemplo é um teste que valida os comportamentos por trás de uma permissão que um Instant App não pode conter não são relevantes no modo Instant App. Há um conjunto de testes que se aplicam apenas a Instant Apps que validam as regras sobre como eles se comportam, por exemplo, não expor serviços ou não ver outros aplicativos. Normalmente, eles já estão escritos e não requerem portabilidade.
Falhas de teste no modo Instant Apps
Se o teste estiver falhando porque valida a funcionalidade que os Instant Apps não podem acessar, então não é aplicável no modo Instant Apps. Marque o teste para executar apenas no modo de aplicativo completo anotando-o com @AppModeFull . Você pode aplicar essa anotação ao nível de classe para excluir todos os testes nele.
Se o teste falhar porque alguma funcionalidade acessível aos Instant Apps está quebrada, registre um bug .
Solução de problemas
Se o seu teste falhar com Failed to install MyCtsModule.apk on DEVICE. Motivo: '-116' , procure mensagens do PackageManager no logcat. Por exemplo, se ele disser que não é possível substituir o aplicativo completo pelo Instant App: your_app , adb desinstale seu aplicativo primeiro.