Lines Matching refs:that
8 <li>Every application runs in its own process and all components of the application run in that
37 for that application (because another component from the application exists), then the component is
38 started within that process and uses the same thread of execution. However, you can arrange for
48 should not change this. However, if you find that you need to control which process a certain
56 <provider>}</a>—supports an {@code android:process} attribute that can specify a
57 process in which that component should run. You can set this attribute so that each component runs
58 in its own process or so that some components share a process while others do not. You can also set
59 {@code android:process} so that components of different applications run in the same
60 process—provided that the applications share the same Linux user ID and are signed with the
65 default value that applies to all components.</p>
68 other processes that are more immediately serving the user. Application
69 components running in the process that's killed are consequently destroyed. A process is started
73 the user. For example, it more readily shuts down a process hosting activities that are no longer
75 terminate a process, therefore, depends on the state of the components running in that process. The
95 <p>A process that is required for what the user is currently doing. A
99 <li>It hosts an {@link android.app.Activity} that the user is interacting with (the {@link
103 <li>It hosts a {@link android.app.Service} that's bound to the activity that the user is
106 <li>It hosts a {@link android.app.Service} that's running "in the foreground"—the
109 <li>It hosts a {@link android.app.Service} that's executing one of its lifecycle
113 <li>It hosts a {@link android.content.BroadcastReceiver} that's executing its {@link
118 a last resort—if memory is so low that they cannot all continue to run. Generally, at that
123 <p>A process that doesn't have any foreground components, but still can
128 <li>It hosts an {@link android.app.Activity} that is not in the foreground, but is still
133 <li>It hosts a {@link android.app.Service} that's bound to a visible (or foreground)
142 <p>A process that is running a service that has been started with the {@link
145 are generally doing things that the user cares about (such as playing music in the background or
151 <p>A process holding an activity that's not currently visible to the user (the activity's
156 in an LRU (least recently used) list to ensure that the process with the activity that was most
166 <p>A process that doesn't hold any active application components. The only reason to keep this
179 it—a process that is serving another process can never be ranked lower than the process it is
185 an activity that initiates a long-running operation might do well to start a <a
186 href="{@docRoot}guide/components/services.html">service</a> for that operation, rather than
188 For example, an activity that's uploading a picture to a web site should start a service to perform
189 the upload so that the upload can continue in the background even if the user leaves the activity.
190 Using a service guarantees that the operation will have at least "service process" priority,
191 regardless of what happens to the activity. This is the same reason that broadcast receivers should
207 components that run in the same process are instantiated in the UI thread, and system calls to
208 each component are dispatched from that thread. Consequently, methods that respond to system
214 the event queue. The UI thread dequeues the request and notifies the widget that it should redraw
240 application's UI that you do not block the UI thread. If you have operations to perform
241 that are not instantaneous, you should make sure to do them in separate threads ("background" or
244 <p>For example, below is some code for a click listener that downloads an image from a separate
265 threads. Here is a list of methods that can help:</p>
300 which simplifies the execution of worker thread tasks that need to interact with the UI.</p>
341 part that should be done on a worker thread and the part that should be done on the UI thread.</p>
376 <p>This is primarily true for methods that can be called remotely—such as methods in a <a
381 a pool of threads that the system maintains in the same process as the {@link android.os.IBinder
384 service's process, methods implemented in the object that {@link android.app.Service#onBind
385 onBind()} returns (for example, a subclass that implements RPC methods) would be called from threads
390 <p> Similarly, a content provider can receive data requests that originate in other processes.
393 android.content.ContentProvider} methods that respond to those requests—the methods {@link