Analysis of the Android Architecture

http://os.ibds.kit.edu/downloads/sa_2010_braehler-stefan_android-architecture.pdf

아래는 주요하게 본 내용들.

1. All Android Dalvik applications need to have a XML document in the application’s root directory called AndroidManifest.xml. This document is used by various facilities in the system to obtain administrative and organizational information about the application

Both receiver and service have to be announced in the application manifest file to allow Android to determine the service’s or receiver’s class even if the application is not running

2. If an activity needs to save it’s state to present the user the same exact state the activity was in when it was left, the onSaveInstanceState() method can be used for this purpose. This hook is called before the onPause() hook is called and allows to save the dynamic data as key-value pairs in a Bundle. The saved state object can be passed to onCreate() and onRestoreInstanceState() to restore the state of the activity. [24, 22, Application Fundamentals

3. Opposing to platforms with native binary executables, Android makes it easy to enforce a certain application behavior, as it’s application VM Dalvik directly controls code execution and resource access

4. During the installation process, an application is assigned with a unique and permanent user id. This user id is used to enforce permissions on process and file system level. An application can explicitly share files by setting the file mode to be world readable or writable, otherwise all files are private. If two applications should share the same processes or use the same user id, both of the applications have to be signed with the same certificate and ask for the same sharedUserId in their manifest files.

5. The native code parts of an application are shared libraries which are called through the Java Native Interface (JNI). The shared library has to be included in the applications .apk file and explicitly loaded. The code from the native library is loaded into the address space of the application’s VM. This leads to a possible security hole, as the security means described in section 2.5 do not cover native code.

6. These small systems usually only provide little RAM, a slow CPU and other than most PCs no swap

space to compensate the small amount of memory.

7. The byte code is more compact than usual Java byte code and the generated .dex files are small.

8. Every application runs in a sandboxed environment in it’s own Dalvik virtual machine instance. This requires Dalvik to be small and only add little overhead.

9. Dalvik is designed to run on devices with a minimum total memory of just 64 MB of RAM. For better performance actual devices have more than 64 MB installed. Of these 64 MB only about 40 MB remain for applications, libraries and services. The used libraries are quite large and likely need 10 MB of RAM. Actual applications only have around 20 MB left of the 64 MB of RAM. This very limited

amount of memory has to be used efficiently in order to run multiple applications at once

10. In order to save storage space, .dex files only contain unique data. If multiple class files share the same string, this string would only exist once in the .dex file and the multiple occurrences are just pointers to this one string (see Figure 3.1). The same mechanism is used for method names, constants and objects which results in smaller files with much internal “pointing”. The results of these means in terms of file size can be seen in table 3.1.

11. Dalvik knows 256 different op codes whereof 23 are unused in Android 2.2, leading to an actual total op code number of 233. Optimizations of the byte code is mostly done by the dexopt tool at installation time

12. Android applications often call native compiled and optimized libraries to perform performance critical tasks which leads to only about 1/3 of all executed code to be interpreted by the virtual machine. Therefore the achievable speedup is limited and also depends heavily on the benchmarked application. 

( jit는 실행중에 bytecode를 compile하여 machine code로 변환하고 이를 재사용한다. 그런데 위의 설명은 byte code 자체가 사실상 별로 없기 때문에 jit를 사용할 필요성이 없다는 내용 )

13. Like for webOS applications there is a browser based application development environment that helps creating applications easily and without the need of programming skills.