System Apps with AOSP A Guide to .bp and .mk File Configuration

Here is the English translation:

What are AOSP and System Apps?

AOSP (Android Open Source Project) refers to the open source project of the Android operating system developed and maintained by Google. Through this, developers can view Android's source code or develop their own operating systems. Operating systems developed based on AOSP can be applied to various devices, allowing developers to optimize the user experience.

What are System Apps?

System apps refer to apps built into the operating system. These are apps that users cannot delete or modify, and they serve core functions of the OS. For example, there are apps like Phone, Messages, Settings, etc. System apps provide consistent user experiences across devices and ensure security and efficiency.

Benefits of Developing System Apps with AOSP

There are several benefits to developing system apps using AOSP. First, since users cannot delete system apps, sustained use of the apps can be guaranteed. Second, system apps can utilize broader device permissions, further enhancing user experience. Third, system apps come pre-installed on devices without separate installation, eliminating the need for users to download apps separately. By leveraging AOSP, developers can maximize these benefits when developing system apps.

Understanding .bp and .mk Files

AOSP uses .bp and .mk files to manage build configurations. These files play important roles in building system apps, so understanding their functions and characteristics is key.

What are .bp Files?

.bp (Blueprint) files are the new build system introduced in AOSP. Written in a JSON-like format, they are used to describe build configurations. .bp files define source files, compile options, dependencies, etc. needed in the build process. Using .bp files allows concise management of complex build processes.

What are .mk Files?

.mk (Make) files are configuration files used in AOSP's legacy build system. Also called Makefiles, they are used to define build rules. .mk files specify build targets, methods, required libraries, etc. Through .mk files, the build process can be controlled in greater detail.

How to Configure .bp Files

Configuring .bp files starts with understanding their basic structure. .bp files are written in the following format:

cc_binary {
  name: "my_app",
  srcs: ["my_app.c"],
  cflags: ["-DUSE_MY_APP"],
  static_libs: ["libmylib"],
}

In the example above, 'cc_binary' indicates the build target is a C/C++ binary. 'name' specifies the build target name, 'srcs' lists source files, 'cflags' shows compile options, and 'static_libs' lists static libraries. Using .bp files allows build configurations to be written and managed easily in this manner.

Various Settings in .bp Files

.bp files can control build processes in detail through various settings. For example, 'shared_libs' can specify dynamic libraries, and 'cppflags' can set C++ compile options. The 'arch' setting can also change build settings for specific architectures.

  
cc_binary {
  name: "my_app",
  srcs: ["my_app.c"],
  cppflags: ["-DUSE_MY_APP"],
  shared_libs: ["libmylib"],
  target: {
    arm64: {
      srcs: ["my_app_arm64.c"],
    },
    x86: {
      srcs: ["my_app_x86.c"],
    },
  },
}

In the example above, the 'target' setting specifies separate source files for ARM64 and x86 architectures. These configurations allow developing system apps that support diverse environments.

How to Configure .mk Files

Configuring .mk files also starts with understanding their basic structure. .mk files are written as:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := my_app  
LOCAL_SRC_FILES := my_app.c
LOCAL_CFLAGS    := -DUSE_MY_APP
LOCAL_STATIC_LIBRARIES := libmylib

include $(BUILD_EXECUTABLE) 

In the example above, 'LOCAL_MODULE' specifies the build target name, 'LOCAL_SRC_FILES' lists source files, 'LOCAL_CFLAGS' shows compile options, and 'LOCAL_STATIC_LIBRARIES' lists static libraries. 'include $(BUILD_EXECUTABLE)' indicates the target is a buildable binary. Using .mk files allows build configurations to be written and managed in this way.

Various Settings in .mk Files

.mk files can also control build processes in detail through various settings. For example, 'LOCAL_SHARED_LIBRARIES' can specify dynamic libraries, and 'LOCAL_CPPFLAGS' can set C++ compile options. The 'LOCAL_MODULE_TAGS' setting can also tag build targets.

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := my_app
LOCAL_SRC_FILES := my_app.c  
LOCAL_CPPFLAGS  := -DUSE_MY_APP
LOCAL_SHARED_LIBRARIES := libmylib
LOCAL_MODULE_TAGS := optional  

include $(BUILD_EXECUTABLE)

In the example above, 'LOCAL_MODULE_TAGS' makes 'my_app' module optionally buildable. These configurations allow developing system apps that support diverse environments.

Considerations when Developing System Apps

Developing system apps has some notable differences from general app development. This is because system apps serve core OS functions and directly impact user devices.

Security

System apps can access broader device permissions, so security is especially important. Strict procedures like obtaining user consent must be followed when handling personal data. Also, since users cannot delete system apps, any discovered vulnerabilities must be patched immediately.

Compatibility

System apps need to work across various devices and OS versions. So apps must be developed with consideration for diverse environments. In particular, apps must be updated to support new APIs whenever new OS versions are released.