109 lines
3.1 KiB
Markdown
109 lines
3.1 KiB
Markdown
# System Services
|
|
|
|
There are many system services
|
|
|
|
- Activity Manager
|
|
- Notification Manager
|
|
- Location Manager
|
|
- …
|
|
|
|
###### `onPause()`
|
|
|
|

|
|
|
|
All the communication is facilitated by `Binder`.
|
|
|
|
### System services and APIs
|
|
|
|
##### Power Management
|
|
|
|
- Lock the device in *awake* power mode
|
|
- Only allow this app to unlock this operation
|
|
|
|
```java
|
|
public class MainActivity extends Activity {
|
|
|
|
private PowerManager.WakeLock wakeLock;
|
|
|
|
@Override
|
|
protected void onCreate(Bundle savedInstanceState) {
|
|
super.onCreate(savedInstanceState);
|
|
|
|
PowerManager pm =
|
|
(PowerManager) getSystemService(Context.POWER_SERVICE);
|
|
wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "My Tag");
|
|
wakeLock.acquire();
|
|
}
|
|
|
|
@Override
|
|
protected void onDestroy() {
|
|
super.onDestroy();
|
|
wakeLock.release();
|
|
}
|
|
}
|
|
```
|
|
|
|
- Connect to the service (Power Manager)
|
|
- Create a unique token
|
|
- This unlocks the phone, can be passed to other components
|
|
|
|
This is what actually happens:
|
|
|
|

|
|
|
|
#### Binder Objects and Tokens
|
|
|
|
###### Binder Object
|
|
|
|
- An object that can be accessed through the binder framework
|
|
- When connected to a service, we're given a binder object back which we use as a proxy for accessing the service.
|
|
- Implements the `IBinder` interface
|
|
- A unique identity maintained across processes
|
|
- **Allocated by the binder driver**
|
|
- Cannot be duplicated. Binder objects maintain a unique ID even when parcelled
|
|
- Is a 32-bit ID maintained by the kernel
|
|
|
|
Process A creates a binder object <- references memory directly
|
|
|
|
> (really asks the Binder driver to allocate it a Binder object for the local object)
|
|
>
|
|
> Passes it to process B <- referenced by handle (ID)
|
|
>
|
|
> - Can then be passed to process C the same way
|
|
|
|
###### Capability-Based security model
|
|
|
|
Processes are granted access to a particular resource by giving them a *capability* in the form of the binder object
|
|
|
|
- Binder object as **token**
|
|
|
|
The possession of a token grants the owning process full access to the Binder object, enabling it to perform Binder transactions on the target object.
|
|
|
|
- The only way to communicate with a Binder object is to be given a reference to it
|
|
|
|
### Service Manager
|
|
|
|
A single context manager that maintains references to (system service) Binder objects
|
|
|
|
- Implemented as a `ServiceManager`
|
|
- Also hosts many system services within its process
|
|
- As the system user. Not root, but a privileged user
|
|
- A Binder instance with a known binder handle (`ID=0`)
|
|
- Knows about other remote services
|
|
- The first to be registered with the Binder
|
|
- Only *trusted* system services allowed to register
|
|
- System, radio, media
|
|
- Binder submits a service name and its Binder handle to the `ServiceManager` via IPC
|
|
- Client retrieves remote service Binder handle with service name
|
|
- Client communicates with remote service
|
|
|
|
When wanting to make use of the power manager, I ask the service manager for the binder handle for that particular service.
|
|
|
|
This means the kernel does not reason about security; however, the service manager does.
|
|
|
|

|
|
|
|

|
|
|
|
|