From 3fbb9e0053b81286309c23898fdecd7b933cdf02 Mon Sep 17 00:00:00 2001 From: Android Partner Docs Date: Thu, 31 Jan 2019 16:55:24 -0800 Subject: Docs: Changes to source.android.com - 231881498 Improve image quality in Android P power management conte... by Janet Davies - 231880127 Add links to the hwasan patches. by Android Partner Docs - 231815061 Add instructions for debugging in VS Code by Kenneth Lau - 231791311 Modular Kernels: fix typo by Android Partner Docs - 231790813 Set up: consistently use uppercase 'Python' when referenc... by Android Partner Docs - 231790746 Set up: Build Environment: fix typo by Android Partner Docs - 231681839 Update Camera HAL note by Kenneth Lau - 231660908 Hello, by Aparna Kliebenstein - 231619056 Devsite localized content from translation request 1097090. by Android Partner Docs - 231618944 Devsite localized content from translation request 1094215. by Android Partner Docs - 231618928 Devsite localized content from translation request 552911. by Android Partner Docs - 231618923 Devsite localized content from translation request 1097088. by Android Partner Docs - 231489043 Fix documented kernel config option for enabling ext4 enc... by Android Partner Docs - 231443319 Devsite localized content from translation request 1097084. by Android Partner Docs - 231443304 Devsite localized content from translation request 1097086. by Android Partner Docs - 231438081 Update link to updated zip file by Kenneth Lau - 231426393 Devsite localized content from translation request 1092190. by Android Partner Docs - 231426378 Devsite localized content from translation request 1097087. by Android Partner Docs - 231318520 Correct wrong link to image by Kenneth Lau - 231314863 Update images and zip file. by Kenneth Lau - 231264039 Update images and text by Kenneth Lau - 231243440 Devsite localized content from translation request 1093583. by Android Partner Docs - 231243428 Devsite localized content from translation request 1096727. by Android Partner Docs - 231243410 Devsite localized content from translation request 1093591. by Android Partner Docs - 231243331 Devsite localized content from translation request 1094216. by Android Partner Docs - 231243312 Devsite localized content from translation request 1094057. by Android Partner Docs - 231243304 Devsite localized content from translation request 1093780. by Android Partner Docs - 230975764 Adding Translation links for Janurary Android Bulletin by Luke Haviland PiperOrigin-RevId: 231881498 Change-Id: Ib8f9b5b2277f2ada710cd5ebbfda837c9c8e3d05 --- .../architecture/kernel/modular-kernels.html | 2 +- .../images/automotive_power_class_diagram.png | Bin 206642 -> 141145 bytes .../images/automotive_power_deep_sleep.png | Bin 129342 -> 73006 bytes .../images/automotive_power_deep_sleep_exit.png | Bin 106899 -> 60340 bytes .../images/automotive_power_object_state.png | Bin 64709 -> 39254 bytes .../images/automotive_power_reference_diagram.png | Bin 42141 -> 10636 bytes .../automotive/images/automotive_power_states.png | Bin 58397 -> 25526 bytes en/devices/automotive/power.html | 114 ++++++++++----------- en/devices/camera/camera3.html | 10 +- en/devices/tech/debug/asan.html | 16 ++- en/devices/tech/debug/gdb.html | 42 ++++++++ en/devices/tech/power/values.html | 104 +++++++++++-------- 12 files changed, 176 insertions(+), 112 deletions(-) (limited to 'en/devices') diff --git a/en/devices/architecture/kernel/modular-kernels.html b/en/devices/architecture/kernel/modular-kernels.html index c314a956..a0908b71 100644 --- a/en/devices/architecture/kernel/modular-kernels.html +++ b/en/devices/architecture/kernel/modular-kernels.html @@ -599,7 +599,7 @@ where to load the DT blob from.

