In the previous videos and articles, we have introduced the basic knowledge required for the entire vehicle Android application development:
- [Video transcript] Vehicle-mounted Android application development and analysis-Into the vehicle-mounted operating system-Nuggets
- [Video transcript] Vehicle Android application development and analysis - AOSP download and compilation - Nuggets
- [Video transcript] Car Android application development and analysis-Developing system applications-Nuggets
- [Video transcript] Vehicle-mounted Android application development and analysis - AIDL practice and packaging (Part 1) - Nuggets
- [Video transcript] Vehicle-mounted Android application development and analysis - AIDL practice and packaging (Part 2) - Nuggets
In this issue, we introduce the implementation of in-vehicle applications in native Android Automotive and its principles. The first thing I want to introduce is a very important system application in vehicle application development, the UI of the Android system - SystemUI.
Since the native Android system SystemUIhas a large amount of code and a very complex content, here I will select SystemUImodules that are of reference significance for vehicle development and introduce them. There will be about 4-5 issues of content, which are mainly divided into the following modules:
- Car Android application development and analysis - SystemUI "function" and "source code structure" analysis - Nuggets
- Car Android application development and analysis-first try SystemUI Plugin
The source code of SystemUI may be the most complex of all Android native applications. When we need to customize SystemUI, the huge amount of source code will bring huge potential risks to the customized development. Therefore, the current common practice for vehicle-mounted SystemUI is to transplant a small amount of necessary source code from the native SystemUI, and then customize a SystemUI with source code and fully controllable functions from scratch.
Is re-developing a SystemUI the only option? of course not! Google officials have long noticed this problem, so SystemUI provides a plug-in development method - SystemUI Plugin.
Source code address of this article: /frameworks/base/+/refs/heads/main/packages/SystemUI/plugin/ExamplePlugin/
The source code environment of this article is based on Android 13
SystemUI Plugins
The SystemUI plugin mechanism is a method that allows SystemUI functions to be dynamically replaced or modified. It allows developers to quickly create and iterate SystemUI prototypes while modifying the main framework of SystemUI as little as possible .
Note: Using Plugin does not guarantee that we do not need to modify the main framework of SystemUI. After all, the needs are always changing.
Plugin Hooks
Plugin hooks are predefined plug-in interfaces that allow applications to implement specific functions and register and declare plug-in types and versions through Intents and annotations. There are many types of Plugin hooks, such as OverlayPlugin, QSFactory, VolumeDialog, etc. Each type has a corresponding action and expected interface, which are used to identify the functions and requirements of the plug-in.
The predefined interfaces for Plugin hooks in Android 13 mainly include the following:
- BcSmartspaceDataPlugin : This plugin allows the application to provide customized data to the smart space (BcSmartspace) on the lock screen interface, such as weather, calendar, news, etc.
- ClockProviderPlugin : This plugin allows applications to provide customized clock styles for lock screen interfaces and always-on applications.
- DozeServicePlugin : This plugin allows applications to customize the behavior of Doze mode, such as controlling screen brightness, display content, sensors, etc.
- FalsingPlugin : This plugin allows applications to customize the detection and processing of false touch (Falsing) events, such as determining whether the user really wants to slide the notification bar or unlock the screen.
- GlobalActions : This plugin allows applications to customize the appearance and behavior of the Global Actions dialog box, such as adding new action buttons or changing the dialog box style.
- GlobalActionsPanelPlugin : This plugin allows the application to add an expandable panel to the global operations dialog box to display more operation options or information.
- IntentButtonProvider : This plugin allows the application to add a custom button on the lock screen interface to start a specified Intent.
- NavigationEdgeBackPlugin : This plugin allows applications to customize the behavior of the navigation bar edge return (NavigationEdgeBack) gesture, such as changing the trigger area or animation effects.
- NotificationListenerController : This plugin allows the application to control the connection and disconnection of the notification listener (NotificationListener) service, as well as obtain notification events and data.
- NotificationMenuRowPlugin : This plugin allows applications to customize the appearance and behavior of the notification menu bar (NotificationMenuRow), such as adding new menu items or changing the menu style.
- NotificationPersonExtractorPlugin : This plugin allows applications to customize the logic of extracting person information (NotificationPersonExtractor) from notifications, such as identifying contacts or avatars included in notifications.
- OverlayPlugin : This plugin allows the application to customize the view (OverlayView) that covers the notification bar to display some additional content or functions.
- PluginFragment : This plugin allows the application to embed a Fragment in SystemUI to display some customized interfaces or functions.
- QSFactory : This plugin allows applications to provide a custom quick settings factory (QSFactory) for creating quick settings tiles or panels.
- SensorManagerPlugin : This plugin allows applications to use the SensorManager service to register and unregister sensor listeners, and obtain sensor events and data.
- ToastPlugin : This plugin allows applications to customize the appearance and behavior of Toast messages (Toast), such as changing the Toast position or duration.
- ViewProvider : This plugin allows the application to provide a custom view (View) to replace certain components or functions in SystemUI.
- VolumeDialog : This plugin allows applications to customize the appearance and behavior of the volume adjustment dialog box (VolumeDialog), such as adding new volume control options or changing the style of the volume bar.
Plugin skill
To create an AndroidStudio SystemUI plugin project, you can refer to the following steps:
1) Compile SystemUIPluginLib.jar
Before using Plugin, we need to compile it SystemUIPluginLib.jarand execute the following instructions in the AOSP source code root directory.
make SystemUIPluginLib
Then you can get it in the directory belowSystemUIPluginLib.jar
out/target/product/emulator_x86/obj/JAVA_LIBRARIES/SystemUIPluginLib_intermediates/javalib.jar
In the AOSP documentation, it is recommended to use the frameworks/base/packages/SystemUI/plugin/update_plugin_lib.sh script to compile SystemUIPluginLib.jar, but I encountered an environment configuration problem when compiling.
2) Configure system signature
Configure system signing in build.gradle.
android {
...
signingConfigs {
sign {
storeFile file('system.keystore')
storePassword '123456'
keyAlias 'cardemo'
keyPassword '123456'
}
}
buildTypes {
release {
minifyEnabled false
signingConfig signingConfigs.sign
}
debug {
minifyEnabled false
signingConfig signingConfigs.sign
}
}
}
Regarding how to make a system signature, please refer to: Vehicle Android Application Development and Analysis - Developing System Applications - Nuggets
3) Create a Plugin
Define a class in the plugin project to implement various plug-ins already provided in Plugin, and use the Requires annotation to declare the target and version fields. These fields are used to identify the type and version of the plug-in.
@Requires(target = OverlayPlugin.class, version = OverlayPlugin.VERSION)
public class SampleOverlayPlugin implements OverlayPlugin {
private static final String TAG = "SampleOverlayPlugin";
private Context mPluginContext;
private View mStatusBarView;
private View mNavBarView;
@Override
public void onCreate(Context sysuiContext, Context pluginContext) {
Log.d(TAG, "onCreate");
mPluginContext = pluginContext;
}
@Override
public void onDestroy() {
if (mInputSetup) {
mStatusBarView.getViewTreeObserver().removeOnComputeInternalInsetsListener(
onComputeInternalInsetsListener);
}
Log.d(TAG, "onDestroy");
if (mStatusBarView != null) {
mStatusBarView.post(() -> ((ViewGroup) mStatusBarView.getParent()).removeView(mStatusBarView));
}
if (mNavBarView != null) {
mNavBarView.post(() -> ((ViewGroup) mNavBarView.getParent()).removeView(mNavBarView));
}
}
@Override
public void setup(View notificationShadeWindowView, View navBar) {
Log.d(TAG, "Setup");
if (notificationShadeWindowView instanceof ViewGroup) {
mStatusBarView = LayoutInflater.from(mPluginContext)
.inflate(R.layout.colored_overlay, (ViewGroup) notificationShadeWindowView, false);
((ViewGroup) notificationShadeWindowView).removeAllViews();
((ViewGroup) notificationShadeWindowView).addView(mStatusBarView);
}
if (navBar instanceof ViewGroup) {
mNavBarView = LayoutInflater.from(mPluginContext)
.inflate(R.layout.colored_overlay, (ViewGroup) navBar, false);
((ViewGroup) navBar).removeAllViews();
((ViewGroup) navBar).addView(mNavBarView);
}
}
}
Note: There are considerable differences in the code of SystemUI in different versions of Android. For example: the statusBar returned in setup(View statusBar, View navBar) in Android13 is actually NotificationShadeWindowView.
4) Register Plugin
Register a service in the AndroidManifest of the plugin project, and use the action and permission attributes to specify the plug-in's interface and permissions, so that SystemUI can find the plug-in through Intent.
<uses-permission android:name="com.android.systemui.permission.PLUGIN" />
<application>
<service
android:name=".SampleOverlayPlugin"
android:exported="false"
android:label="@string/plugin_label"
tools:ignore="Instantiatable">
<intent-filter>
<action android:name="com.android.systemui.action.PLUGIN_OVERLAY" />
</intent-filter>
</service>
</application>
The name can be found in the plugin interface we implemented.
In order to ensure system security, SystemUI has built two lines of defense for plugin loading:
The first line of defense is the Build.IS_DEBUGGABLE check. SysUI checks Build.IS_DEBUGGABLE before scanning or loading any plugins on the device to ensure the build is debuggable.
The second line of defense is signature authority. All plugins must be signed by the system and hold com.android.systemui.permission.PLUGINpermissions to load any of their code, otherwise a violation will be logged and the plugin will be ignored.
5) Run Plugin
Push plugin.apk to the /system/priv-app/ directory of the Android 13 emulator and restart. You can see the following effect:
- All sub-Views of NavBar are removed and a red View is added;
- All child Views of NotificationShadeWindowView are removed and a red View is added.
Summarize
This article first tried the SystemUI plug-in mechanism. When writing this article, I found that there was very little Plugin-related information, and even the official information was out of date. So just like the title, this article just briefly tried Plugin. How to use Plugin to customize a SystemUI that fully meets our needs? We will write this later, because we need to analyze the principles of SystemUI Plugin first. With so little information, it is almost impossible to write a Plugin that meets the needs without understanding the principles. In the process of analyzing the principles, we will gradually complete and understand some Plugin concepts.
The above is all the content of this article. Thank you for reading. I hope it will be helpful to you.
References