What Exactly Is the Job of an Operating System?
Well, as the name states, it operates the entire system, and by ‘operate the entire system’ we mean the device that it is running on, in this case, the Android device. So you can really think of an OS as a conductor that makes sure that all the components, both hardware and software, that the device consists of, work together smoothly. It is really just a bridge between hardware and software.
To give you a clearer technical understanding of what all this means at a lower level, let’s walk through the specific roles an operating system plays.
-
Process and Thread Management: It is the job of the operating system to decide which thread runs, when which thread runs, and to make sure that multiple applications can work efficiently together, even in parallel.
-
Memory Management: An Android device has a specific amount of RAM, and deep down in the RAM, we have a big amount of storage space where we can just write 1s and 0s. It is important in such a device to have clear boundaries of which memory belongs to what process, for example. So that one app does not accidentally override the RAM in the memory usage of another app, which would definitely lead to issues.
Memory management on Android specifically has a kind of special role, because on mobile devices, resources are just typically a bit more scarce than on servers and better devices like desktops, etc., where we have a consistent power supply, while on an Android device, we have a battery, which typically don’t have that much memory available as on these larger devices. So the Android OS specifically also always needs to make sure that there’s always enough memory for what the user wants to do, for example, killing apps that are not frequently used or that the user will probably not use again. This internal logic to decide what should be done if a lot of the memory is used is a part of the operating system.
-
File Handling and I/O Operations: Another job of the operating system is handling the file system and I/O operations (writing to files and reading from files). This is a good example of how the operating system acts as a bridge between hardware and software. The hardware is just a disk where we persistently write data to, and the software is then maybe our app, where we can use high-level APIs to easily write data to disk.
-
Security and Permissions: No matter what kind of operating system you are running, there will be some sort of security and permission set up, which will just make sure that it enforces strict boundaries to protect core functionalities of the OS, so that our app can’t suddenly break the functioning of the operating system itself and therefore potentially destroy how the entire workings of the device are like, but also things like protecting user’s data.
This is important on Android devices because they have access to the camera, microphone, sensor data, and GPS, which is, of course, data that has to be protected. Of course, certain apps need to access that data, but many apps clearly don’t. The operating system needs to make sure that there are clear permissions for accessing such sensitive data.
You’ll know this from Android, where we always have those permission dialogues that the user has to grant a certain permission, like accessing the camera. These kinds of permissions are managed by the operating system because our apps don’t really have access to them.
-
Hardware Abstraction Layer (HAL): The OS is a bridge between hardware and software, as earlier stated, but interacting with the hardware itself is, in the en,d a super low-level thing. Our Android device may be made out of a lot of different components, the camera might be from manufacturer A, the microphone from manufacturer B, and then all those different hardware components are manufactured together to a working Android device. But each hardware manufacturer decides how their certain hardware is programmed, and how other components need to interact with it, this is, in the en,d what a hardware driver does.
This low-level interaction of controlling a device’s hardware is something we developers typically don’t need to deal with in our day-to-day work, so the operating system would abstract that away from us, which is the hardware abstraction layer, and then provide very high-level accessible APIs to us developers that we can easily use. An important example of this is a network interface where you and your app can just make an HTTP request by using a library such as Retrofit or Ktor. But that’s, of course, not how things work on a lower level.
On a lower level, all those HTTP calls have to be transformed into some sequence of zeros and ones, with clear boundaries that the zeros and ones still contain where they will be sent to, the actual data, and all kids of metadata around that, which are then being sent to the device’s network chip and then distributed.
-
UI Management: All Android devices, of course has a user interface (UI) that a user interacts with; that is not something all operating systems need to do. There are lots of Linux instances running on servers that do not have an actual UI, where you just interact with a pure terminal.
The touchscreen is of course also a hardware component that needs to transform the user’s touches into clear coordinations on the screen, into forwarding this information to the app that is currently running, so we can process that input, but also making sure that UI can be rendered on the screen, that there is a rendering pipeline, that we can draw multiple layers on our app.
On Android specifically, that includes notifications, so that no matter where we are on our device, we will always get a pop-up for a notification. UI management on Android may also include navigation between multiple apps.
So you see that there are lots of different jobs and purposes of an operating system that we typically don’t even think about in our day-to-day work. With this overview, we will be diving into those aspects of the Android OS Architecture that actually have practical relevance for our typical work-life.