Android application architecture. Part I - the origins
In this article we will look at the architecture of Android applications.
Frankly, I find the official Google article on this topic not very useful. Responding in detail to the question “how”, she doesn’t explain at all what and why. So, here is my version, and I hope it will bring some clarity. Yes, by the way, I fully approve of reading Google articles, because they contain useful information, which I do not intend to repeat.
As is often the case in IT, many things cannot be explained in isolation from the history of the emergence of specific software. That is why we must turn to the origins of the Android OS.
The development of the Android OS was launched in 2003 by the young company Android Inc. In 2005, this company was bought by Google. I believe that the main features of the Android architecture were identified during this period. This is not only the credit of Android Inc; Google’s architectural concepts and financial resources have had a decisive influence on Android’s architecture. Next I will give a few examples.
')
If you remember, 2003-2005 was marked by increased attention to AJAX applications. I think this had a fundamental impact on the architecture of Android: in many aspects it is closer to the architecture of a typical AJAX application than to the desktop GUI application written in Java, C #, C ++, VB, and so on.
I do not know why it happened. My guess was someone from Google invented at a time when rich Internet applications (Rich Internet Applications, RIA) in the spirit of Google Docs or Gmail were considered to be the solution to all problems. In my opinion, this idea can not be called neither good nor bad. Just remember that Android applications are very different from desktop ones.
The influence of the architectural philosophy of Eclipse is noticeable in choosing the principle of GUI implementation, which is more like SWT than Swing.
In the standards for the design of the Android code there is a “Hungarian notation”, born within the walls of MS. It can be assumed that the person who wrote these standards was previously engaged in the development under Windows.
The Android operating system has three very different and highly separated levels:
Consider these layers one by one and in more detail.
Imagine that you are an architect in a young company. You must develop an OS for a new type of device. What are you going to do?
Roughly speaking, you have two ways: to implement your own ideas, starting from scratch, or use the existing OS and adapt it to your devices.
Implementing from scratch always sounds exciting to programmers. At these moments, we all believe that this time we will do everything better than others do, and even better than we ourselves did before.
However, this is not always practical. For example, the use of the Linux kernel has significantly reduced the cost of development (perhaps somewhere already excessively large). Agree, if someone decides to create something resembling the Linux kernel in its current state, it will need several million dollars.
If you are in charge of Android Inc, then by definition you cannot have that much money. If you run Google, then you will find that kind of money, but you will most likely think twice before spending it on creating your own OS. You will also spend several years before you reach the current state of Linux; several years of delay may be too late to enter the market.
In this situation, Apple decided to build a Mac OS based on Free BSD. Android Inc decided to use Linux as the basis for Android. Both BSD and Linux sources are freely available and provide a good basis for any development, be it Apple or Google.
But at that time it was impossible to launch standard Linux on a mobile device (now this is not the case). The devices had too little RAM and non-volatile memory. The processors were significantly slower compared to the processors of computers where Linux is commonly used. As a result, Android developers decided to minimize Linux system requirements.
If you look at Linux at a high level, then this is a combination of the kernel (which you can't do without) and many other optional parts. You can even run one core, without anything else. So, Google is forced in any case to use the Linux kernel as part of the Android OS. In addition, optional parts were considered and the most necessary were selected. For example, the IPTables network firewall and the Ash shell were added. It is curious that it was Ash who was added, not Bash, despite the fact that the latter is an order of magnitude more powerful; this decision was probably based on the fact that Ash is less resource intensive.
Android developers have modified the Linux kernel, adding support for hardware used in mobile devices and, more often, inaccessible on computers.
The choice of Linux as the basis had a huge impact on all aspects of the Android OS. Building Android, in fact, is a variation of the Linux build process. The Android code is under the control of git (a tool developed to manage Linux code). And so on.
Let it all be interesting, but you will most likely never touch all these specific moments until your goal is to develop Android applications. The only exception may be a review of the file system using the ash commands. The main thing that you should know when developing applications for Android is the level of application infrastructure.
You may ask how to be if you need to develop a native Android application? Google strongly discourages doing this. Technically, of course, this is possible, but in the future you will not be able to distribute this application in the normal way. So think twice before starting native Android development, unless of course you are working on the Android Open Source Project (AOSP), i.e. Android OS itself.
Despite some similarities between Apple iOS and Android OS, there are significant differences between the architectural solutions on the infrastructure level of both OSs.
Apple decided to use Objective-C as a programming language and iOS application runtime. Objective-C looks like a more or less natural choice for an OS based on Free BSD. You can think of Objective-C as regular C ++ with a custom preprocessor that adds some specific linguistic constructs. Why it is impossible to use standard C ++ on which Free BSD is written? I think the reason is that Apple is trying to do everything in its “Apple” style.
The basic idea is that iOS applications are written more or less in the same language as the OS behind them.
Android applications are very different in that sense. They are written in Java, and this is a completely different technology than C ++ (although the syntax is inherited from C ++).
Why is this so? Why, for example, Android applications are not written in C ++? From Google, I did not find any explanation, so I can only share my own thoughts.
I think the main reason is that the same application needs to work on different hardware. This problem only occurs for the Android OS; The guys from Apple have no such problem. iOS only works on its own production equipment, and Apple fully controls the entire process. For Android, the opposite is true: Google does not control hardware manufacturers. For example, the Android OS runs on x86, ARM and Atom processors (in the comments, x86 includes Atom, and Android runs on x86, ARM, PPC and MIPS - translator's note ). At the binary level, these architectures are incompatible.
If the architects of the Android OS chose the same path as the architects from Apple, Android developers would have to distribute several versions of the same application at the same time. This would be a serious problem that could lead to the collapse of the entire Android project.
In order for the same application to work on different hardware, Google used container-based architecture. In this architecture, the binary code is executed by a software container and is isolated from the details of the specific hardware. Examples are familiar to all - Java and C #. In both languages, the binary code does not depend on the specific hardware and is executed by the virtual machine.
Of course, there is another way to achieve hardware independence at the binary code level. As one option, you can use a hardware emulator, also known as QEMU . It allows you to emulate, for example, a device with an ARM processor on the x86 platform and so on. Google could use C ++ as a language for developing applications inside emulators. Indeed, Google uses this approach in its Android emulators, which are based on QEMU.
It is very good that they did not follow this path, because then someone would have to run the OS on an emulator, which requires much more resources, and, as a result, the speed of work would decrease. For best performance, emulation was left only where it could not be avoided, in our case in Android applications.
Be that as it may, Google has decided to use Java as the main language for developing applications and their environment.
I think it was a critical architectural solution that put Android apart from the rest of the Linux-based mobile OSs that are currently available. As far as I know, none of them have binary compatibility at the application level. Take for example MeeGo . It uses C ++ and the Qt framework ; Despite the fact that Qt is cross-platform, the need to do different builds for different platforms does not disappear.
Choosing Java, you had to decide which virtual machine (JVM) to use. Due to limited resources, using standard JVM was difficult. The only possible choice was to use a Java ME JVM developed for mobile devices. However, the happiness of Google would be incomplete without developing its own virtual machine, and Dalvik VM appeared.
Dalvik VM differs from other Java virtual machines in the following:
The guys from Google also reviewed the standard Java JDK API packages. They removed some of them (for example, everything about Swing) and added some of their own - their name starts with “android”.
They also added several open source packages that are not part of the standard JDK: Bouncy Castle crypto API, HTTPClient with support for HTTP / HTTPS separation on the client side.
Google also added a web browser to the application infrastructure layer. This is not a full-fledged Google Chrome for mobile devices, but very close to it, because it is based on the same WebKit engine and uses the JavaScript V8 engine from Chrome. In the end, this is an extremely modern and high-tech browser. It can be integrated into any Android application.
That's all for today. In the next article we will focus on the architecture of Android applications.
Update from the translator. The original used not quite the correct terminology. Thanks to all those who pointed out these errors.
The following articles:
Frankly, I find the official Google article on this topic not very useful. Responding in detail to the question “how”, she doesn’t explain at all what and why. So, here is my version, and I hope it will bring some clarity. Yes, by the way, I fully approve of reading Google articles, because they contain useful information, which I do not intend to repeat.
Android OS architecture - a bit of history
As is often the case in IT, many things cannot be explained in isolation from the history of the emergence of specific software. That is why we must turn to the origins of the Android OS.
The development of the Android OS was launched in 2003 by the young company Android Inc. In 2005, this company was bought by Google. I believe that the main features of the Android architecture were identified during this period. This is not only the credit of Android Inc; Google’s architectural concepts and financial resources have had a decisive influence on Android’s architecture. Next I will give a few examples.
')
If you remember, 2003-2005 was marked by increased attention to AJAX applications. I think this had a fundamental impact on the architecture of Android: in many aspects it is closer to the architecture of a typical AJAX application than to the desktop GUI application written in Java, C #, C ++, VB, and so on.
I do not know why it happened. My guess was someone from Google invented at a time when rich Internet applications (Rich Internet Applications, RIA) in the spirit of Google Docs or Gmail were considered to be the solution to all problems. In my opinion, this idea can not be called neither good nor bad. Just remember that Android applications are very different from desktop ones.
The influence of the architectural philosophy of Eclipse is noticeable in choosing the principle of GUI implementation, which is more like SWT than Swing.
In the standards for the design of the Android code there is a “Hungarian notation”, born within the walls of MS. It can be assumed that the person who wrote these standards was previously engaged in the development under Windows.
Android architectural levels
The Android operating system has three very different and highly separated levels:
- It is based on a modified and trimmed version of Linux, as I mentioned in one of my previous articles .
- Above the Linux level is the application infrastructure layer, which contains the Dalvik virtual machine , a web browser, a SQLite database, some infrastructure crutches, and a Java API.
- And finally, the level of Google-written Android applications. Generally speaking, they are an extension of the infrastructure level, since the developer can use these applications or parts of them as building blocks for their own development.
Consider these layers one by one and in more detail.
Linux level
Imagine that you are an architect in a young company. You must develop an OS for a new type of device. What are you going to do?
Roughly speaking, you have two ways: to implement your own ideas, starting from scratch, or use the existing OS and adapt it to your devices.
Implementing from scratch always sounds exciting to programmers. At these moments, we all believe that this time we will do everything better than others do, and even better than we ourselves did before.
However, this is not always practical. For example, the use of the Linux kernel has significantly reduced the cost of development (perhaps somewhere already excessively large). Agree, if someone decides to create something resembling the Linux kernel in its current state, it will need several million dollars.
If you are in charge of Android Inc, then by definition you cannot have that much money. If you run Google, then you will find that kind of money, but you will most likely think twice before spending it on creating your own OS. You will also spend several years before you reach the current state of Linux; several years of delay may be too late to enter the market.
In this situation, Apple decided to build a Mac OS based on Free BSD. Android Inc decided to use Linux as the basis for Android. Both BSD and Linux sources are freely available and provide a good basis for any development, be it Apple or Google.
But at that time it was impossible to launch standard Linux on a mobile device (now this is not the case). The devices had too little RAM and non-volatile memory. The processors were significantly slower compared to the processors of computers where Linux is commonly used. As a result, Android developers decided to minimize Linux system requirements.
If you look at Linux at a high level, then this is a combination of the kernel (which you can't do without) and many other optional parts. You can even run one core, without anything else. So, Google is forced in any case to use the Linux kernel as part of the Android OS. In addition, optional parts were considered and the most necessary were selected. For example, the IPTables network firewall and the Ash shell were added. It is curious that it was Ash who was added, not Bash, despite the fact that the latter is an order of magnitude more powerful; this decision was probably based on the fact that Ash is less resource intensive.
Android developers have modified the Linux kernel, adding support for hardware used in mobile devices and, more often, inaccessible on computers.
The choice of Linux as the basis had a huge impact on all aspects of the Android OS. Building Android, in fact, is a variation of the Linux build process. The Android code is under the control of git (a tool developed to manage Linux code). And so on.
Let it all be interesting, but you will most likely never touch all these specific moments until your goal is to develop Android applications. The only exception may be a review of the file system using the ash commands. The main thing that you should know when developing applications for Android is the level of application infrastructure.
You may ask how to be if you need to develop a native Android application? Google strongly discourages doing this. Technically, of course, this is possible, but in the future you will not be able to distribute this application in the normal way. So think twice before starting native Android development, unless of course you are working on the Android Open Source Project (AOSP), i.e. Android OS itself.
Application Infrastructure Level
Despite some similarities between Apple iOS and Android OS, there are significant differences between the architectural solutions on the infrastructure level of both OSs.
Apple decided to use Objective-C as a programming language and iOS application runtime. Objective-C looks like a more or less natural choice for an OS based on Free BSD. You can think of Objective-C as regular C ++ with a custom preprocessor that adds some specific linguistic constructs. Why it is impossible to use standard C ++ on which Free BSD is written? I think the reason is that Apple is trying to do everything in its “Apple” style.
The basic idea is that iOS applications are written more or less in the same language as the OS behind them.
Android applications are very different in that sense. They are written in Java, and this is a completely different technology than C ++ (although the syntax is inherited from C ++).
Why is this so? Why, for example, Android applications are not written in C ++? From Google, I did not find any explanation, so I can only share my own thoughts.
I think the main reason is that the same application needs to work on different hardware. This problem only occurs for the Android OS; The guys from Apple have no such problem. iOS only works on its own production equipment, and Apple fully controls the entire process. For Android, the opposite is true: Google does not control hardware manufacturers. For example, the Android OS runs on x86, ARM and Atom processors (in the comments, x86 includes Atom, and Android runs on x86, ARM, PPC and MIPS - translator's note ). At the binary level, these architectures are incompatible.
If the architects of the Android OS chose the same path as the architects from Apple, Android developers would have to distribute several versions of the same application at the same time. This would be a serious problem that could lead to the collapse of the entire Android project.
In order for the same application to work on different hardware, Google used container-based architecture. In this architecture, the binary code is executed by a software container and is isolated from the details of the specific hardware. Examples are familiar to all - Java and C #. In both languages, the binary code does not depend on the specific hardware and is executed by the virtual machine.
Of course, there is another way to achieve hardware independence at the binary code level. As one option, you can use a hardware emulator, also known as QEMU . It allows you to emulate, for example, a device with an ARM processor on the x86 platform and so on. Google could use C ++ as a language for developing applications inside emulators. Indeed, Google uses this approach in its Android emulators, which are based on QEMU.
It is very good that they did not follow this path, because then someone would have to run the OS on an emulator, which requires much more resources, and, as a result, the speed of work would decrease. For best performance, emulation was left only where it could not be avoided, in our case in Android applications.
Be that as it may, Google has decided to use Java as the main language for developing applications and their environment.
I think it was a critical architectural solution that put Android apart from the rest of the Linux-based mobile OSs that are currently available. As far as I know, none of them have binary compatibility at the application level. Take for example MeeGo . It uses C ++ and the Qt framework ; Despite the fact that Qt is cross-platform, the need to do different builds for different platforms does not disappear.
Choosing Java, you had to decide which virtual machine (JVM) to use. Due to limited resources, using standard JVM was difficult. The only possible choice was to use a Java ME JVM developed for mobile devices. However, the happiness of Google would be incomplete without developing its own virtual machine, and Dalvik VM appeared.
Dalvik VM differs from other Java virtual machines in the following:
- It uses a special DEX format for storing binary codes, as opposed to the JAR and Pack200 formats, which are the standard for other Java virtual machines. Google has said that the DEX binaries are smaller than the JAR. I think they might as well have used Pack200, but they decided to go their own way.
- Dalvik VM is optimized to run multiple processes simultaneously.
- Dalvik VM uses a register-based architecture against stack architecture in other JVMs, which leads to an increase in execution speed and a decrease in the size of binaries.
- It uses its own set of instructions (rather than the standard JVM bytecode).
- It is possible to launch (if necessary) several independent Android applications in one process.
- Running an application can span multiple Dalvik VM processes in a “natural way” (later we will discuss what this means). To support this, added:
- A special object serialization mechanism based on the Parcel and Parcelable classes. Functionally, they pursue the same goals as Java Serializable, but as a result, the data is smaller and potentially more tolerant of versioning class changes.
- A special way to make inter-process calls (inter process calls, IPC), based on Android Interface Definition Language (AIDL).
- Prior to Android 2.2, Dalvik VM did not support JIT compilation, which was a serious performance hit. Since version 2.2, the speed of execution of frequently used applications has increased markedly .
The guys from Google also reviewed the standard Java JDK API packages. They removed some of them (for example, everything about Swing) and added some of their own - their name starts with “android”.
They also added several open source packages that are not part of the standard JDK: Bouncy Castle crypto API, HTTPClient with support for HTTP / HTTPS separation on the client side.
Google also added a web browser to the application infrastructure layer. This is not a full-fledged Google Chrome for mobile devices, but very close to it, because it is based on the same WebKit engine and uses the JavaScript V8 engine from Chrome. In the end, this is an extremely modern and high-tech browser. It can be integrated into any Android application.
That's all for today. In the next article we will focus on the architecture of Android applications.
Update from the translator. The original used not quite the correct terminology. Thanks to all those who pointed out these errors.
The following articles:
Source: https://habr.com/ru/post/140459/
All Articles