有些情况，Android的进程管理可以看作为是某种形式的空间交换：程序的进程代表一定数量的（a certain amount of）在用内存；当内存过低时，杀掉一些进程（交换出去）；当又需要那些进程时，它们可以从最后的状态重新启动（交换进来）。
明确地运行在后台
到目前为止，我们有一种不明确的方法令程序运行在后台，就是只要求进程不被Android的内存管理部分杀掉。这对于像在后台加载网页等任务还行，如果有更高的要求怎么样？比如后台播放音乐，数据同步，定位、闹钟等。
对于这些任务，应用程序需要一种途径来告诉Android“我在这一点上要明确的运行”。这里有两种主要的设施可用来为应用程序解决此问题，它们以两种组件为代表，广播和服务，可以在它们的清单中（manifest）注册。
广播接收器
广播接收器允许一个应用程序运行，在短暂的时间里，在后台处理一些发生的事情。它可以用多种途径来构建高级别的设施：例如警告管理器允许程序在未来某个时间发送一个广播，位置管理器可以在发现一个感兴趣的位置变化时发送一个广播。因为接收器的信息是程序清单（manifest）的一部分，Android可以在这个程序没有运行时找到并加载它；当然，如果它的进程在后台可用，广播就可以高效的直接投递给它。
在处理广播时，程序会给定一个允许它工作的时间（当前是10秒钟）。如果在这个时间内没有完成，程序就会被认为是违反规定的（misbehaving），它的进程会立即被扔到（tossed）后台状态，当内存需要时被杀掉。
广播接收器擅长做一些需要响应外部刺激的工作，例如发送一个新的GPS位置报告后给用户发布一个通知。在程序的进程因接收广播而露面后，它们就变成了非常轻量级的。因为它们是再特定的时间活动，有很强的保证在它们运行时进程不会被杀掉。然后这并不适用于（appropriate for）一些不确定时间的情况，如网络。
服务
服务允许应用程序实现长时间的后台操作。当然了，事实上服务也提供了很多其他方法，但这里我们讨论的是服务的最基本目的，一个应用程序说“嗨，我想要持续运行我的程序在后台，直到我说我完成了。”应用程序控制服务的运行，通过明确的启动和停止它。
当服务提供富客户服务器模型时，使用它是可选择的。一旦启动了程序的服务，Android就会实例化这个组件并在程序的进程中提供上下文。在这之后如何使用取决于程序：它可以在服务中放入所有需要的没有和程序的其他部分交互的代码，在其他单例（singleton）对象共享给程序的其他部分调用，直接恢复服务实例在其他需要的地方，或者在另一个进程中运行并在需要时做一个完全的（full-blown）远程过程调用（rpc）。
服务的进程管理与广播接收器的不同，因为不清楚数量的服务可以运行未知长度的时间。这里可能没有足够的RAM来满足服务运行的要求，所以不能够强烈保证它们能够永久运行。
如果只有特别少的RAM，进程维护的服务会像后台进程一样立即被杀掉。然而，如果合适的话，Android会记下那些愿意继续运行的服务，在有足够RAM后再重新启动它们的进程。例如，如果用户使用网页需要大量的RAM，Android会同步的杀掉后台服务进程直到浏览器对内存的需求降低。
服务可以更深层次的讨论它们被认为是“前台”的行为。这里服务就处在一个“请不要杀掉我”的状态，但是这需要它包含一个给用户的积极运行的通知。这对于后台播放音乐或车载导航的服务非常有用，因为用户知道（aware of）这些；当你播放音乐和使用浏览器时，你可以经常在状态栏上看到音乐播放的标记（glyph）。Android不会尝试去杀掉这些服务，不过作为一种交换（trade-off），要保证用户知道它们并且可以在需要时明确的停止。
通用组件的值
Android的通用的广播接收器和服务组件允许开发者创建一个广泛的多种多样的有效后台操作，包括一些最初从没有考虑过的事情。在Android 1.0，它们被用来实现近乎所有内置的后台行为和所有的Google应用：
音乐播放运行在服务中，当用户离开音乐程序时允许继续对其进行操作。
闹钟通过闹钟管理器安排一个广播接收器，在下一次设置时间响起（go off）。
日历程序同样地（likewise）在下一个日历事件中安排一个闹钟在适当时间来显示或更新它的通知。
当进程中有下载时，后台文件下载通过服务来实现。
电子邮件程序安排一个闹钟每隔一段时间或由新邮件到来时来唤醒一个服务。
Google应用程序维护一个服务来接收网络上的通知，并依次（in turn）发送广播给那些需要做工作的单独的程序比如同步联系人。
随着平台的演化，这些基本的组件用来实现很多重要的新的开发特性：
输入法被开发者用服务组件来实现了，Android管理和使用其为当前的输入法。