Requirements for Device Tree Overlay support (if used):

    -
  • Device should have new device tree blob for overlay (DTBO) partion per +
  • Device should have new device tree blob for overlay (DTBO) partition per kernel image for board–specific DT overlay (for details on the partition format, see DTB/DTBO Partitions. The assumption is that bootloader already knows where and how to load the diff --git a/en/devices/automotive/images/automotive_power_class_diagram.png b/en/devices/automotive/images/automotive_power_class_diagram.png index 736dadb8..ac46c2c3 100644 Binary files a/en/devices/automotive/images/automotive_power_class_diagram.png and b/en/devices/automotive/images/automotive_power_class_diagram.png differ diff --git a/en/devices/automotive/images/automotive_power_deep_sleep.png b/en/devices/automotive/images/automotive_power_deep_sleep.png index 2ccfda75..a4ee79f9 100644 Binary files a/en/devices/automotive/images/automotive_power_deep_sleep.png and b/en/devices/automotive/images/automotive_power_deep_sleep.png differ diff --git a/en/devices/automotive/images/automotive_power_deep_sleep_exit.png b/en/devices/automotive/images/automotive_power_deep_sleep_exit.png index b920eb20..8ab08220 100644 Binary files a/en/devices/automotive/images/automotive_power_deep_sleep_exit.png and b/en/devices/automotive/images/automotive_power_deep_sleep_exit.png differ diff --git a/en/devices/automotive/images/automotive_power_object_state.png b/en/devices/automotive/images/automotive_power_object_state.png index 0e0aba62..32f3145c 100644 Binary files a/en/devices/automotive/images/automotive_power_object_state.png and b/en/devices/automotive/images/automotive_power_object_state.png differ diff --git a/en/devices/automotive/images/automotive_power_reference_diagram.png b/en/devices/automotive/images/automotive_power_reference_diagram.png index 625450f1..8b521c09 100644 Binary files a/en/devices/automotive/images/automotive_power_reference_diagram.png and b/en/devices/automotive/images/automotive_power_reference_diagram.png differ diff --git a/en/devices/automotive/images/automotive_power_states.png b/en/devices/automotive/images/automotive_power_states.png index d0c5cab6..8772354f 100644 Binary files a/en/devices/automotive/images/automotive_power_states.png and b/en/devices/automotive/images/automotive_power_states.png differ diff --git a/en/devices/automotive/power.html b/en/devices/automotive/power.html index f126825d..084a39bb 100644 --- a/en/devices/automotive/power.html +++ b/en/devices/automotive/power.html @@ -21,16 +21,16 @@ limitations under the License. --> -

    Android Automotive (AAE) P introduces a new state – deep sleep – into the AAE P power -management state machine. To implement this state, AAE P provides a new power management service +

    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.

    -

    State transitions are triggered by the Vehicle MCU (VMCU). To enable AAE to communicate with the -VMCU, integrators must implement several components. Integrators are responsible for integrating +

    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.

    -

    Terminology

    +

    Terminology

    These terms are used throughout this document:

    @@ -73,7 +73,7 @@ bringup. Hibernate AKA Suspend to Disk (S2D/S4). The SoC is placed into S4 power mode (hibernate) and RAM content is written to non-volatile media (such as flash or disk) and the entire system is powered -off. Android does not currently implement hibernate. +off. Android does not currently implement hibernate. Media Processor (MP) @@ -86,7 +86,7 @@ off. Android does not currently implement hibernate.< System on a Chip (SoC) Main processor that runs Android, typically supplied by manufacturers such as Intel, Mediatek, -Nvidia, Qualcomm, Renesas, and Texas Instruments. +Nvidia, Qualcomm, Renesas, and Texas Instruments. Suspend @@ -112,15 +112,15 @@ communicates with the VMCU via USB, UART, SPI, and GPIO signals. -

    System design

    +

    System design

    -

    This section describes how AAE represents the application processor's power state and which +

    This section describes how Android 9 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.

    -

    Car power state machine

    +

    Car power state machine

    -

    AAE uses a state machine to represent the power state of the AP. This state machine +

    Android 9 uses a state machine to represent the power state of the AP. This state machine provides these five states, as illustrated below:

    @@ -136,15 +136,15 @@ When display turns on, the ON: DISP OFF state transitions into ON:FULL (and vice SHUTDOWN PREPARE and then transitions to OFF or DEEP SLEEP:

      -
    • Power off
      • -
    • Suspended to RAM
      • +
    • Power off.
      • +
    • Suspended to RAM.

    When this 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.

    -

    Power management modules

    +

    Power management modules

    These five modules comprise the power management system:

    @@ -203,14 +203,14 @@ modules, applications, and services is illustrated below:

    Figure 2. Power components reference diagram

    -

    Typical message sequence

    +

    Typical message sequence

    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:

      -
    • Enter deep sleep
      • -
    • Exit deep sleep
      • +
    • Enter deep sleep.
      • +
    • Exit deep sleep.

    Enter deep sleep

    @@ -262,16 +262,16 @@ provided by the CPM. This method returns these values, as notified from the VMCU

    Figure 4. Exit deep sleep sequence diagram

    -

    Programming interfaces provided by CPM

    +

    Programming interfaces provided by CPM

    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 enables the system software to:

      -
    • Monitor the AP's power state changes
      • -
    • Acquire boot reasons from the CPMS
      • -
    • Request the VMCU to shut down the AP on the next suspend instruction
      • +
    • Monitor power state changes in the AP.
      • +
    • Acquire boot reasons from the CPMS.
      • +
    • Request the VMCU to shut down the AP on the next suspend instruction.

    PowerTestFragment.java in com.google.android.car.kitchensink.power @@ -282,7 +282,7 @@ illustrates how to use these APIs in Java. Use these steps to call the APIs prov

  • Call the appropriate method on the object created in Step 1.
    • -

    Creating a CarPowerManager object

    +

    Creating a CarPowerManager object

    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 @@ -297,7 +297,7 @@ CarPowerManager powerManager = -

    CarPowerStateListener and registration

    +

    CarPowerStateListener and registration

    System applications and services can receive power state change notifications by implementing CarPowerManager.CarPowerStateListener. This interface defines one method @@ -358,7 +358,7 @@ following table:

    -

    CarPowerStateListener unregistration

    +

    CarPowerStateListener unregistration

    To unregister all listener objects registered to CPM, call the clearListener method:

    @@ -367,7 +367,7 @@ powerManager.clearListener(); -

    Boot reason acquisition

    +

    Boot reason acquisition

    To acquire the boot reason, call the getBootReason method, which communicates with the CPMS and returns one of the following five boot reasons:

    @@ -424,29 +424,29 @@ try{

    This method throws a CarNotConnectedException when it fails to communicate with the CPMS.

    -

    Shutdown request on next suspend

    +

    Shutdown request on next suspend

    The requestShutdownOnNextSuspend()method instructs CPMS to shut down instead of deep sleep at the next opportunity.

    -

    System integration on your Android implementation

    +

    System integration on your Android implementation

    Integrators are responsible for implementing the following items:

      -
    • Kernel interface to suspend Android
      • +
    • Kernel interface to suspend Android.
    • The VHAL to:
        -
      • Propagate the initiation of suspend or shutdown from the car to Android
        • -
      • Send the shutdown ready message from Android to the car
        • -
      • Initiate shutdown or suspend of Android via the Linux kernel interface
        • -
      • Propagate the wake reason from the car to Android upon resume from suspend
        • +
      • Propagate the initiation of suspend or shutdown from the car to Android.
        • +
      • Send the shutdown ready message from Android to the car.
        • +
      • Initiate shutdown or suspend of Android via the Linux kernel interface.
        • +
      • Propagate the wake reason from the car to Android upon resume from suspend.
      -
    • Wakesources to be disabled when the device is in suspend
      • +
    • Wakesources to be disabled when the device is in suspend.
    • Applications to shut down quickly enough so as not to indefinitely postpone the shutdown -process
      • +process.
    -

    Kernel interface: /sys/power/state

    +

    Kernel interface: /sys/power/state

    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,15 +455,15 @@ 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.

    -

    VHAL responsibility

    +

    VHAL responsibility

    The VHAL provides an interface between the vehicle network and Android. The VHAL:

      -
    • Propagates the initiation of suspend or shutdown from the car to Android
      • -
    • Sends the shutdown ready message from Android to the car
      • -
    • Initiates the shutdown or suspend of Android via the Linux kernel interface
      • -
    • Propagates the wake reason from the car to Android upon resume from suspend
      • +
    • Propagates the initiation of suspend or shutdown from the car to Android.
      • +
    • Sends the shutdown ready message from Android to the car.
      • +
    • Initiates the shutdown or suspend of Android via the Linux kernel interface.
      • +
    • Propagates the wake reason from the car to Android upon resume from suspend.

    When the CPMS informs the VHAL that it is ready to shut down, the VHAL sends the shutdown ready @@ -503,7 +503,7 @@ instruct the VMCU that it is safe to remove power from the device.

    integers:

      -
    • int32Values[0]: VehicleApPowerStateReport enum of 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.
    @@ -517,7 +517,7 @@ specific descriptions, which are stored in the Value name Description -Second value +Second value @@ -562,7 +562,7 @@ 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 +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.

    AP_POWER_STATE_REQ

    @@ -572,14 +572,14 @@ two integers:

    • int32Values[0]: VehicleApPowerStateReq enum value, which represents -the new state into which to transition
      • -
    • int32Values[1]: VehicleApPowerStateShutdownParam enum value. This is -sent only for a SHUTDOWN_PREPARE message and conveys to Android what options it -contains.
      • +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.

    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:

    +are defined in types.hal and provided in the following table:

    @@ -677,24 +677,24 @@ a specific duration, as specified in VehicleApPowerSetState#SHUTDOW
    -

    Wake sources

    +

    Wake sources

    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 +Common wake sources include heartbeats, modem, wifi, and Bluetooth. The only valid wake source must be an interrupt from the VMCU to wake up the SoC. This assumes that the VMCU can listen to the modem -for remote wakeup events (such as remote engine start). If this functionality is pushed to the AP, +for remote wakeup events (such as remote engine start). If this functionality is pushed to the AP, then another wake source to service the modem must be added. In the current design, the Integrator -supplies a file with a list of wake sources to be turned off. The CPMS iterates through this file +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.

    -

    Applications

    +

    Applications

    OEMs must be careful to write applications so that they can be shut down quickly and not postpone the process indefinitely.

    -

    Appendix

    +

    Appendix

    -

    Directories in the source code tree

    +

    Directories in the source code tree

    @@ -731,7 +731,7 @@ the process indefinitely.

    -

    Class diagram

    +

    Class diagram

    This class diagram displays the Java classes and interfaces in the power management system:

    @@ -739,7 +739,7 @@ the process indefinitely.

    Figure 5. Power class diagram

    -

    Object relationship

    +

    Object relationship

    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 diff --git a/en/devices/camera/camera3.html b/en/devices/camera/camera3.html index bb2e6833..71e90a34 100644 --- a/en/devices/camera/camera3.html +++ b/en/devices/camera/camera3.html @@ -30,7 +30,7 @@ to your underlying camera driver and hardware. Android 8.0 introduced Treble, switching the CameraHal API to a stable interface defined by the HAL Interface Description Language (HIDL). If you have previously developed a camera -HAL module and driver for older versions of Android, be aware of significant +HAL module and driver for Android 7.0 and lower, be aware of significant changes in the camera pipeline.

    Camera HAL3 features

    @@ -84,12 +84,12 @@ may be repeated indefinitely (with setRepeatingRequest()). Captures have priority over repeating requests.

    Camera data model -

    Figure 2. Camera core operation model

    +

    Figure 1. Camera core operation model

    Camera HAL1 overview

    - +

    Version 1 of the camera subsystem was designed as a black box with high-level controls and the following three operating modes:

    @@ -105,7 +105,7 @@ hard to implement new features such as burst mode, which falls between two of the operating modes.

    Camera block diagram -

    Figure 1. Camera components

    +

    Figure 2. Camera components

    Android 7.0 continues to support camera HAL1 as many devices still rely on it. In addition, the Android camera service supports implementing both HALs (1 diff --git a/en/devices/tech/debug/asan.html b/en/devices/tech/debug/asan.html index 9ea32939..29df8b6d 100644 --- a/en/devices/tech/debug/asan.html +++ b/en/devices/tech/debug/asan.html @@ -44,7 +44,8 @@ HWASan is non-deterministic. There are only 256 possible tag values, so there is probability of missing any bug. HWAsan does not have ASan's limited-size redzones for detecting overflows and limited-capacity quarantine for detecting use-after-free, so it does not matter to HWAsan how large the overflow is or how long ago the memory -was deallocated. This makes HWASan better than ASan.

    +was deallocated. This makes HWASan better than ASan. You can read more about +the design of HWAsan.

    Valgrind's Memcheck tool is similar, but ASan also detects stack/global overflows in addition to heap overflows, and is much faster with less memory overhead. Conversely, @@ -60,10 +61,15 @@ instead.

    Using HWAsan

    -

    As of December 2018 only Pixel 2 and Pixel 2 XL are supported. Supporting another device -requires backporting several kernel patches. The Android team is working on getting those into -the common kernel. -You may also need to remove some optional extras to make room on your system partition for the +

    As of February 2019 only Pixel 2 and Pixel 2 XL support HWAsan. The Android team is working on +getting the necessary patches into the common kernel, but for now supporting another device requires +backporting these kernel patches:

    + + +

    You may also need to remove some optional extras to make room on your system partition for the larger libraries. See the walleye_hwasan target for an example.

    Use the following commands to build the entire platform using HWASan:

    diff --git a/en/devices/tech/debug/gdb.html b/en/devices/tech/debug/gdb.html index 49d62aa3..34096fb6 100644 --- a/en/devices/tech/debug/gdb.html +++ b/en/devices/tech/debug/gdb.html @@ -162,5 +162,47 @@ the following property:

    set arm fallback-mode arm # or thumb +

    Debugging with VS Code

    +

    GDB supports debugging platform code on + Visual Studio Code. + You can use the + VS Code debugger frontend instead of the GDB CLI interface to control and + debug native code running on devices.

    +

    Before using VS Code for debugging, make sure you install the + + C/C++ extension.

    +

    To debug code using VS Code:

    +
      +
    1. Ensure all build artifacts (such as symbols) required to run + gdbclient.py are present.
      2. +
    2. +

      Run the following command:

      + 
      gdbclient.py -p pid | -n proc-name | -r ... --setup-forwarding vscode ANY_OTHER_FLAGS
      +

      This prints a JSON object and gdbclient.py continues running. + This is expected; do not kill the gdbclient.py program.

      +
      3. +
    3. In the debugging tab in VS Code, select + add configuration, then select + C/C++ gdb attach. + This opens a launch.json file and adds a new JSON object to a + list. +
      4. +
    4. Delete the newly added debugger configuration.
      5. +
    5. Copy the JSON object printed by gdbclient.py and paste it + into the object you just deleted. Save the changes. +
      6. +
    6. To reload the window to refresh the debugger list, press + Ctrl+Shift+P and type "reload window". +
      7. +
    7. Select the new debugger configuration and press + run. The debugger should connect after 10 to 30 seconds. +
      8. +
    8. When you are done debugging, go to the terminal running + gdbclient.py and press enter to end the + gdbclient.py program. +
      9. +
    +

    After setting up the debugger configuration for the first time, + you can skip steps 3 through 6.

    diff --git a/en/devices/tech/power/values.html b/en/devices/tech/power/values.html index e4c68426..a2ea8388 100644 --- a/en/devices/tech/power/values.html +++ b/en/devices/tech/power/values.html @@ -5,6 +5,7 @@ + {% include "_versions.html" %}