Home | History | Annotate | Download | only in app

Lines Matching defs:Instrumentation

53  * Base class for implementing application instrumentation code.  When running
54 * with instrumentation turned on, this class will be instantiated for you
56 * interaction the system has with the application. An Instrumentation
58 * <instrumentation> tag.
60 public class Instrumentation {
73 * instrumentation can also be launched, and results collected, by an automated system.
77 private static final String TAG = "Instrumentation";
95 public Instrumentation() {
99 * Called when the instrumentation is starting, before any application code
101 * {@link #start} to begin the instrumentation thread, which will then
105 * instrumentation to be completely asynchronous (returning to the event
107 * instrumentation here, for example call {@link Context#startActivity} to
111 * instrumentation was started.
117 * Create and start a new thread in which to run instrumentation. This new
119 * instrumentation.
123 throw new RuntimeException("Instrumentation already started");
130 * Method where the instrumentation thread enters execution. This allows
131 * you to run your instrumentation code in a separate thread than the
136 * to end your instrumentation.
162 * @param resultCode Current success/failure of instrumentation.
163 * @param results Any results to send back to the code that started the instrumentation.
177 * Terminate instrumentation of the application. This will cause the
178 * application process to exit, removing this instrumentation from the next
181 * @param resultCode Overall success/failure of instrumentation.
183 * instrumentation.
224 * Return the Context of this instrumentation's package. Note that this is
226 * instrumentated, since the instrumentation code often lives is a
231 * @return The instrumentation's package context.
240 * Returns complete component name of this instrumentation.
242 * @return Returns the complete component name for this instrumentation.
250 * that this is often different than the Context of the instrumentation
251 * code, since the instrumentation code often lives is a different package
253 * {@link #getContext} to retrieve a Context for the instrumentation code.
264 * Check whether this instrumentation was started with profiling enabled.
275 * manifest file for this Instrumentation to true.
296 * your instrumentation relies on the UI being in one more or the other
326 * instrumentation in its own thread.
415 * current instrumentation through {@link #addMonitor}; after being added,
431 // This is protected by 'Instrumentation.this.mSync'.
448 * @see Instrumentation#addMonitor
469 * @see Instrumentation#addMonitor
570 true, "Instrumentation") < 0) {
1000 * Often instrumentation tests start their test thread in onCreate(); you
1660 * work across application boundaries while the APIs exposed by the instrumentation
1661 * do not. For example, {@link Instrumentation#sendPointerSync(MotionEvent)} will
1662 * not allow you to inject the event in an app different from the instrumentation
1668 * {@link Instrumentation} APIs. Using both APIs at the same time is not
1695 Log.w(TAG, "Exception setting priority of instrumentation thread "