Lines Matching defs:Instrumentation
59 * Base class for implementing application instrumentation code. When running
60 * with instrumentation turned on, this class will be instantiated for you
62 * interaction the system has with the application. An Instrumentation
64 * <instrumentation> tag.
66 public class Instrumentation {
79 * instrumentation can also be launched, and results collected, by an automated system.
83 private static final String TAG = "Instrumentation";
109 public Instrumentation() {
113 * Called when the instrumentation is starting, before any application code
115 * {@link #start} to begin the instrumentation thread, which will then
119 * instrumentation to be completely asynchronous (returning to the event
121 * instrumentation here, for example call {@link Context#startActivity} to
125 * instrumentation was started.
131 * Create and start a new thread in which to run instrumentation. This new
133 * instrumentation.
137 throw new RuntimeException("Instrumentation already started");
144 * Method where the instrumentation thread enters execution. This allows
145 * you to run your instrumentation code in a separate thread than the
150 * to end your instrumentation.
176 * @param resultCode Current success/failure of instrumentation.
177 * @param results Any results to send back to the code that started the instrumentation.
191 * Terminate instrumentation of the application. This will cause the
192 * application process to exit, removing this instrumentation from the next
195 * @param resultCode Overall success/failure of instrumentation.
197 * instrumentation.
241 * Return the Context of this instrumentation's package. Note that this is
243 * instrumentated, since the instrumentation code often lives is a
248 * @return The instrumentation's package context.
257 * Returns complete component name of this instrumentation.
259 * @return Returns the complete component name for this instrumentation.
267 * that this is often different than the Context of the instrumentation
268 * code, since the instrumentation code often lives is a different package
270 * {@link #getContext} to retrieve a Context for the instrumentation code.
281 * Check whether this instrumentation was started with profiling enabled.
292 * manifest file for this Instrumentation to true.
313 * your instrumentation relies on the UI being in one more or the other
343 * instrumentation in its own thread.
432 * current instrumentation through {@link #addMonitor}; after being added,
448 // This is protected by 'Instrumentation.this.mSync'.
465 * @see Instrumentation#addMonitor
486 * @see Instrumentation#addMonitor
587 true, "Instrumentation") < 0) {
1017 * Often instrumentation tests start their test thread in onCreate(); you
1849 * work across application boundaries while the APIs exposed by the instrumentation
1850 * do not. For example, {@link Instrumentation#sendPointerSync(MotionEvent)} will
1851 * not allow you to inject the event in an app different from the instrumentation
1857 * {@link Instrumentation} APIs. Using both APIs at the same time is not
1876 * work across application boundaries while the APIs exposed by the instrumentation
1877 * do not. For example, {@link Instrumentation#sendPointerSync(MotionEvent)} will
1878 * not allow you to inject the event in an app different from the instrumentation
1884 * {@link Instrumentation} APIs. Using both APIs at the same time is not
1926 Log.w(TAG, "Exception setting priority of instrumentation thread "
