What is call history manager?

Apps like Tasker and Locale have long been one of the main arguments in the debate between Android and iOS fans. Indeed, ordinary applications that do not require either root or administrator rights, but allow you to create with a smartphone such that any veteran of Linux scripting will envy. How do they work and why are there no similar applications in iOS and other mobile systems? It's all about Binder, the IPC / RPC engine that runs throughout Android.

Instead of introducing

The creators of Android, having the opportunity to think over the architecture of the OS from scratch, taking into account modern realities, naturally decided to isolate the installed applications from each other. This is how the idea of ​​using sandboxes appeared, so the Android application: a) has access only to its own directory and (if there is such authority) to the SD card - a dump of junk that does not contain important data, b) can only use the pre-specified OS capabilities (a in Android 6.0, the user can revoke such permissions right while the program is running) and c) does not have the right to launch, create communication channels or call methods of other applications.

This is all implemented with the help of standard file permissions (in Android, each application runs with the rights of a Linux user created specifically for it), numerous checks for access permissions to OS resources at all levels up to the kernel and launching each application in its own virtual machine ( now it has already been replaced by ART, but this does not change the essence): https://callgear.com/vpbx/call-logs-and-data/.

All these mechanisms work fine and perform their functions, but there is one problem: if applications are completely cut off from each other, up to execution on behalf of different users, then how should they communicate and how they should interact with more privileged system services, which are the same applications? The answer to this question is the system of messages and procedure calls Binder, one of the many finds of the creators of the legendary BeOS, which migrated to Android.

Binder is similar to the COM mechanism found in Windows, but permeates the system inside and out. In fact, the entire high-level part of Android is based on Binder, allowing system components and applications to exchange data and transfer control to each other, clearly controlling the authority of the components to interact. Binder is used for interaction of applications with the graphics subsystem, with its help, applications start and stop, applications "communicate" with system services. Binder is used even when you launch a new activity or service inside your application, and by default the service runs in the same process as the main part of the application, but it is very easy to move it into a separate process by simply adding one line to the manifest. Everything will work as before, and thanks to Binder.

This may seem a little strange to you, and perhaps this is the first time you hear about some kind of magical Binder, but this is due to the fact that Android abstracts the programmer from direct communication with this driver (yes, it is implemented in the kernel and is controlled using the / dev / binder). But you were definitely dealing with intents, an abstract entity built on top of Binder.

Magic intents

In Android, an object of the Intent class is an abstraction of the Binder message and, by and large, is a way to transfer control to the components of your own or someone else's application, regardless of whether the application to which this component belongs is running or not.