Os Instant Apps são um recurso chave do 10, por isso é essencial que funcionem corretamente. Os Instant Apps são instalados implicitamente, portanto, têm um conjunto restrito de recursos e são executados em um sandbox de segurança mais restritivo. Devido à natureza generalizada dessas restrições, qualquer parte do sistema corre o risco de não funcionar corretamente com os Instant Apps. Um subconjunto de teste CTS é criado para garantir que os comportamentos permitidos pelos Instant Apps estejam funcionando. A ideia principal é minimizar o crescimento do tamanho do CTS isolando o conjunto mínimo de testes para a porta. O CTS executado no modo Instant Apps significa instalar o APK de teste como um Instant App e executar os testes.
Restrições de aplicativos instantâneos
Os Instant Apps não são instalados pelo usuário, então eles 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 pode expor serviços/provedores.
- Pode receber e enviar com regras especiais em torno de transmissões.
Além disso, os Instant Apps precisam permitir que o novo sandbox de segurança adicione mais restrições. Essa ampla variedade de comportamentos especiais em torno dos Instant Apps abrange toda a plataforma, portanto, é preciso 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 aos Instant Apps. Se a funcionalidade testada pelo módulo tiver interação com o servidor do sistema, esses testes devem ser executados no modo Instant App. 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 App enquanto os testes de acessibilidade interagem com o servidor do sistema, mas é necessário executá-los no modo Instant App.
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 do 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 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 aos 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
Se o teste falhar porque valida a funcionalidade que os Instant Apps não podem acessar, ele não é aplicável no modo Instant App. Marque o teste para ser executado apenas no modo Full App anotando-o com @AppModeFull . Você pode aplicar esta anotação ao nível de classe para excluir todos os testes nela.
Se o teste falhar porque alguma funcionalidade acessível aos Instant Apps está quebrada, registre um bug .
Solução de problemas
Se seu teste falhar com Failed to install MyCtsModule.apk no DEVICE. Motivo: '-116' , procure mensagens do PackageManager no logcat. Por exemplo, se disser Não é possível substituir o aplicativo completo pelo aplicativo instantâneo: seu_aplicativo , o adb desinstale seu aplicativo primeiro.