A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Primeiro, leia Testar seu app
em developer.android.com. Observe que há algumas diferenças em
como os testes de instrumentação são usados nos testes de plataforma.
Em resumo, um teste de instrumentação fornece um ambiente especial de execução
de teste lançado pelo comando am instrument, em que o processo do aplicativo
alvo é reiniciado e inicializado com o contexto básico do aplicativo,
e uma linha de execução de instrumentação é iniciada dentro da VM do processo do aplicativo. O
código de teste inicia a execução nessa linha de execução de instrumentação e é fornecido com
uma instância Instrumentation que fornece acesso ao contexto do aplicativo
e às APIs para manipular o processo do aplicativo em teste.
Principais conceitos
uma instrumentação precisa ser declarada em um pacote de app, com uma tag
<instrumentation>
anexada à tag <manifest> do manifesto do pacote de app.
Tecnicamente, um manifesto de pacote de aplicativo pode conter várias
tags <instrumentation>, embora não seja comumente usado dessa maneira.
Cada <instrumentation> precisa conter:
um atributo android:name: precisa ser o nome de uma subclasse de
Instrumentation
incluída no aplicativo de teste, que normalmente é o executor
de teste que está sendo usado, por exemplo:
android.support.test.runner.AndroidJUnitRunner
um atributo android:targetPackage precisa ser definido. O valor precisa
ser definido como o pacote do aplicativo em teste.
Resumo das etapas
Confira abaixo os destinos comuns para testes herméticos em relação aos serviços de framework:
Siga a convenção atual se você estiver adicionando testes a um dos
locais acima. Se você estiver configurando um novo módulo de teste, siga a
configuração de AndroidManifest.xml e Android.mk em um dos locais
acima.
adb shell am instrument -w -e class \
android.animation.AnimatorSetEventsTest \
com.android.frameworks.coretests\
/android.support.test.runner.AndroidJUnitRunner
um método de teste específico
adb shell am instrument -w -e class \
android.animation.AnimatorSetEventsTest#testCancel \
com.android.frameworks.coretests\
/android.support.test.runner.AndroidJUnitRunner
O teste pode fazer uma declaração explícita sobre aprovação ou reprovação usando APIs JUnit.
Além disso, qualquer exceção não detectada também causa uma falha funcional.
Para emitir métricas de performance, o código de teste pode chamar
Instrumentation#sendStatus
para enviar uma lista de pares de chave-valor. É importante observar que:
as métricas podem ser números inteiros ou de ponto flutuante
Todos os valores não numéricos serão descartados
O APK de teste pode ser de testes funcionais ou de métricas, mas
não há suporte para a mistura de ambos no momento.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-27 UTC."],[],[],null,["# Instrumentation tests\n\nFirst read [Test your app](https://developer.android.com/studio/test/)\non developer.android.com. Take note there are some differences in\nhow instrumentation tests are used in platform testing.\n\nIn summary, an instrumentation test provides a special test execution\nenvironment as launched via the `am instrument` command, where the targeted\napplication process is restarted and initialized with basic application context,\nand an instrumentation thread is started inside the application process VM. Your\ntest code starts execution on this instrumentation thread and is provided with\nan `Instrumentation` instance that provides access to the application context\nand APIs to manipulate the application process under test.\n\nKey concepts\n------------\n\n- an instrumentation must be declared in an application package, with an [`\u003cinstrumentation\u003e`](https://developer.android.com/guide/topics/manifest/instrumentation-element.html) tag nested under the `\u003cmanifest\u003e` tag of the application package manifest.\n- an application package manifest may technically contain multiple `\u003cinstrumentation\u003e` tags, though it's not commonly used in this fashion.\n- each `\u003cinstrumentation\u003e` must contain:\n - an `android:name` attribute: it should be the name of a subclass of [`Instrumentation`](https://developer.android.com/reference/android/app/Instrumentation.html) that's included in the test application, which is typically the test runner that's being used, e.g.: `android.support.test.runner.AndroidJUnitRunner`\n - an `android:targetPackage` attribute must be defined. Its value should be set to the application package under test.\n\nSummary of steps\n----------------\n\n1. Below are common destinations for hermetic tests against framework services:\n\n frameworks/base/core/tests/coretests\n frameworks/base/services/tests/servicestests\n\n If you are adding a brand new instrumentation module for your component, see\n - [Self-Instrumenting Tests: A Complete Example](/docs/core/tests/development/instr-self-e2e)\n - [Instrumentation Targeting an Application: A Complete Example](/docs/core/tests/development/instr-app-e2e)\n2. Following the existing convention if you are adding tests into one of the\n locations above. If you are setting up a new test module, please follow the\n setup of `AndroidManifest.xml` and `Android.mk` in one of the locations\n above\n\n3. See\n [frameworks/base/core/tests/coretests/](https://android.googlesource.com/platform/frameworks/base.git/+/android16-release/core/tests/coretests/)\n for an example.\n Note these lines install extra apps:\n\n \u003coption name=\"test-file-name\" value=\"FrameworksCoreTests.apk\" /\u003e\n \u003coption name=\"test-file-name\" value=\"BstatsTestApp.apk\" /\u003e\n\n4. Do not forget to mark your test as `@SmallTest`, `@MediumTest` or\n `@LargeTest`\n\n5. Build the test module with m, e.g.:\n\n m FrameworksCoreTests\n\n6. Run the tests:\n\n - The simplest solution is to use\n [Atest](/docs/core/tests/development/atest) like so:\n\n atest FrameworksCoreTests\n\n - Or for more complex tests, use the\n [Trade Federation test Harness](/docs/core/tests/tradefed):\n\n m tradefed-all\n tradefed.sh run template/local_min --template:map test=FrameworksCoreTests\n\n7. If not using Tradefed, manually install and run the tests:\n\n 1. Install the generated apk:\n\n adb install -r ${OUT}/data/app/FrameworksCoreTests/FrameworksCoreTests.apk\n\n | **Tip:** you use `adb shell pm list instrumentation` to find the instrumentations inside the apk just installed\n 1. Run the tests with various options:\n\n 1. all tests in the apk\n\n adb shell am instrument -w com.android.frameworks.coretests\\\n /android.support.test.runner.AndroidJUnitRunner\n\n 2. all tests under a specific Java package\n\n adb shell am instrument -w -e package android.animation \\\n com.android.frameworks.coretests\\\n /android.support.test.runner.AndroidJUnitRunner\n\n 3. all tests under a specific class\n\n adb shell am instrument -w -e class \\\n android.animation.AnimatorSetEventsTest \\\n com.android.frameworks.coretests\\\n /android.support.test.runner.AndroidJUnitRunner\n\n 4. a specific test method\n\n adb shell am instrument -w -e class \\\n android.animation.AnimatorSetEventsTest#testCancel \\\n com.android.frameworks.coretests\\\n /android.support.test.runner.AndroidJUnitRunner\n\nYour test can make an explicit assertion on pass or fail using `JUnit` APIs; in\naddition, any uncaught exceptions will also cause a functional failure.\n\nTo emit performance metrics, your test code can call\n[`Instrumentation#sendStatus`](http://developer.android.com/reference/android/app/Instrumentation.html#sendStatus(int,%20android.os.Bundle))\nto send out a list of key-value pairs. It's important to note that:\n\n1. metrics can be integer or floating point\n2. any non-numerical values will be discarded\n3. your test apk can be either functional tests or metrics tests, however mixing both are not currently supported"]]
