From 02a62fc2556af74122fd3ab113a393961bec4ec7 Mon Sep 17 00:00:00 2001
From: Android Partner Docs As part of the Android 8.0 rearchitecture of the lower layers of the Android OS
-to support better modularity, devices running Android 8.0 must support binderized
-or passthrough HALs: In Android 8.0 and higher, the lower-level layers are re-written to adopt
+a new, more modular architecture. Devices running Android 8.0 and higher must
+support HALs written in the HIDL language, with a few exceptions listed below.
+These HALs can be binderized or passthrough:
-
diff --git a/en/devices/architecture/hidl-cpp/interfaces.html b/en/devices/architecture/hidl-cpp/interfaces.html
index 285c22b5..c236a171 100644
--- a/en/devices/architecture/hidl-cpp/interfaces.html
+++ b/en/devices/architecture/hidl-cpp/interfaces.html
@@ -248,7 +248,7 @@ from a thread in the RPC threadpool when the process hosting the interface dies:
All other HALs provided by the vendor image can be in passthrough
-OR binderized mode.
+OR binderized mode. In a fully Treble-compliant device, all of these must be
+binderized.
-class MyDeathRecipient : android::hardware::hidl_death_recipient { +class MyDeathRecipient : public android::hardware::hidl_death_recipient { virtual void serviceDied(uint64_t cookie, const android::wp<::android::hidl::base::V1_0::IBase>& who) { // Deal with the fact that the service died } diff --git a/en/devices/architecture/hidl/interfaces.html b/en/devices/architecture/hidl/interfaces.html index 6fc1cb1b..483b521a 100644 --- a/en/devices/architecture/hidl/interfaces.html +++ b/en/devices/architecture/hidl/interfaces.html @@ -215,11 +215,11 @@ previous version. New data structures and methods can be added, but no existing data structures or method signatures may be changed. -For broader compatibility with frameworks, multiple major versions of a HAL -can be present on a device simultaneously. While multiple minor versions can -also be present on a device, as minor versions are backwards compatible no -reason exists to support more than the latest minor version for each major -version. For more details on versioning and vendor extensions, see +
Multiple major or minor versions of a HAL can be present on a device +simultaneously. However, a minor version should be preferred over a major +version because client code that works with a previous minor version interface +will also work with later minor versions of that same interface. For more +details on versioning and vendor extensions, see HIDL Versioning.
Interface layout summary
diff --git a/en/devices/architecture/kernel/bpf.md b/en/devices/architecture/kernel/bpf.md new file mode 100644 index 00000000..1e08703f --- /dev/null +++ b/en/devices/architecture/kernel/bpf.md @@ -0,0 +1,302 @@ +Project: /_project.yaml +Book: /_book.yaml + +{% include "_versions.html" %} + + + +# Extending the kernel with eBPF + +Android includes an eBPF loader and library that loads eBPF +programs at boot time to extend kernel functionality. This can be used for +collecting statistics from the kernel, monitoring, or debugging. + +## About eBPF + +Extended Berkeley Packet Filter (eBPF) is an in-kernel virtual machine that +runs user-supplied eBPF programs that can be hooked to probes or events in +the kernel, collect useful statistics, and store the results in rich +data structures. A program is loaded into the kernel using the `bpf(2)` syscall +and is provided by the user as a binary blob of eBPF machine instructions. +The Android build system has support for compiling C programs to eBPF using +simple build file syntax described later. + +More information about eBPF internals and architecture can be found at [Brendan +Gregg's eBPF page](http://www.brendangregg.com/ebpf.html){: .external}. + +## Android BPF loader + +During Android boot, all eBPF programs located at `/system/etc/bpf/` are +loaded. These programs are binary objects built by the Android build system +from C programs accompanied with Android.bp files in the Android source tree. +The build system stores the generated objects at `/system/etc/bpf`, and +they become part of the system image. + +### Format of an Android eBPF C program + +An eBPF C program loaded on an Android device must have the following format: + ++#include <bpf_helpers.h> + +<... define one or more maps in the maps section, ex: +/* Define a map of type array, with 10 entries */ +struct bpf_map_def SEC("maps") MY_MAPNAME = { + .type = BPF_MAP_TYPE_ARRAY, + .key_size = sizeof(int), + .value_size = sizeof(uint32_t), + .max_entries = 10, +}; +... > + +SEC("PROGTYPE/PROGNAME") +int PROGFUNC(..args..) { + <body-of-code + ... read or write to MY_MAPNAME + ... do other things + > +} + +char _license[] SEC("license") = "GPL"; // or other license ++ +Here, `MY_MAPNAME` is the name of your map variable. It's of type `struct +bpf_map_def` and tells the BPF loader what kind of map to create with what +parameters. This struct definition is provided by the `bpf_helpers.h` header +that the C program includes. The above code results in a creation of an array +map of 10 entries. + +Next, the program defines a function `PROGFUNC`. When compiled, this function is +placed in a section. The section must have a name of the format +`PROGTYPE/PROGNAME`. `PROGTYPE` can be any one of the following. More types can +be found in the [Loader +source code](https://android.googlesource.com/platform/system/bpf/+/4845288a6e42e13b1bb8063923b24371c9e93397/libbpf_android/Loader.cpp){: +.external}. + +
kprobe | +Hooks PROGFUNC onto at a kernel instruction using the
+kprobe infrastructure. PROGNAME must be the name of the kernel
+function being kprobed. Refer to the kprobe kernel documentation for more information about
+kprobes.
+ |
+
---|---|
tracepoint | +Hooks PROGFUNC onto a tracepoint. PROGNAME must be of
+ the format SUBSYSTEM/EVENT . For example, a tracepoint section for attaching
+functions to scheduler context switch events would be
+ SEC("tracepoint/sched/sched_switch") , where sched is
+ the name of the trace subsystem, and sched_switch is the name
+ of the trace event. Check the trace events kernel
+documentation for more information about tracepoints.
+ |
+
skfilter | +Program will function as a networking socket filter. | +
schedcls | +Program functions as a networking traffic classifier. | +
cgroupskb, cgroupsock | +Program runs whenever processes in a CGroup create an AF_INET or AF_INET6 socket. + | +
+#include <linux/bpf.h> +#include <stdbool.h> +#include <stdint.h> +#include <bpf_helpers.h> + +struct bpf_map_def SEC("maps") cpu_pid = { + .type = BPF_MAP_TYPE_ARRAY, + .key_size = sizeof(int), + .value_size = sizeof(uint32_t), + /* Assume max of 1024 CPUs */ + .max_entries = 1024, +}; + +struct switch_args { + unsigned long long ignore; + char prev_comm[16]; + int prev_pid; + int prev_prio; + long long prev_state; + char next_comm[16]; + int next_pid; + int next_prio; +}; + +SEC("tracepoint/sched/sched_switch") +int tp_sched_switch(struct switch_args* args) { + int key; + uint32_t val; + + key = bpf_get_smp_processor_id(); + val = args->next_pid; + + bpf_map_update_elem(&cpu_pid, &key, &val, BPF_ANY); + return 0; +} + +char _license[] SEC("license") = "GPL"; ++ +The license section is used by the kernel to verify if the program is compatible with the +kernel's license when the program makes use of BPF helper functions provided by the kernel. Set `_license` to your +project's license. + +### Format of the Android.bp file +In order for the Android build system to build an eBPF .c program, an entry has +to be made in the Android.bp file of the project. + +For example, to build an eBPF C program of name `bpf_test.c`, make the following +entry in your project's Android.bp file: +
+bpf { + name: "bpf_test.o", + srcs: ["bpf_test.c"], + cflags: [ + "-Wall", + "-Werror", + ], +} ++ +This compiles the C program resulting in the object +`/system/etc/bpf/bpf_test.o`. On boot, the Android system automatically loads +the `bpf_test.o` program into the kernel. + +### Files available in sysfs +During boot up, the Android system automatically loads all the eBPF objects from `/system/etc/bpf/`, +creates the maps that the program needs, and pins the loaded program with its maps to the bpf file system. +These files can then be used for further interaction with the eBPF program or reading maps. This section +describes the conventions used for naming these files and their locations in sysfs. + +The following files are created and pinned: + +* For any programs loaded, assuming `PROGNAME` is the name of the program and `FILENAME` is the name of the eBPF C file, the Android loader creates and pins each program at `/sys/fs/bpf/prog_FILENAME_PROGTYPE_PROGNAME`. + + For example, for the above `sched_switch` tracepoint example in `myschedtp.c`, a program file will be created and pinned to +`/sys/fs/bpf/prog_myschedtp_tracepoint_sched_sched_switch`. + +* For any maps created, assuming `MAPNAME` is the name of the map and `PROGNAME` is the name of the eBPF C file, the Android loader creates and pins each map to `/sys/fs/bpf/map_FILENAME_MAPNAME`. + + For example, for the above `sched_switch` tracepoint example in `myschedtp.c`, a map file is created and pinned to +`/sys/fs/bpf/map_myschedtp_cpu_pid`. + +* The `bpf_obj_get()` in the Android BPF library can be used to obtained a file descriptor from these pinned /sys/fs/bpf file. This function returns a file descriptor, which can be used for further operations, such as reading maps or attaching a program to a tracepoint. + +## Android BPF library +The Android BPF library is named `libbpf_android.so` and is part of the system +image. This library provides the user with low-level eBPF functionality needed +for creating and reading maps, creating probes, tracepoints, perf buffers etc. + +### Attaching programs to tracepoints and kprobes +Once tracepoint and kprobe programs have been loaded (which is done automatically +at boot up as previously described), they need to be activated. To activate them, +first, use the `bpf_obj_get()` API to obtain the program fd from the pinned file's +location (see the [Files available in sysfs](/devices/architecture/kernel/bpf#files_available_in_sysfs) +section). Next, call the `bpf_attach_tracepoint()` +API in the BPF library, passing it the program fd and the tracepoint name. + +For example, to attach the `sched_switch` tracepoint defined in the `myschedtp.c` +source file in the example above, do the following (error checking is not shown): + +
+ char *tp_prog_path = "/sys/fs/bpf/prog_myschedtp_tracepoint_sched_sched_switch"; + char *tp_map_path = "/sys/fs/bpf/map_myschedtp_cpu_pid"; + + // Attach tracepoint and wait for 4 seconds + int mProgFd = bpf_obj_get(tp_prog_path); + int mMapFd = bpf_obj_get(tp_map_path); + int ret = bpf_attach_tracepoint(mProgFd, "sched", "sched_switch"); + sleep(4); + + // Read the map to find the last PID that ran on CPU 0 + android::bpf::BpfMap+ +### Reading from the maps + +BPF maps support arbitrary complex key and value structures or types. The +Android BPF library includes an `android::BpfMap` class that makes use of C++ +templates to instantiate `BpfMap` based on the key and value's type for the +map in question. The above code shows an example of using a `BpfMap` with key and +value as integers. The integers can also be arbitrary structures. + +Thus the templatized `BpfMap` class makes it easy to define a custom `BpfMap` +object suitable for the particular map. The map can then be accessed using the +custom-generated functions which are type aware, resulting in cleaner code. + +For more information about `BpfMap`, refer to the +[Android sources].(https://android.googlesource.com/platform/system/bpf/+/75b410bdf186263fa4e05e079bfba44578622c33/libbpf/include/bpf/BpfMap.h){: .external} + +## Debugging issues + +During boot time, several messages related to BPF loading are logged. If the +loading process fails for any reason, a detailed log message is provided +in logcat. Filtering the logcat logs by "bpf" prints all the messages and +any detailed errors during load time, such as eBPF verifier errors. + +## Users of eBPF in Android + +Currently there are two eBPF C programs in Android that you can refer to for examples. + +The `netd` [eBPF C +program](https://android.googlesource.com/platform/system/bpf/+/4845288a6e42e13b1bb8063923b24371c9e93397/progs/netd.c){: .external} +is used by the networking daemon (netd) in Android for various purposes such as +socket filtering and statistics gathering. To see how this programs is used, check the [eBPF traffic +monitor](https://www.google.com/url?sa=D&q=https%3A%2F%2Fsource.android.com%2Fdevices%2Ftech%2Fdatausage%2Febpf-traffic-monitor){: .external} +sources. + +The `time_in_state` [eBPF C +program](https://android.googlesource.com/platform/system/bpfprogs/+/482dfa1ca63eb209866ff3a7b3aeb3daada7b4e1/time_in_state.c){: .external} +calculates the amount of time an Android app spends at different +CPU frequencies which is used to calculate power. This program is currently under development. + +## Licensing considerations + +If you want to contribute an eBPF C program, it should be contributed to the right +project depending on its license. A GPL licensed eBPF C program should be +contributed to the `system/bpfprogs` AOSP project. On the other hand, if the program +is Apache licensed, it should be contributed to `system/bpf` AOSP project. diff --git a/en/devices/architecture/kernel/reqs-interfaces.html b/en/devices/architecture/kernel/reqs-interfaces.html index 53fbf656..ea6c687e 100644 --- a/en/devices/architecture/kernel/reqs-interfaces.html +++ b/en/devices/architecture/kernel/reqs-interfaces.html @@ -23,7 +23,7 @@ -->myMap(mMapFd); + printf("last PID running on CPU %d is %d\n", 0, myMap.readValue(0)); +
This page describes a subset of the Linux kernel interfaces on which Android -relies to function properly. The presence and correctness of these interfaces is +relies to function properly. The presence and correctness of these interfaces are tested as part of the Vendor Test Suite (VTS). This subset will grow over time to contain a larger portion of Android kernel interfaces.
diff --git a/en/devices/architecture/vintf/objects.html b/en/devices/architecture/vintf/objects.html index 3bfeff64..18cd57c0 100644 --- a/en/devices/architecture/vintf/objects.html +++ b/en/devices/architecture/vintf/objects.html @@ -64,7 +64,7 @@ DM from fragments./vendor/manfiest.xml
(legacy, no fragments)/vendor/manifest.xml
(legacy, no fragments)Note: Android 7.0 preserves support for using +
Note: Android 7.0 preserves support for using
audio_policy.conf
; this legacy format is used by default. To use
the XML file format, include the build option USE_XML_AUDIO_POLICY_CONF
:= 1
in device makefile.
AOSP includes an example of an audio policy configuration file that uses the parameter-framework at: Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml
. For
details, refer to Intel documentation on the
-parameter-framework
-and
-Android
-Configurable Audio Policy.
Android 6.0 introduced a public Enumeration and Selection API that sits on
@@ -367,10 +364,13 @@ the explicit routing methods that were specific to AudioTrack
and
AudioRecord
classes.
For details on the Enumeration and Selection API, refer to
-Android
+Android
configuration interfaces and OpenSLES_AndroidConfiguration.h
.
For details on audio routing, refer to
-AudioRouting.
+AudioRouting.
A sample C++ EVS application
-(/packages/services/Car/evs/sample_app
) serves as a reference
+(/packages/services/Car/evs/app
) serves as a reference
implementation. This application is responsible for requesting video frames from
the EVS Manager and sending finished frames for display back to the EVS Manager.
It expects to be started by init as soon as EVS and Car Service are available,
diff --git a/en/devices/automotive/power.html b/en/devices/automotive/power.html
index 084a39bb..d6707341 100644
--- a/en/devices/automotive/power.html
+++ b/en/devices/automotive/power.html
@@ -21,16 +21,17 @@
limitations under the License.
-->
-
Android 9 introduces a new state – deep sleep – into the power
-management state machine. To implement this state, Android 9 provides a new power management service
-and interface: CarPowerManagementService
and CarPowerManager
.
Android introduces a new state into the power management state machine, called
+deep sleep. To implement deep sleep, Android provides a
+CarPowerManagementService
service and a CarPowerManager
interface.
State transitions are triggered by the Vehicle MCU (VMCU). To communicate with the VMCU, -integrators must implement several components. Integrators are responsible for integrating -with the VHAL and the kernel implementation. Integrators are also responsible for disabling wake -sources and ensuring that shutdowns are not postponed indefinitely.
+State transitions are triggered by the Vehicle Master Control Unit (VMCU). To communicate with +the VMCU, Integrators must implement several components. Integrators are responsible for integrating +with the Vehicle Hardware Abstraction Layer (VHAL) and the kernel implementation. Integrators are +also responsible for disabling wake sources and ensuring that shutdowns are not postponed +indefinitely.
-These terms are used throughout this document:
@@ -44,54 +45,52 @@ sources and ensuring that shutdowns are not postponed indefinitely.suspend()
and shutdown()
.This section describes how Android 9 represents the application processor's power state and which +
This section describes how Android represents the application processor's power state and which modules implement the power management system. This material also describes how these modules work together and how state transitions typically occur.
-Android 9 uses a state machine to represent the power state of the AP. This state machine -provides these five states, as illustrated below: +
Android uses a state machine to represent the power state of the AP. The state +machine provides the states illustrated below: -
+ -Figure 1. Car power state machine
+Figure 1. Car power state machine
The initial state of this state machine is OFF. This state can transition into two states, -ON:DISP OFF and ON: FULL. Both states indicate the AP is on. The difference lies in the +ON: DISP OFF and ON: FULL. Both states indicate that the AP is on. The difference lies in the display's power state. ON: DISP OFF means that the AP is running and displays are turned off. -When display turns on, the ON: DISP OFF state transitions into ON:FULL (and vice versa).
+When the display turns on, the ON: DISP OFF state transitions into ON: FULL (and vice versa).The AP is turned off in two cases. In both cases, the state machine first changes state to SHUTDOWN PREPARE and then transitions to OFF or DEEP SLEEP:
When this power management state machine enters the DEEP SLEEP state, the AP runs Suspend to +
When the power management state machine enters the DEEP SLEEP state, the AP runs Suspend to RAM. For example, the AP suspends its state (such as register stored value) in RAM. When the AP wakes up, all states are restored.
-These five modules comprise the power management system:
+The power management system is comprised of these modules:
CarPowerManager | -Java/C++ API | +Java/C++ API. | |
CarPowerManagementService | -Responsible for coordinating the sleep/suspend power state | +Coordinates the Sleep/Suspend power state. | |
Vehicle HAL | -Interface to VMCU | +Interface to the VMCU. | |
libsuspend | -Native library to place the device into suspend | +libsuspend | +Native library to place the device into suspend. |
Kernel | -Suspend to RAM implementation | +Suspend to RAM implementation. |
The deep sleep feature (suspending Android to RAM) is implemented in the kernel. This feature is
-exposed to the user space as a special file located at /sys/power/state
. AAE is
-suspended by writing mem
to this file.
/sys/power/state
. Android
+Auto is suspended by writing mem
to this file.
libsuspend
is a native library that implements forcesuspend()
. This
-function uses /sys/power/state
to suspend AAE. forcesuspend()
can be
-called from system services, including CPMS.
/sys/power/state
to suspend Android Auto.
+forcesuspend()
can be called from system services, including CPMS.
+
The CPMS coordinates the power state with other services and HALs. The CPMS implements the state machine described above and sends notifications to every observer when a power state transition @@ -195,23 +195,19 @@ hardware.
Some properties are defined in the VHAL. To communicate with the VMCU, the CPMS reads and writes these properties. Applications can use the interface defined in the CPM to monitor power state changes. This interface also enables applications to acquire the boot reason and to send shutdown -requests. This API can be called from Java and C++ and are annotated with @hide / @System API, which +requests. This API can be called from Java and C++ and is annotated with @hide / @System API, which means it is available to privileged applications only. The relationship between these five modules, applications, and services is illustrated below:
- + -Figure 2. Power components reference diagram
+Figure 2. Power components reference diagram
-The previous section described the modules that comprise the power management system. This -section uses the following two examples to explain how the modules and applications communicate:
- -onStateChanged()
method with a new state ID provided by the
CPM.
-The CPM mediates between the applications/services and the CPMS. The onStateChanged()
-method for the applications/services is synchronously invoked in the CPM's
-onStateChanged()
method. After which, the finished method of the CPMS is invoked to
-notify the CPMS that the target application or service is ready to suspend. The CPM's
+The CPM mediates between the applications/services and the CPMS. The
+onStateChanged()
method for the applications/services is synchronously invoked in the
+CPM's onStateChanged()
method. After which, the finished method of the CPMS is invoked
+to notify the CPMS that the target application or service is ready to suspend. The CPM's
onStateChanged()
method runs asynchronously. Therefore, some delay occurs between the
calling of the onStateChanged()
method to all CPM objects and the receiving of the
finished message from all these objects. During this time, the CPMS continues to send shutdown
@@ -235,11 +231,11 @@ postpone requests to the VHAL.
libsuspend
.
-The entire sequence described above is illustrated in the following sequence diagram: +
The sequence described above is illustrated below: -
+ -Figure 3. Enter deep sleep sequence diagram
+Figure 3. Enter deep sleep
Figure 4. Exit deep sleep sequence diagram
+Figure 4. Exit deep sleep
-This section describes the Java and C++ API provided by the CPM for system applications and services. The process to call the CPM in C++ is identical to that used by the Java API. This API @@ -282,9 +278,9 @@ illustrates how to use these APIs in Java. Use these steps to call the APIs prov
To create a CPM object, call the Car object's getCarManager()
method. This method is
+
To create a CPM object, call the Car object's getCarManager()
method. This method is
a facade used to create CM objects. Specify android.car.Car.POWER_SERVICE
as an
argument to create a CPM object.
System applications and services can receive power state change notifications by implementing
CarPowerManager.CarPowerStateListener
. This interface defines one method
@@ -328,7 +324,7 @@ powerManager.setListener(powerListener, executer);
When the power state is changed, the onStateChanged()
method of the listener object
is invoked with a value to represent the new power state. The association between actual value and
-power state is defined in CarPowerManager.CarPowerStateListene
r and is shown in the
+power state is defined in CarPowerManager.CarPowerStateListener
and is shown in the
following table:
To unregister all listener objects registered to CPM, call the clearListener
method:
To acquire the boot reason, call the getBootReason
method, which communicates with
the CPMS and returns one of the following five boot reasons:
This method throws a CarNotConnectedException
when it fails to communicate with the
CPMS.
The requestShutdownOnNextSuspend()
method instructs CPMS to shut down instead of deep
sleep at the next opportunity.
Integrators are responsible for implementing the following items:
@@ -446,7 +442,7 @@ sleep at the next opportunity. process. -First, implement the Linux suspend power state. Android places a device into suspend mode when
an application or service writes mem
into a file located at
@@ -455,7 +451,7 @@ the VMCU that the device has shut down completely. The Integrator is also respon
any race conditions between VHAL sending the final message to the VMCU and the system going into
suspend or shutdown mode.
The VHAL provides an interface between the vehicle network and Android. The VHAL:
@@ -499,11 +495,11 @@ instruct the VMCU that it is safe to remove power from the device.Use this property to report Android's current power management state.This property contains two +
Use this property to report Android's current power management state. This property contains two integers:
int32Values[0]
: VehicleApPowerStateReport
enum of the current state.int32Values[0]
: VehicleApPowerStateReport enum of the current state.int32Values[1]
: Time in milliseconds to postpone or sleep/shutdown. This value
depends on the first value.The state can be set asynchronously (in the case of BOOT_COMPLETE
) or in response to
a request via the VMCU. When the state is set to SHUTDOWN_START
,
-DEEP_SLEEP_ENTRY,
or SHUTDOWN_POSTPONE
, an integer value in
-milliseconds is sent to notify the VMCU for how long the AP must postpone shutdown or sleep.
DEEP_SLEEP_ENTRY,
or SHUTDOWN_POSTPONE
, an integer (in milliseconds)
+is sent to notify the VMCU for how long the AP must postpone shutdown or sleep.
int32Values[0]
: VehicleApPowerStateReq
enum value, which represents
the new state into which to transition.int32Values[1]
: VehicleApPowerStateShutdownParam
enum value. This
- value os sent only for a SHUTDOWN_PREPARE
message and transmits to Android the
- options it contains.SHUTDOWN_PREPARE
message and transmits to Android the
+options it contains.
The first integer value represents the new state into which Android is to transit. The semantics
-are defined in types.hal
and provided in the following table:
types.hal
and provided below:
Use Integrator to disable the appropriate wake sources when the device is in suspend mode. Common wake sources include heartbeats, modem, wifi, and Bluetooth. The only valid wake source must @@ -687,14 +683,14 @@ then another wake source to service the modem must be added. In the current desi supplies a file with a list of wake sources to be turned off. The CPMS iterates through this file and manages the turning off and on of the wake sources at suspend time.
-OEMs must be careful to write applications so that they can be shut down quickly and not postpone the process indefinitely.
-hardware/interfaces/automotive/vehicle/2.0 |
||
Sample app to provide some idea about the CarPowerManager . |
+Sample app to provide some idea about the CarPowerManager |
packages/services/Car/tests/EmbeddedKitchenSinkApp/src/com/google/android/car/kitchensink |
libsuspend resides in this directory. | +libsuspend resides in this directory. |
system/core/libsuspend |
This class diagram displays the Java classes and interfaces in the power management system:
- + -Figure 5. Power class diagram
+Figure 5. Power class diagram
-The following graph illustrates which objects have references to other objects. An edge means that the source object holds a reference to the target object. For example, VehicleHAL has a reference to a PropertyHalService object.
- + -Figure 6. Object reference diagram
+Figure 6. Object reference diagram
-