aboutsummaryrefslogtreecommitdiff
path: root/en/devices
diff options
context:
space:
mode:
authorAndroid Partner Docs <noreply@android.com>2019-01-25 14:26:34 -0800
committerMark Hecomovich <mheco@google.com>2019-01-25 14:56:27 -0800
commit964c5956c98fb20ab44ead57e59b5c0ed9f0ab11 (patch)
tree94e1ae7edb82c95a5da83468b6ea104d651850f3 /en/devices
parentd8c39787c5a4061686695502e62c0477b939c633 (diff)
downloadsource.android.com-964c5956c98fb20ab44ead57e59b5c0ed9f0ab11.tar.gz
Docs: Changes to source.android.com
- 230969164 Add details about supported deviceless tests by Android Partner Docs <noreply@android.com> - 230954177 Devsite localized content from translation request 1089952. by Android Partner Docs <noreply@android.com> - 230924636 Devsite localized content from translation request 1092604. by Android Partner Docs <noreply@android.com> - 230924621 Devsite localized content from translation request 1091268. by Android Partner Docs <noreply@android.com> - 230811847 Please review this new content for "Automotive Power Mana... by Janet Davies <janetd@google.com> - 230794111 Add HWASan to the docs ready for bootcamp. by Android Partner Docs <noreply@android.com> - 230779068 Link to NDK docs on DAC from first reference to Make by Android Partner Docs <noreply@android.com> - 230744983 Devsite localized content from translation request 1092191. by Android Partner Docs <noreply@android.com> - 230744981 Devsite localized content from translation request 1093422. by Android Partner Docs <noreply@android.com> - 230744964 Devsite localized content from translation request 1094193. by Android Partner Docs <noreply@android.com> - 230742820 Moving Marshmallow 6.0 to No Release Planned as CTS 6.0 w... by Android Partner Docs <noreply@android.com> - 230614628 Fixed broken links (they were relative and not absolute f... by Christina Nguyen <cqn@google.com> - 230384953 Remove rogue parenthesis by Danielle Roberts <daroberts@google.com> - 230375898 Fix broken links to subpages with absolute paths by Android Partner Docs <noreply@android.com> - 230364707 Devsite localized content from translation request 1093572. by Android Partner Docs <noreply@android.com> - 230364690 Devsite localized content from translation request 1093439. by Android Partner Docs <noreply@android.com> - 230364619 Devsite localized content from translation request 1089936. by Android Partner Docs <noreply@android.com> - 230364605 Devsite localized content from translation request 1086836. by Android Partner Docs <noreply@android.com> - 230364588 Devsite localized content from translation request 1093713. by Android Partner Docs <noreply@android.com> - 230364494 Devsite localized content from translation request 1093448. by Android Partner Docs <noreply@android.com> - 230364465 Devsite localized content from translation request 1091295. by Android Partner Docs <noreply@android.com> - 230364454 Devsite localized content from translation request 1092609. by Android Partner Docs <noreply@android.com> - 230364368 Devsite localized content from translation request 1048174. by Android Partner Docs <noreply@android.com> - 230364354 Devsite localized content from translation request 1047598. by Android Partner Docs <noreply@android.com> - 230364346 Devsite localized content from translation request 1089969. by Android Partner Docs <noreply@android.com> - 230020584 Update the guide for using vendor provided bcc by Android Partner Docs <noreply@android.com> - 229999258 Fix a typo in gsi.html by Android Partner Docs <noreply@android.com> - 229997798 Add file_patterns attribute documentation by Android Partner Docs <noreply@android.com> - 229991256 Update the characters for zh-cn and zh-tw in the Security... by Danielle Roberts <daroberts@google.com> - 229977174 Moving time zones to Updates (from Permissions); also upd... by Heidi von Markham <hvm@google.com> - 229831729 Devsite localized content from translation request 1090171. by Android Partner Docs <noreply@android.com> - 229831714 Devsite localized content from translation request 1090622. by Android Partner Docs <noreply@android.com> - 229831667 Devsite localized content from translation request 1015775. by Android Partner Docs <noreply@android.com> - 229831656 Devsite localized content from translation request 1088392. by Android Partner Docs <noreply@android.com> - 229831644 Devsite localized content from translation request 1090166. by Android Partner Docs <noreply@android.com> - 229581198 Devsite localized content from translation request 1086821. by Android Partner Docs <noreply@android.com> - 229425689 Fixing typos for Shutdown (to shutdown) by Heidi von Markham <hvm@google.com> - 229416134 Update a paragraph in the permission model section of the... by Luke Haviland <lhaviland@google.com> - 229402835 Devsite localized content from translation request 553155. by Android Partner Docs <noreply@android.com> - 229305053 Devsite localized content from translation request 1091266. by Android Partner Docs <noreply@android.com> - 229305046 Devsite localized content from translation request 1091273. by Android Partner Docs <noreply@android.com> - 229245843 Devsite localized content from translation request 1015221. by Android Partner Docs <noreply@android.com> - 228916961 Fix typo by Kenneth Lau <kennethlau@google.com> - 228796242 Change "Optional" to "Required" by Kenneth Lau <kennethlau@google.com> - 228720589 Devsite localized content from translation request 1090636. by Android Partner Docs <noreply@android.com> - 228612958 Added Joshua Laney's information to November security ack... by Luke Haviland <lhaviland@google.com> - 228585561 Update versions file by Kenneth Lau <kennethlau@google.com> - 228557861 Devsite localized content from translation request 1089965. by Android Partner Docs <noreply@android.com> - 228541590 Fix HTML. by Android Partner Docs <noreply@android.com> - 228525372 Replace unresolved variable reference in localized files. by Android Partner Docs <noreply@android.com> - 228439111 Add missing < by Android Partner Docs <noreply@android.com> - 228436522 Adding the January Android bulletin acknowledgements by Luke Haviland <lhaviland@google.com> - 228407590 Correct the naming of EGL extension, and point the link t... by Android Partner Docs <noreply@android.com> - 228395277 Rename Test Config to Build Config to better reflect Soon... by Android Partner Docs <noreply@android.com> - 228340013 Devsite localized content from translation request 1044284. by Android Partner Docs <noreply@android.com> - 228340002 Devsite localized content from translation request 1048178. by Android Partner Docs <noreply@android.com> - 228339974 Devsite localized content from translation request 1089289. by Android Partner Docs <noreply@android.com> - 228339806 Devsite localized content from translation request 999875. by Android Partner Docs <noreply@android.com> - 228339785 Devsite localized content from translation request 1046259. by Android Partner Docs <noreply@android.com> - 228339757 Devsite localized content from translation request 1049718. by Android Partner Docs <noreply@android.com> - 228267452 Add information on gdbclient.py by Kenneth Lau <kennethlau@google.com> - 228261450 Adding the Android AOSP links to the Android January secu... by Luke Haviland <lhaviland@google.com> - 228247613 Fill in security levels for December 2018 builds. by Android Partner Docs <noreply@android.com> - 228241115 Add January 2019 builds. by Android Partner Docs <noreply@android.com> - 228208289 Remove _toc-*.yaml files that are no longer used due to r... by Christina Nguyen <cqn@google.com> - 228205865 Devsite localized content from translation request 1048626. by Android Partner Docs <noreply@android.com> - 228205856 Devsite localized content from translation request 1048155. by Android Partner Docs <noreply@android.com> - 228205845 Devsite localized content from translation request 1047886. by Android Partner Docs <noreply@android.com> - 228186179 Adding the January 2019 security Android/Pixel bulletins. by Luke Haviland <lhaviland@google.com> - 228183717 Add BCC native stack dump documentation by Android Partner Docs <noreply@android.com> - 228181974 Devsite localized content from translation request 1089935. by Android Partner Docs <noreply@android.com> - 227911224 Add more information on cts-dev and also --skip-precondit... by Android Partner Docs <noreply@android.com> - 227772142 Update image path by Danielle Roberts <daroberts@google.com> - 227719040 Fix broken links by Kenneth Lau <kennethlau@google.com> - 227715850 Devsite localized content from translation request 1045494. by Android Partner Docs <noreply@android.com> - 227715841 Devsite localized content from translation request 1044265. by Android Partner Docs <noreply@android.com> - 227715826 Devsite localized content from translation request 1087340. by Android Partner Docs <noreply@android.com> - 227709199 Fix path on images by Danielle Roberts <daroberts@google.com> - 227620512 Devsite localized content from translation request 1032286. by Android Partner Docs <noreply@android.com> - 227620508 Devsite localized content from translation request 1087344. by Android Partner Docs <noreply@android.com> - 227620485 Devsite localized content from translation request 1087104. by Android Partner Docs <noreply@android.com> - 227620481 Devsite localized content from translation request 1046261. by Android Partner Docs <noreply@android.com> - 227620479 Devsite localized content from translation request 1087239. by Android Partner Docs <noreply@android.com> - 227617540 Devsite localized content from translation request 1007762. by Android Partner Docs <noreply@android.com> - 227617535 Devsite localized content from translation request 1089145. by Android Partner Docs <noreply@android.com> - 227617491 Devsite localized content from translation request 1087109. by Android Partner Docs <noreply@android.com> - 227617482 Devsite localized content from translation request 1047584. by Android Partner Docs <noreply@android.com> - 227617480 Devsite localized content from translation request 1089449. by Android Partner Docs <noreply@android.com> - 227617378 Devsite localized content from translation request 1087099. by Android Partner Docs <noreply@android.com> - 227610447 Add variable tag to CTS downloads page by Danielle Roberts <daroberts@google.com> - 227595909 Add link to camera section on CTS setup page by Kenneth Lau <kennethlau@google.com> - 227595777 Change title to title case by Kenneth Lau <kennethlau@google.com> - 227546776 Newline between function and param descriptions. by Android Partner Docs <noreply@android.com> - 227546753 Small edits to system best practices by Danielle Roberts <daroberts@google.com> - 227033873 Document "run cts-dev" command, present CTS V2 first by Android Partner Docs <noreply@android.com> - 226772000 Devsite localized content from translation request 1041964. by Android Partner Docs <noreply@android.com> - 226552899 Announce Adiantum on SAC home page by Danielle Roberts <daroberts@google.com> - 226550934 Add Adiantum docs to encryption section by Danielle Roberts <daroberts@google.com> - 226530870 Devsite localized content from translation request 1046265. by Android Partner Docs <noreply@android.com> - 226497667 Devsite localized content from translation request 1047878. by Android Partner Docs <noreply@android.com> (And 26 more changes) PiperOrigin-RevId: 230969164 Change-Id: I2bf51b3793304247e04b953816961605fe1ba4bf
Diffstat (limited to 'en/devices')
-rw-r--r--en/devices/_toc-frameworks.yaml429
-rw-r--r--en/devices/_toc-interaction.yaml2
-rw-r--r--en/devices/_toc-permissions.yaml30
-rw-r--r--en/devices/_toc-systems.yaml429
-rw-r--r--en/devices/_toc-tech.yaml269
-rw-r--r--en/devices/_toc-update.yaml2
-rw-r--r--en/devices/_translation.yaml10
-rw-r--r--en/devices/architecture/hidl/code-style.html7
-rw-r--r--en/devices/architecture/vndk/renderscript.html8
-rw-r--r--en/devices/automotive/images/automotive_power_class_diagram.pngbin0 -> 206642 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_deep_sleep.pngbin0 -> 129342 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_deep_sleep_exit.pngbin0 -> 106899 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_object_state.pngbin0 -> 64709 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_reference_diagram.pngbin0 -> 42141 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_states.pngbin0 -> 58397 bytes
-rw-r--r--en/devices/automotive/power.html753
-rw-r--r--en/devices/bootloader/boot-reason.html4
-rw-r--r--en/devices/camera/camera3_requests_hal.html2
-rw-r--r--en/devices/camera/external-usb-cameras.md3
-rw-r--r--en/devices/sensors/index.html186
-rw-r--r--en/devices/tech/admin/index.html73
-rw-r--r--en/devices/tech/connect/call-notification.html2
-rw-r--r--en/devices/tech/connect/wifi-passpoint.md2
-rw-r--r--en/devices/tech/debug/asan.html98
-rw-r--r--en/devices/tech/debug/gdb.html24
-rw-r--r--en/devices/tech/debug/native_stack_dump.md179
-rw-r--r--en/devices/tech/display/color-mgmt.html2
-rw-r--r--en/devices/tech/ota/index.html71
28 files changed, 1232 insertions, 1353 deletions
diff --git a/en/devices/_toc-frameworks.yaml b/en/devices/_toc-frameworks.yaml
deleted file mode 100644
index 5f91e99d..00000000
--- a/en/devices/_toc-frameworks.yaml
+++ /dev/null
@@ -1,429 +0,0 @@
-toc:
-- title: Overview
- path: /devices/
-- title: Architecture
- section:
- - title: Overview
- path: /devices/architecture/
- - title: Hardware Abstraction Layer (HAL)
- path: /devices/architecture/hal
- - title: HAL Types
- path: /devices/architecture/hal-types
- - title: Treble
- path: /devices/architecture/treble
- - title: Kernel
- section:
- - title: Overview
- path: /devices/architecture/kernel/
- - title: Stable Releases & Updates
- path: /devices/architecture/kernel/releases
- - title: Android Common Kernels
- path: /devices/architecture/kernel/android-common
- - title: Modular Kernel Requirements
- path: /devices/architecture/kernel/modular-kernels
- - title: Interface Requirements
- path: /devices/architecture/kernel/reqs-interfaces
- - title: Configuration
- path: /devices/architecture/kernel/config
- - title: Kernel Hardening
- path: /devices/architecture/kernel/hardening
- - title: SquashFS
- path: /devices/architecture/kernel/squashfs
- - title: LLDB Debugging
- path: /devices/architecture/kernel/lldb-debug
- - title: Network Tests
- path: /devices/architecture/kernel/network_tests
- - title: HIDL (General)
- section:
- - title: Overview
- path: /devices/architecture/hidl/
- - title: Interfaces & Packages
- path: /devices/architecture/hidl/interfaces
- - title: Interface Hashing
- path: /devices/architecture/hidl/hashing
- - title: Services & Data Transfer
- path: /devices/architecture/hidl/services
- - title: Fast Message Queue
- path: /devices/architecture/hidl/fmq
- - title: Using Binder IPC
- path: /devices/architecture/hidl/binder-ipc
- - title: Network Stack Configuration Tools
- path: /devices/architecture/hidl/network-stack
- - title: Threading Models
- path: /devices/architecture/hidl/threading
- - title: Converting Modules
- path: /devices/architecture/hidl/converting
- - title: Data Types
- path: /devices/architecture/hidl/types
- - title: Versioning
- path: /devices/architecture/hidl/versioning
- - title: Code Style Guide
- path: /devices/architecture/hidl/code-style
- - title: HIDL (C++)
- section:
- - title: Overview
- path: /devices/architecture/hidl-cpp/
- - title: Packages
- path: /devices/architecture/hidl-cpp/packages
- - title: Interfaces
- path: /devices/architecture/hidl-cpp/interfaces
- - title: Data Types
- path: /devices/architecture/hidl-cpp/types
- - title: Functions
- path: /devices/architecture/hidl-cpp/functions
- - title: HIDL (Java)
- section:
- - title: Overview
- path: /devices/architecture/hidl-java/
- - title: Data Types
- path: /devices/architecture/hidl-java/types
- - title: Interface Errors & Methods
- path: /devices/architecture/hidl-java/interfaces
- - title: Exporting Constants
- path: /devices/architecture/hidl-java/constants
- - title: ConfigStore HAL
- section:
- - title: Overview
- path: /devices/architecture/configstore/
- - title: Creating the HAL Interface
- path: /devices/architecture/configstore/interface
- - title: Implementing the Service
- path: /devices/architecture/configstore/service
- - title: Client-Side Usage
- path: /devices/architecture/configstore/client
- - title: Adding Classes & Items
- path: /devices/architecture/configstore/add-class-item
- - title: Device Tree Overlays
- section:
- - title: Overview
- path: /devices/architecture/dto/
- - title: Implementing DTO
- path: /devices/architecture/dto/implement
- - title: DTO Syntax
- path: /devices/architecture/dto/syntax
- - title: Compiling & Verifying
- path: /devices/architecture/dto/compile
- - title: Using Multiple DTs
- path: /devices/architecture/dto/multiple
- - title: DTB/DTBO Partition Format
- path: /devices/architecture/dto/partitions
- - title: Optimizing DTO
- path: /devices/architecture/dto/optimize
- - title: Vendor NDK
- section:
- - title: Overview
- path: /devices/architecture/vndk/
- - title: Enabling the VNDK
- path: /devices/architecture/vndk/enabling
- - title: VNDK Build System Support
- path: /devices/architecture/vndk/build-system
- - title: VNDK Extensions
- path: /devices/architecture/vndk/extensions
- - title: VNDK Definition Tool
- path: /devices/architecture/vndk/deftool
- - title: Linker Namespace
- path: /devices/architecture/vndk/linker-namespace
- - title: Directories, Rules, and sepolicy
- path: /devices/architecture/vndk/dir-rules-sepolicy
- - title: Renderscript
- path: /devices/architecture/vndk/renderscript
- - title: Vendor Interface Object
- section:
- - title: Overview
- path: /devices/architecture/vintf/
- - title: VINTF Object Data
- path: /devices/architecture/vintf/objects
- - title: Compatibility Matrices
- path: /devices/architecture/vintf/comp-matrices
- - title: Matching Rules
- path: /devices/architecture/vintf/match-rules
- - title: Resources
- path: /devices/architecture/vintf/resources
-- title: Audio
- section:
- - title: Overview
- path: /devices/audio/
- - title: Terminology
- path: /devices/audio/terminology
- - title: Implementation
- section:
- - title: Overview
- path: /devices/audio/implement
- - title: Policy Configuration
- path: /devices/audio/implement-policy
- - title: Shared Library
- path: /devices/audio/implement-shared-library
- - title: Pre-processing Effects
- path: /devices/audio/implement-pre-processing
- - title: Data Formats
- path: /devices/audio/data_formats
- - title: Attributes
- path: /devices/audio/attributes
- - title: AAudio and MMAP
- path: /devices/audio/aaudio
- - title: Warmup
- path: /devices/audio/warmup
- - title: Latency
- section:
- - title: Overview
- path: /devices/audio/latency
- - title: Contributors
- path: /devices/audio/latency_contrib
- - title: Design
- path: /devices/audio/latency_design
- - title: Measure
- path: /devices/audio/latency_measure
- - title: Light Testing Circuit
- path: /devices/audio/testing_circuit
- - title: Audio Loopback Dongle
- path: /devices/audio/loopback
- - title: Measurements
- path: /devices/audio/latency_measurements
- - title: Applications
- path: /devices/audio/latency_app
- - title: Priority Inversion
- path: /devices/audio/avoiding_pi
- - title: Sample Rate Conversion
- path: /devices/audio/src
- - title: Debugging
- path: /devices/audio/debugging
- - title: MIDI
- section:
- - title: Overview
- path: /devices/audio/midi
- - title: MIDI Architecture
- path: /devices/audio/midi_arch
- - title: MIDI Test Procedure
- path: /devices/audio/midi_test
- - title: USB Digital Audio
- path: /devices/audio/usb
- - title: TV Audio
- path: /devices/audio/tv
-- title: Automotive
- section:
- - title: Overview
- path: /devices/automotive/
- - title: Vehicle Properties
- path: /devices/automotive/properties
- - title: Camera HAL
- path: /devices/automotive/camera-hal
- - title: IVI Connectivity
- path: /devices/automotive/ivi_connectivity
-- title: Bluetooth
- section:
- - title: Overview
- path: /devices/bluetooth
- - title: Services
- path: /devices/bluetooth/services
- - title: Bluetooth Low Energy
- path: /devices/bluetooth/ble
- - title: BLE Advertising
- path: /devices/bluetooth/ble_advertising
- - title: Verifying and Debugging
- path: /devices/bluetooth/verifying_debugging
- - title: HCI Requirements
- path: /devices/bluetooth/hci_requirements
-- title: Bootloader
- section:
- - title: Overview
- path: /devices/bootloader
- - title: Partitions and Images
- path: /devices/bootloader/partitions-images
- - title: Flashing and Updating
- path: /devices/bootloader/flashing-updating
- - title: Unlocking and Trusty
- path: /devices/bootloader/unlock-trusty
-- title: Camera
- section:
- - title: Overview
- path: /devices/camera/
- - title: Camera3
- path: /devices/camera/camera3
- - title: HAL Subsystem
- path: /devices/camera/camera3_requests_hal
- - title: Metadata and Controls
- path: /devices/camera/camera3_metadata
- - title: 3A Modes and State
- path: /devices/camera/camera3_3Amodes
- - title: Output and Cropping
- path: /devices/camera/camera3_crop_reprocess
- - title: Errors and Streams
- path: /devices/camera/camera3_error_stream
- - title: Request Creation
- path: /devices/camera/camera3_requests_methods
- - title: Version Support
- path: /devices/camera/versioning
-- title: DRM
- path: /devices/drm
-- title: Graphics
- section:
- - title: Overview
- path: /devices/graphics/
- - title: Architecture
- section:
- - title: Overview
- path: /devices/graphics/architecture
- - title: BufferQueue
- path: /devices/graphics/arch-bq-gralloc
- - title: SurfaceFlinger and HWC
- path: /devices/graphics/arch-sf-hwc
- - title: Surface and SurfaceHolder
- path: /devices/graphics/arch-sh
- - title: OpenGL ES
- path: /devices/graphics/arch-egl-opengl
- - title: OpenGLRenderer Configuration
- path: /devices/graphics/renderer
- - title: Vulkan
- path: /devices/graphics/arch-vulkan
- - title: SurfaceView
- path: /devices/graphics/arch-sv-glsv
- - title: SurfaceTexture
- path: /devices/graphics/arch-st
- - title: TextureView
- path: /devices/graphics/arch-tv
- - title: Game Loops
- path: /devices/graphics/arch-gameloops
- - title: Implementation
- section:
- - title: Overview
- path: /devices/graphics/implement
- - title: Hardware Composer HAL
- path: /devices/graphics/implement-hwc
- - title: VSYNC
- path: /devices/graphics/implement-vsync
- - title: Vulkan
- path: /devices/graphics/implement-vulkan
- - title: Virtual Displays
- path: /devices/graphics/implement-vdisplays
- - title: OpenGL ES Testing
- section:
- - title: Overview
- path: /devices/graphics/testing
- - title: Building Test Programs
- path: /devices/graphics/build-tests
- - title: Porting the Test Framework
- path: /devices/graphics/port-tests
- - title: Running the Tests
- path: /devices/graphics/run-tests
- - title: Automating the Tests
- path: /devices/graphics/automate-tests
- - title: Using Special Test Groups
- path: /devices/graphics/test-groups
- - title: Integrating with Android CTS
- path: /devices/graphics/cts-integration
-- title: Input
- section:
- - title: Overview
- path: /devices/input/
- - title: Key Layout Files
- path: /devices/input/key-layout-files
- - title: Key Character Map Files
- path: /devices/input/key-character-map-files
- - title: Input Device Configuration Files
- path: /devices/input/input-device-configuration-files
- - title: Migration Guide
- path: /devices/input/migration-guide
- - title: Keyboard Devices
- path: /devices/input/keyboard-devices
- - title: Touch Devices
- path: /devices/input/touch-devices
- - title: Getevent
- path: /devices/input/getevent
- - title: Validate Keymaps
- path: /devices/input/validate-keymaps
-- title: Media
- section:
- - title: Overview
- path: /devices/media/
- - title: Framework Hardening
- path: /devices/media/framework-hardening
- - title: SoC Dependencies
- path: /devices/media/soc
- - title: OEM Dependencies
- path: /devices/media/oem
-- title: Peripherals
- path: /devices/accessories
- section:
- - title: Audio Accessories
- section:
- - title: Overview
- path: /devices/accessories/audio
- - title: 3.5 mm Headset
- section:
- - title: Headset Spec
- path: /devices/accessories/headset/plug-headset-spec
- - title: Device Spec
- path: /devices/accessories/headset/jack-headset-spec
- - title: USB Headset
- section:
- - title: Headset Spec
- path: /devices/accessories/headset/usb-headset-spec
- - title: Adapter Spec
- path: /devices/accessories/headset/usb-adapter
- - title: Device Spec
- path: /devices/accessories/headset/usb-device
- - title: Expected Behavior
- path: /devices/accessories/headset/expected-behavior
- - title: Testing
- path: /devices/accessories/headset/testing
- - title: Custom Accessories
- section:
- - title: Overview
- path: /devices/accessories/custom
- - title: AOA
- section:
- - title: Overview
- path: /devices/accessories/protocol
- - title: AOA 2.0
- path: /devices/accessories/aoa2
- - title: AOA 1.0
- path: /devices/accessories/aoa
- - title: Stylus
- path: /devices/accessories/stylus
-- title: Sensors
- section:
- - title: Overview
- path: /devices/sensors/
- - title: Sensor Stack
- path: /devices/sensors/sensor-stack
- - title: Reporting Modes
- path: /devices/sensors/report-modes
- - title: Suspend Mode
- path: /devices/sensors/suspend-mode
- - title: Power Consumption
- path: /devices/sensors/power-use
- - title: Interaction
- path: /devices/sensors/interaction
- - title: HAL Interface
- path: /devices/sensors/hal-interface
- - title: Batching
- path: /devices/sensors/batching
- - title: Sensor Types
- path: /devices/sensors/sensor-types
- - title: Version Deprecation
- path: /devices/sensors/versioning
-- title: Storage
- section:
- - title: Overview
- path: /devices/storage/
- - title: Traditional Storage
- path: /devices/storage/traditional
- - title: Adoptable Storage
- path: /devices/storage/adoptable
- - title: Device Configuration
- path: /devices/storage/config
- - title: Configuration Examples
- path: /devices/storage/config-example
- - title: Faster Statistics
- path: /devices/storage/faster-stats
-- title: TV
- section:
- - title: Overview
- path: /devices/tv
- - title: HDMI-CEC Control Service
- path: /devices/tv/hdmi-cec
- - title: Reference TV App
- path: /devices/tv/reference-tv-app
- - title: Customize the TV App
- path: /devices/tv/customize-tv-app
-
diff --git a/en/devices/_toc-interaction.yaml b/en/devices/_toc-interaction.yaml
index 252a7a3b..20c440c7 100644
--- a/en/devices/_toc-interaction.yaml
+++ b/en/devices/_toc-interaction.yaml
@@ -41,6 +41,8 @@ toc:
path: /devices/automotive/ivi_connectivity
- title: Vehicle Properties
path: /devices/automotive/properties
+ - title: Power Management
+ path: /devices/automotive/power
- title: Flash Wear Management
path: /devices/tech/perf/flash-wear
- title: Neural Networks
diff --git a/en/devices/_toc-permissions.yaml b/en/devices/_toc-permissions.yaml
index 5857602e..51bb9585 100644
--- a/en/devices/_toc-permissions.yaml
+++ b/en/devices/_toc-permissions.yaml
@@ -1,17 +1,15 @@
toc:
- - title: Privileged Permission Whitelist
- path: /devices/tech/config/perms-whitelist
- - title: Runtime Permissions
- path: /devices/tech/config/runtime_perms
- - title: Time Zone Rules
- path: /devices/tech/config/timezone-rules
- - title: Ambient Capabilities
- path: /devices/tech/config/ambient
- - title: Discretionary Access Control
- path: /devices/tech/config/filesystem
- - title: Library Namespaces
- path: /devices/tech/config/namespaces_libraries
- - title: USB HAL
- path: /devices/tech/config/usb-hal
- - title: Visual Voicemail
- path: /devices/tech/config/voicemail
+- title: Privileged Permission Whitelist
+ path: /devices/tech/config/perms-whitelist
+- title: Runtime Permissions
+ path: /devices/tech/config/runtime_perms
+- title: Ambient Capabilities
+ path: /devices/tech/config/ambient
+- title: Discretionary Access Control
+ path: /devices/tech/config/filesystem
+- title: Library Namespaces
+ path: /devices/tech/config/namespaces_libraries
+- title: USB HAL
+ path: /devices/tech/config/usb-hal
+- title: Visual Voicemail
+ path: /devices/tech/config/voicemail
diff --git a/en/devices/_toc-systems.yaml b/en/devices/_toc-systems.yaml
deleted file mode 100644
index 5f91e99d..00000000
--- a/en/devices/_toc-systems.yaml
+++ /dev/null
@@ -1,429 +0,0 @@
-toc:
-- title: Overview
- path: /devices/
-- title: Architecture
- section:
- - title: Overview
- path: /devices/architecture/
- - title: Hardware Abstraction Layer (HAL)
- path: /devices/architecture/hal
- - title: HAL Types
- path: /devices/architecture/hal-types
- - title: Treble
- path: /devices/architecture/treble
- - title: Kernel
- section:
- - title: Overview
- path: /devices/architecture/kernel/
- - title: Stable Releases & Updates
- path: /devices/architecture/kernel/releases
- - title: Android Common Kernels
- path: /devices/architecture/kernel/android-common
- - title: Modular Kernel Requirements
- path: /devices/architecture/kernel/modular-kernels
- - title: Interface Requirements
- path: /devices/architecture/kernel/reqs-interfaces
- - title: Configuration
- path: /devices/architecture/kernel/config
- - title: Kernel Hardening
- path: /devices/architecture/kernel/hardening
- - title: SquashFS
- path: /devices/architecture/kernel/squashfs
- - title: LLDB Debugging
- path: /devices/architecture/kernel/lldb-debug
- - title: Network Tests
- path: /devices/architecture/kernel/network_tests
- - title: HIDL (General)
- section:
- - title: Overview
- path: /devices/architecture/hidl/
- - title: Interfaces & Packages
- path: /devices/architecture/hidl/interfaces
- - title: Interface Hashing
- path: /devices/architecture/hidl/hashing
- - title: Services & Data Transfer
- path: /devices/architecture/hidl/services
- - title: Fast Message Queue
- path: /devices/architecture/hidl/fmq
- - title: Using Binder IPC
- path: /devices/architecture/hidl/binder-ipc
- - title: Network Stack Configuration Tools
- path: /devices/architecture/hidl/network-stack
- - title: Threading Models
- path: /devices/architecture/hidl/threading
- - title: Converting Modules
- path: /devices/architecture/hidl/converting
- - title: Data Types
- path: /devices/architecture/hidl/types
- - title: Versioning
- path: /devices/architecture/hidl/versioning
- - title: Code Style Guide
- path: /devices/architecture/hidl/code-style
- - title: HIDL (C++)
- section:
- - title: Overview
- path: /devices/architecture/hidl-cpp/
- - title: Packages
- path: /devices/architecture/hidl-cpp/packages
- - title: Interfaces
- path: /devices/architecture/hidl-cpp/interfaces
- - title: Data Types
- path: /devices/architecture/hidl-cpp/types
- - title: Functions
- path: /devices/architecture/hidl-cpp/functions
- - title: HIDL (Java)
- section:
- - title: Overview
- path: /devices/architecture/hidl-java/
- - title: Data Types
- path: /devices/architecture/hidl-java/types
- - title: Interface Errors & Methods
- path: /devices/architecture/hidl-java/interfaces
- - title: Exporting Constants
- path: /devices/architecture/hidl-java/constants
- - title: ConfigStore HAL
- section:
- - title: Overview
- path: /devices/architecture/configstore/
- - title: Creating the HAL Interface
- path: /devices/architecture/configstore/interface
- - title: Implementing the Service
- path: /devices/architecture/configstore/service
- - title: Client-Side Usage
- path: /devices/architecture/configstore/client
- - title: Adding Classes & Items
- path: /devices/architecture/configstore/add-class-item
- - title: Device Tree Overlays
- section:
- - title: Overview
- path: /devices/architecture/dto/
- - title: Implementing DTO
- path: /devices/architecture/dto/implement
- - title: DTO Syntax
- path: /devices/architecture/dto/syntax
- - title: Compiling & Verifying
- path: /devices/architecture/dto/compile
- - title: Using Multiple DTs
- path: /devices/architecture/dto/multiple
- - title: DTB/DTBO Partition Format
- path: /devices/architecture/dto/partitions
- - title: Optimizing DTO
- path: /devices/architecture/dto/optimize
- - title: Vendor NDK
- section:
- - title: Overview
- path: /devices/architecture/vndk/
- - title: Enabling the VNDK
- path: /devices/architecture/vndk/enabling
- - title: VNDK Build System Support
- path: /devices/architecture/vndk/build-system
- - title: VNDK Extensions
- path: /devices/architecture/vndk/extensions
- - title: VNDK Definition Tool
- path: /devices/architecture/vndk/deftool
- - title: Linker Namespace
- path: /devices/architecture/vndk/linker-namespace
- - title: Directories, Rules, and sepolicy
- path: /devices/architecture/vndk/dir-rules-sepolicy
- - title: Renderscript
- path: /devices/architecture/vndk/renderscript
- - title: Vendor Interface Object
- section:
- - title: Overview
- path: /devices/architecture/vintf/
- - title: VINTF Object Data
- path: /devices/architecture/vintf/objects
- - title: Compatibility Matrices
- path: /devices/architecture/vintf/comp-matrices
- - title: Matching Rules
- path: /devices/architecture/vintf/match-rules
- - title: Resources
- path: /devices/architecture/vintf/resources
-- title: Audio
- section:
- - title: Overview
- path: /devices/audio/
- - title: Terminology
- path: /devices/audio/terminology
- - title: Implementation
- section:
- - title: Overview
- path: /devices/audio/implement
- - title: Policy Configuration
- path: /devices/audio/implement-policy
- - title: Shared Library
- path: /devices/audio/implement-shared-library
- - title: Pre-processing Effects
- path: /devices/audio/implement-pre-processing
- - title: Data Formats
- path: /devices/audio/data_formats
- - title: Attributes
- path: /devices/audio/attributes
- - title: AAudio and MMAP
- path: /devices/audio/aaudio
- - title: Warmup
- path: /devices/audio/warmup
- - title: Latency
- section:
- - title: Overview
- path: /devices/audio/latency
- - title: Contributors
- path: /devices/audio/latency_contrib
- - title: Design
- path: /devices/audio/latency_design
- - title: Measure
- path: /devices/audio/latency_measure
- - title: Light Testing Circuit
- path: /devices/audio/testing_circuit
- - title: Audio Loopback Dongle
- path: /devices/audio/loopback
- - title: Measurements
- path: /devices/audio/latency_measurements
- - title: Applications
- path: /devices/audio/latency_app
- - title: Priority Inversion
- path: /devices/audio/avoiding_pi
- - title: Sample Rate Conversion
- path: /devices/audio/src
- - title: Debugging
- path: /devices/audio/debugging
- - title: MIDI
- section:
- - title: Overview
- path: /devices/audio/midi
- - title: MIDI Architecture
- path: /devices/audio/midi_arch
- - title: MIDI Test Procedure
- path: /devices/audio/midi_test
- - title: USB Digital Audio
- path: /devices/audio/usb
- - title: TV Audio
- path: /devices/audio/tv
-- title: Automotive
- section:
- - title: Overview
- path: /devices/automotive/
- - title: Vehicle Properties
- path: /devices/automotive/properties
- - title: Camera HAL
- path: /devices/automotive/camera-hal
- - title: IVI Connectivity
- path: /devices/automotive/ivi_connectivity
-- title: Bluetooth
- section:
- - title: Overview
- path: /devices/bluetooth
- - title: Services
- path: /devices/bluetooth/services
- - title: Bluetooth Low Energy
- path: /devices/bluetooth/ble
- - title: BLE Advertising
- path: /devices/bluetooth/ble_advertising
- - title: Verifying and Debugging
- path: /devices/bluetooth/verifying_debugging
- - title: HCI Requirements
- path: /devices/bluetooth/hci_requirements
-- title: Bootloader
- section:
- - title: Overview
- path: /devices/bootloader
- - title: Partitions and Images
- path: /devices/bootloader/partitions-images
- - title: Flashing and Updating
- path: /devices/bootloader/flashing-updating
- - title: Unlocking and Trusty
- path: /devices/bootloader/unlock-trusty
-- title: Camera
- section:
- - title: Overview
- path: /devices/camera/
- - title: Camera3
- path: /devices/camera/camera3
- - title: HAL Subsystem
- path: /devices/camera/camera3_requests_hal
- - title: Metadata and Controls
- path: /devices/camera/camera3_metadata
- - title: 3A Modes and State
- path: /devices/camera/camera3_3Amodes
- - title: Output and Cropping
- path: /devices/camera/camera3_crop_reprocess
- - title: Errors and Streams
- path: /devices/camera/camera3_error_stream
- - title: Request Creation
- path: /devices/camera/camera3_requests_methods
- - title: Version Support
- path: /devices/camera/versioning
-- title: DRM
- path: /devices/drm
-- title: Graphics
- section:
- - title: Overview
- path: /devices/graphics/
- - title: Architecture
- section:
- - title: Overview
- path: /devices/graphics/architecture
- - title: BufferQueue
- path: /devices/graphics/arch-bq-gralloc
- - title: SurfaceFlinger and HWC
- path: /devices/graphics/arch-sf-hwc
- - title: Surface and SurfaceHolder
- path: /devices/graphics/arch-sh
- - title: OpenGL ES
- path: /devices/graphics/arch-egl-opengl
- - title: OpenGLRenderer Configuration
- path: /devices/graphics/renderer
- - title: Vulkan
- path: /devices/graphics/arch-vulkan
- - title: SurfaceView
- path: /devices/graphics/arch-sv-glsv
- - title: SurfaceTexture
- path: /devices/graphics/arch-st
- - title: TextureView
- path: /devices/graphics/arch-tv
- - title: Game Loops
- path: /devices/graphics/arch-gameloops
- - title: Implementation
- section:
- - title: Overview
- path: /devices/graphics/implement
- - title: Hardware Composer HAL
- path: /devices/graphics/implement-hwc
- - title: VSYNC
- path: /devices/graphics/implement-vsync
- - title: Vulkan
- path: /devices/graphics/implement-vulkan
- - title: Virtual Displays
- path: /devices/graphics/implement-vdisplays
- - title: OpenGL ES Testing
- section:
- - title: Overview
- path: /devices/graphics/testing
- - title: Building Test Programs
- path: /devices/graphics/build-tests
- - title: Porting the Test Framework
- path: /devices/graphics/port-tests
- - title: Running the Tests
- path: /devices/graphics/run-tests
- - title: Automating the Tests
- path: /devices/graphics/automate-tests
- - title: Using Special Test Groups
- path: /devices/graphics/test-groups
- - title: Integrating with Android CTS
- path: /devices/graphics/cts-integration
-- title: Input
- section:
- - title: Overview
- path: /devices/input/
- - title: Key Layout Files
- path: /devices/input/key-layout-files
- - title: Key Character Map Files
- path: /devices/input/key-character-map-files
- - title: Input Device Configuration Files
- path: /devices/input/input-device-configuration-files
- - title: Migration Guide
- path: /devices/input/migration-guide
- - title: Keyboard Devices
- path: /devices/input/keyboard-devices
- - title: Touch Devices
- path: /devices/input/touch-devices
- - title: Getevent
- path: /devices/input/getevent
- - title: Validate Keymaps
- path: /devices/input/validate-keymaps
-- title: Media
- section:
- - title: Overview
- path: /devices/media/
- - title: Framework Hardening
- path: /devices/media/framework-hardening
- - title: SoC Dependencies
- path: /devices/media/soc
- - title: OEM Dependencies
- path: /devices/media/oem
-- title: Peripherals
- path: /devices/accessories
- section:
- - title: Audio Accessories
- section:
- - title: Overview
- path: /devices/accessories/audio
- - title: 3.5 mm Headset
- section:
- - title: Headset Spec
- path: /devices/accessories/headset/plug-headset-spec
- - title: Device Spec
- path: /devices/accessories/headset/jack-headset-spec
- - title: USB Headset
- section:
- - title: Headset Spec
- path: /devices/accessories/headset/usb-headset-spec
- - title: Adapter Spec
- path: /devices/accessories/headset/usb-adapter
- - title: Device Spec
- path: /devices/accessories/headset/usb-device
- - title: Expected Behavior
- path: /devices/accessories/headset/expected-behavior
- - title: Testing
- path: /devices/accessories/headset/testing
- - title: Custom Accessories
- section:
- - title: Overview
- path: /devices/accessories/custom
- - title: AOA
- section:
- - title: Overview
- path: /devices/accessories/protocol
- - title: AOA 2.0
- path: /devices/accessories/aoa2
- - title: AOA 1.0
- path: /devices/accessories/aoa
- - title: Stylus
- path: /devices/accessories/stylus
-- title: Sensors
- section:
- - title: Overview
- path: /devices/sensors/
- - title: Sensor Stack
- path: /devices/sensors/sensor-stack
- - title: Reporting Modes
- path: /devices/sensors/report-modes
- - title: Suspend Mode
- path: /devices/sensors/suspend-mode
- - title: Power Consumption
- path: /devices/sensors/power-use
- - title: Interaction
- path: /devices/sensors/interaction
- - title: HAL Interface
- path: /devices/sensors/hal-interface
- - title: Batching
- path: /devices/sensors/batching
- - title: Sensor Types
- path: /devices/sensors/sensor-types
- - title: Version Deprecation
- path: /devices/sensors/versioning
-- title: Storage
- section:
- - title: Overview
- path: /devices/storage/
- - title: Traditional Storage
- path: /devices/storage/traditional
- - title: Adoptable Storage
- path: /devices/storage/adoptable
- - title: Device Configuration
- path: /devices/storage/config
- - title: Configuration Examples
- path: /devices/storage/config-example
- - title: Faster Statistics
- path: /devices/storage/faster-stats
-- title: TV
- section:
- - title: Overview
- path: /devices/tv
- - title: HDMI-CEC Control Service
- path: /devices/tv/hdmi-cec
- - title: Reference TV App
- path: /devices/tv/reference-tv-app
- - title: Customize the TV App
- path: /devices/tv/customize-tv-app
-
diff --git a/en/devices/_toc-tech.yaml b/en/devices/_toc-tech.yaml
deleted file mode 100644
index 211a990e..00000000
--- a/en/devices/_toc-tech.yaml
+++ /dev/null
@@ -1,269 +0,0 @@
-toc:
-- title: Overview
- path: /devices/tech/
-- title: ART and Dalvik
- section:
- - title: Overview
- path: /devices/tech/dalvik
- - title: Improvements
- path: /devices/tech/dalvik/improvements
- - title: Bytecode Format
- path: /devices/tech/dalvik/dalvik-bytecode
- - title: Dex Format
- path: /devices/tech/dalvik/dex-format
- - title: Instruction Formats
- path: /devices/tech/dalvik/instruction-formats
- - title: Constraints
- path: /devices/tech/dalvik/constraints
- - title: Configuration
- path: /devices/tech/dalvik/configure
- - title: Garbage Collection
- path: /devices/tech/dalvik/gc-debug
- - title: JIT Compilation
- path: /devices/tech/dalvik/jit-compiler
-- title: Configuration
- section:
- - title: Overview
- path: /devices/tech/config/
- - title: Ambient Capabilities
- path: /devices/tech/config/ambient
- - title: Carrier Customization
- section:
- - title: Carrier Configuration
- path: /devices/tech/config/carrier
- - title: APN and CarrierConfig
- path: /devices/tech/config/update
- - title: UICC
- path: /devices/tech/config/uicc
- - title: File DAC Configuration
- path: /devices/tech/config/filesystem
- - title: Namespaces for Libraries
- path: /devices/tech/config/namespaces_libraries
- - title: Privileged Permission Whitelist
- path: /devices/tech/config/perms-whitelist
- - title: Runtime Permissions
- path: /devices/tech/config/runtime_perms
- - title: Time Zone Rules
- path: /devices/tech/config/timezone-rules
- - title: USB HAL
- path: /devices/tech/config/usb-hal
- - title: Visual Voicemail
- path: /devices/tech/config/voicemail
-- title: Connectivity
- section:
- - title: Overview
- path: /devices/tech/connect/
- - title: Block Phone Numbers
- path: /devices/tech/connect/block-numbers
- - title: Call Notifications
- path: /devices/tech/connect/call-notification
- - title: Data Saver Mode
- path: /devices/tech/connect/data-saver
- - title: Emergency Affordance
- path: /devices/tech/connect/emergency-affordance
- - title: Host Card Emulation of FeliCa
- path: /devices/tech/connect/felica
- - title: Out-of-Balance Users
- path: /devices/tech/connect/oob-users
- - title: Network Connectivity Tests
- path: /devices/tech/connect/connect_tests
- - title: Radio Interface Layer (RIL)
- path: /devices/tech/connect/ril
- - title: Wi-Fi Aware
- path: /devices/tech/connect/wifi-aware
-- title: Data Usage
- section:
- - title: Overview
- path: /devices/tech/datausage/
- - title: Network Interface Statistics Overview
- path: /devices/tech/datausage/iface-overview
- - title: Excluding Network Types from Data Usage
- path: /devices/tech/datausage/excluding-network-types
- - title: Tethering Data
- path: /devices/tech/datausage/tethering-data
- - title: Usage Cycle Reset Dates
- path: /devices/tech/datausage/usage-cycle-resets-dates
- - title: Kernel Overview
- path: /devices/tech/datausage/kernel-overview
- - title: Data Usage Tags Explained
- path: /devices/tech/datausage/tags-explained
- - title: Kernel Changes
- path: /devices/tech/datausage/kernel-changes
-- title: Debugging
- section:
- - title: Overview
- path: /devices/tech/debug/
- - title: Diagnosing Native Crashes
- path: /devices/tech/debug/native-crash
- - title: Evaluating Performance
- section:
- - title: Overview
- path: /devices/tech/debug/eval_perf
- - title: Understanding systrace
- path: /devices/tech/debug/systrace
- - title: Using ftrace
- path: /devices/tech/debug/ftrace
- - title: Identifying Capacity Jank
- path: /devices/tech/debug/jank_capacity
- - title: Identifying Jitter Jank
- path: /devices/tech/debug/jank_jitter
- - title: Fuzzing and Sanitizing
- section:
- - title: Overview
- path: /devices/tech/debug/fuzz-sanitize
- - title: AddressSanitizer
- path: /devices/tech/debug/asan
- - title: LLVM Sanitizers
- path: /devices/tech/debug/sanitizers
- - title: Build kernel with KASAN+KCOV
- path: /devices/tech/debug/kasan-kcov
- - title: Fuzzing with libFuzzer
- path: /devices/tech/debug/libfuzzer
- - title: Using GDB
- path: /devices/tech/debug/gdb
- - title: Native Memory Use
- path: /devices/tech/debug/native-memory
- - title: Rescue Party
- path: /devices/tech/debug/rescue-party
- - title: Storaged
- path: /devices/tech/debug/storaged
- - title: Strace
- path: /devices/tech/debug/strace
- - title: Valgrind
- path: /devices/tech/debug/valgrind
-- title: Device Administration
- section:
- - title: Overview
- path: /devices/tech/admin/
- - title: Implementation
- path: /devices/tech/admin/implement
- - title: Multiple Users
- path: /devices/tech/admin/multi-user
- - title: Managed Profiles
- path: /devices/tech/admin/managed-profiles
- - title: Provisioning
- path: /devices/tech/admin/provision
- - title: Multiuser Apps
- path: /devices/tech/admin/multiuser-apps
- - title: Enterprise Telephony
- path: /devices/tech/admin/enterprise-telephony
- - title: Testing Device Provisioning
- path: /devices/tech/admin/testing-provision
- - title: Testing Device Administration
- path: /devices/tech/admin/testing-setup
-- title: Display
- section:
- - title: Overview
- path: /devices/tech/display/
- - title: Adaptive Icons
- path: /devices/tech/display/adaptive-icons
- - title: App Shortcuts
- path: /devices/tech/display/app-shortcuts
- - title: Circular Icons
- path: /devices/tech/display/circular-icons
- - title: Color Management
- path: /devices/tech/display/color-mgmt
- - title: Do Not Disturb
- path: /devices/tech/display/dnd
- - title: HDR Video
- path: /devices/tech/display/hdr
- - title: Multi-Window
- path: /devices/tech/display/multi-window
- - title: Night Light
- path: /devices/tech/display/night-light
- - title: Picture-in-picture
- path: /devices/tech/display/pip
- - title: Retail Demo Mode
- path: /devices/tech/display/retail-mode
- - title: Split-Screen Interactions
- path: /devices/tech/display/split-screen
- - title: TEXTCLASSIFIER
- path: /devices/tech/display/textclassifier
- - title: Widgets & Shortcuts
- path: /devices/tech/display/widgets-shortcuts
-- title: OTA Updates
- section:
- - title: Overview
- path: /devices/tech/ota/
- - title: OTA Tools
- path: /devices/tech/ota/tools
- - title: Signing Builds for Release
- path: /devices/tech/ota/sign_builds
- - title: Reducing OTA Size
- path: /devices/tech/ota/reduce_size
- - title: A/B System Updates
- section:
- - title: Overview
- path: /devices/tech/ota/ab/
- - title: Implementing A/B Updates
- path: /devices/tech/ota/ab/ab_implement
- - title: Frequently Asked Questions
- path: /devices/tech/ota/ab/ab_faqs
- - title: Non-A/B System Updates
- section:
- - title: Overview
- path: /devices/tech/ota/nonab/
- - title: Block-Based OTA
- path: /devices/tech/ota/nonab/block
- - title: Inside OTA Packages
- path: /devices/tech/ota/nonab/inside_packages
- - title: Device-Specific Code
- path: /devices/tech/ota/nonab/device_code
-- title: Performance
- section:
- - title: Overview
- path: /devices/tech/perf/
- - title: Boot Times
- path: /devices/tech/perf/boot-times
- - title: Flash Wear Management
- path: /devices/tech/perf/flash-wear
- - title: Low RAM
- path: /devices/tech/perf/low-ram
- - title: Task Snapshots
- path: /devices/tech/perf/task-snapshots
-- title: Power
- section:
- - title: Overview
- path: /devices/tech/power/
- - title: Power Management
- path: /devices/tech/power/mgmt
- - title: Performance Management
- path: /devices/tech/power/performance
- - title: Component Power
- path: /devices/tech/power/component
- - title: Device Power
- path: /devices/tech/power/device
- - title: Power Values
- path: /devices/tech/power/values
-- title: Settings Menu
- section:
- - title: Overview
- path: /devices/tech/settings/
- - title: Patterns and Components
- path: /devices/tech/settings/patterns-components
- - title: Information Architecture
- path: /devices/tech/settings/info-architecture
- - title: Personalized Settings
- path: /devices/tech/settings/personalized
- - title: Universal Search
- path: /devices/tech/settings/universal-search
- - title: Design Guidelines
- path: /devices/tech/settings/settings-guidelines
-- title: Testing Infrastructure
- section:
- - title: Overview
- path: /devices/tech/test_infra/tradefed/
- - title: Start Here
- path: /devices/tech/test_infra/tradefed/fundamentals
- - title: Machine Setup
- path: /devices/tech/test_infra/tradefed/fundamentals/machine_setup
- - title: Working with Devices
- path: /devices/tech/test_infra/tradefed/fundamentals/devices
- - title: Test Lifecycle
- path: /devices/tech/test_infra/tradefed/fundamentals/lifecycle
- - title: Option Handling
- path: /devices/tech/test_infra/tradefed/fundamentals/options
- - title: An End-to-End Example
- path: /devices/tech/test_infra/tradefed/full_example
- - title: Package Index
- path: /reference/tradefed/
diff --git a/en/devices/_toc-update.yaml b/en/devices/_toc-update.yaml
index e3b86dde..5158be28 100644
--- a/en/devices/_toc-update.yaml
+++ b/en/devices/_toc-update.yaml
@@ -25,3 +25,5 @@ toc:
path: /devices/tech/ota/nonab/inside_packages
- title: Device-Specific Code
path: /devices/tech/ota/nonab/device_code
+- title: Time Zone Rules
+ path: /devices/tech/config/timezone-rules
diff --git a/en/devices/_translation.yaml b/en/devices/_translation.yaml
deleted file mode 100644
index 32d1e74b..00000000
--- a/en/devices/_translation.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-enable_continuous_translation: true
-title: Android Open Source Project Devices tab
-description: Translations for SAC devices tab
-language:
-- zh-CN
-cc:
-- sac-doc-leads+translation@google.com
-reviewer:
-- daroberts
-product: Android
diff --git a/en/devices/architecture/hidl/code-style.html b/en/devices/architecture/hidl/code-style.html
index 5f787d71..5f451851 100644
--- a/en/devices/architecture/hidl/code-style.html
+++ b/en/devices/architecture/hidl/code-style.html
@@ -52,12 +52,14 @@ interface <a href="#interface-names">IFoo</a> {
/**
* This is a <a href="#comments">multiline docstring</a>.
+ *
* <a href="#return">@return</a> result 0 if successful, nonzero otherwise.
*/
<a href="#function-declarations">foo() generates (FooStatus result);</a>
/**
* Restart controller by power cycle.
+ *
* <a href="#param">@param</a> bar callback interface that&#8230;
* @return result 0 if successful, nonzero otherwise.
*/
@@ -69,6 +71,7 @@ interface <a href="#interface-names">IFoo</a> {
/**
* The bar function.
+ *
* <a href="#param">@param</a> <a href="#functions">clientCallback</a> callback after function is called
* @param baz related baz object
* @param data input data blob
@@ -107,7 +110,7 @@ package android.hardware.foo@1.0;
<h2 id=naming>Naming conventions</h2>
<p>Function names, variable names, and filenames should be descriptive; avoid
over-abbreviation. Treat acronyms as words (e.g., use <code>INfc</code> instead
-of <code>INFC</code>.</p>
+of <code>INFC</code>).</p>
<h3 id=dir-structure>Directory structure and file naming</h3>
<p>The directory structure should appear as follows:</p>
@@ -455,6 +458,7 @@ the package directory).</p>
interface IFooController {
/**
* Opens the controller.
+ *
* @return status HAL_FOO_OK if successful.
*/
open() generates (FooStatus status);
@@ -478,6 +482,7 @@ should be followed by the name of the return value then the docstring.</li>
<pre class="prettyprint">
/**
* Explain what foo does.
+ *
* @param arg1 explain what arg1 is
* @param arg2 explain what arg2 is
* @return ret1 explain what ret1 is
diff --git a/en/devices/architecture/vndk/renderscript.html b/en/devices/architecture/vndk/renderscript.html
index a2b5a8bd..873b24a2 100644
--- a/en/devices/architecture/vndk/renderscript.html
+++ b/en/devices/architecture/vndk/renderscript.html
@@ -533,14 +533,8 @@ namespace.sphal.link.rs.shared_libs = libRS_internal.so
</p>
<pre class="prettyprint">
-device/vendor_foo/device_bar/sepolicy/file.te:
-type renderscript_exec, exec_type, file_type;
-
-device/vendor_foo/device_bar/sepolicy/app.te:
-allow appdomain renderscript_exec:file { read open getattr execute execute_no_trans };
-
device/vendor_foo/device_bar/sepolicy/file_contexts:
-/vendor/bin/bcc u:object_r:renderscript_exec:s0
+/vendor/bin/bcc u:object_r:same_process_hal_file:s0
</pre>
<h3 id="legacy-devices">Legacy devices</h3>
diff --git a/en/devices/automotive/images/automotive_power_class_diagram.png b/en/devices/automotive/images/automotive_power_class_diagram.png
new file mode 100644
index 00000000..736dadb8
--- /dev/null
+++ b/en/devices/automotive/images/automotive_power_class_diagram.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_deep_sleep.png b/en/devices/automotive/images/automotive_power_deep_sleep.png
new file mode 100644
index 00000000..2ccfda75
--- /dev/null
+++ b/en/devices/automotive/images/automotive_power_deep_sleep.png
Binary files 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
new file mode 100644
index 00000000..b920eb20
--- /dev/null
+++ b/en/devices/automotive/images/automotive_power_deep_sleep_exit.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_object_state.png b/en/devices/automotive/images/automotive_power_object_state.png
new file mode 100644
index 00000000..0e0aba62
--- /dev/null
+++ b/en/devices/automotive/images/automotive_power_object_state.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_reference_diagram.png b/en/devices/automotive/images/automotive_power_reference_diagram.png
new file mode 100644
index 00000000..625450f1
--- /dev/null
+++ b/en/devices/automotive/images/automotive_power_reference_diagram.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_states.png b/en/devices/automotive/images/automotive_power_states.png
new file mode 100644
index 00000000..d0c5cab6
--- /dev/null
+++ b/en/devices/automotive/images/automotive_power_states.png
Binary files differ
diff --git a/en/devices/automotive/power.html b/en/devices/automotive/power.html
new file mode 100644
index 00000000..f126825d
--- /dev/null
+++ b/en/devices/automotive/power.html
@@ -0,0 +1,753 @@
+<html devsite>
+ <head>
+ <title>Power Management</title>
+ <meta name="project_path" value="/_project.yaml" />
+ <meta name="book_path" value="/_book.yaml" />
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android Automotive (AAE) P introduces a new state – <em>deep sleep</em> – into the AAE P power
+management state machine. To implement this state, AAE P provides a new power management service
+and interface: <code>CarPowerManagementService</code> and <code>CarPowerManager</code>.</p>
+
+<p>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
+with the VHAL and the kernel implementation. Integrators are also responsible for disabling wake
+sources and ensuring that shutdowns are not postponed indefinitely.</p>
+
+<h2>Terminology</h2>
+
+<p>These terms are used throughout this document:</p>
+
+<table>
+<thead>
+<tr>
+<th>Term</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Application Processor (AP)</td>
+<td>Part of the System on Chip (SoC).</td>
+</tr>
+<tr>
+<td>Board Support Processor (BSP)</td>
+<td>All of the chip and hardware specific code
+necessary for the product to work. Typically provided by the SoC vendor and hardware
+manufacturer. This covers items such as device drivers, the PMIC sequencing code, and SoC
+bringup.</td>
+</tr>
+<tr>
+<td>CarPowerManager (CPM)</td>
+<td>Exposes an API for applications to register for power state changes.</td>
+</tr>
+<tr>
+<td>CarPowerManagementService (CPMS)</td>
+<td>Implements the car power state machine, interfaces with VHAL, and performs the final calls to <code>suspend()</code> and <code>shutdown()</code>.</td>
+</tr>
+<tr>
+<td>CarServiceHelperService</strong> (<strong>CSHS</strong>)</td>
+<td>Provides a hook into SystemServer for OK, provided that is the Car Service.</td>
+</tr>
+<tr>
+<td>General Purpose Input / Output (GPIO)</td>
+<td>A digital signal pin for general purpose use.</td>
+</tr>
+<tr>
+<td>Hibernate</td>
+<td>AKA <em>Suspend to Disk</em> (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 <strong><em>not</em></strong> currently implement hibernate.</td>
+</tr>
+<tr>
+<td>Media Processor (MP)</td>
+<td>See System on Chip (SoC).</td>
+</tr>
+<tr>
+<td>Power Management Integrated Circuit (PMIC)</td>
+<td>Chip used to manage power requirements for the host system.</td>
+</tr>
+<tr>
+<td>System on a Chip (SoC)</td>
+<td>Main processor that runs Android, typically supplied by manufacturers such as Intel, Mediatek,
+Nvidia, Qualcomm, Renesas, and Texas Instruments. </td>
+</tr>
+<tr>
+<td>Suspend</td>
+<td>AKA <em>Suspend to RAM</em> (S2R or STR). The SoC is placed into S3 power mode and the CPU is
+powered off while RAM remains powered on.</td>
+</tr>
+<tr>
+<td>Vehicle HAL (VHAL)</td>
+<td>The Android API used to interface with the vehicle network. The Tier 1 partner or OEM is
+responsible for writing this module. The vehicle network can use any physical layer (such as CAN,
+LIN, MOST, and Ethernet). The VHAL abstracts this vehicle network to enable Android to interact with
+the vehicle.</td>
+</tr>
+<tr>
+<td>Vehicle Interface Processor (VIP)</td>
+<td>See Vehicle MCU.</td>
+</tr>
+<tr>
+<td>Vehicle MCU (VMCU)</td>
+<td>The microcontroller that provides the interface between the vehicle network and the SoC. The SoC
+communicates with the VMCU via USB, UART, SPI, and GPIO signals. </td>
+</tr>
+</tbody>
+</table>
+
+<h2>System design</h2>
+
+<p>This section describes how AAE 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.</p>
+
+<h3>Car power state machine</h3>
+
+<p>AAE uses a <em>state machine</em> to represent the power state of the AP. This state machine
+provides these five states, as illustrated below:
+
+<p><img src="/devices/automotive/images/automotive_power_states.png"></p>
+
+<p><b>Figure 1</b>. Car power state machine</p>
+
+<p>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
+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).</p>
+
+<p>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:</p>
+
+<ul>
+<li>Power off</li>
+<li>Suspended to RAM</li>
+</ul>
+
+<p>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.</p>
+
+<h3>Power management modules</h3>
+
+<p>These five modules comprise the power management system:</p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Module name</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>CarPowerManager</td>
+<td>Java/C++ API</td>
+</tr>
+<tr>
+<td>CarPowerManagementService</td>
+<td>Responsible for coordinating the sleep/suspend power state</td>
+</tr>
+<tr>
+<td>Vehicle HAL</td>
+<td>Interface to VMCU</td>
+</tr>
+<tr>
+<td>libsuspend</td>
+<td>Native library to place the device into suspend</td>
+</tr>
+<tr>
+<td>Kernel</td>
+<td>Suspend to RAM implementation</td>
+</tr>
+</tbody>
+</table>
+
+<p>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 <code>/sys/power/state</code>. AAE is
+suspended by writing <code>mem</code> to this file. </p>
+
+<p><code>libsuspend</code> is a native library that implements <code>forcesuspend()</code>. This
+function uses <code>/sys/power/state</code> to suspend AAE. <code>forcesuspend()</code> can be
+called from system services, including CPMS.</p>
+
+<p>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
+occurs. This service also uses <code>libsuspend</code> and the VHAL to send messages to the
+hardware. </p>
+
+<p>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
+means it is available to privileged applications <em>only</em>. The relationship between these five
+modules, applications, and services is illustrated below:</p>
+
+<p><img src="/devices/automotive/images/automotive_power_reference_diagram.png"></p>
+
+<p><b>Figure 2</b>. Power components reference diagram</p>
+
+<h3>Typical message sequence</h3>
+
+<p>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:</p>
+
+<ul>
+<li>Enter deep sleep</li>
+<li>Exit deep sleep</li>
+</ul>
+
+<h4>Enter deep sleep</h4>
+
+<p>Only the VMCU can initiate deep sleep. Once deep sleep is initiated, the VMCU sends a
+notification to the CPMS via the VHAL. The CPMS changes the state to SHUTDOWN PREPARE and
+broadcasts this state transition to all observers (the applications and services that monitor
+CPMS) by calling the <code>onStateChanged()</code> method with a new state ID provided by the
+CPM.</p>
+
+The CPM mediates between the applications/services and the CPMS. The <code>onStateChanged()</code>
+method for the applications/services is synchronously invoked in the CPM's
+<code>onStateChanged()</code> 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
+<code>onStateChanged()</code> method runs asynchronously. Therefore, some delay occurs between the
+calling of the <code>onStateChanged()</code> 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
+postpone requests to the VHAL.</p>
+
+<p>Once the CPMS receives the finished message from all CPM objects, the CPMS sends
+<code>AP_POWER_STATE_REPORT</code> to the VHAL, which then notifies the VMCU that the AP is ready to
+suspend. The CPMS also calls its suspend method, which suspends the kernel with a feature provided
+by <code>libsuspend</code>.</p>
+
+<p>The entire sequence described above is illustrated in the following sequence diagram:
+
+<p><img src="/devices/automotive/images/automotive_power_deep_sleep.png"></p>
+
+<p><b>Figure 3</b>. Enter deep sleep sequence diagram</p>
+
+<h4>Exit deep sleep</h4>
+
+<p>The sequence to exit suspend is also initiated by the VMCU. The VMCU turns on the AP and the AP
+restores the suspended Android from RAM. The CPMS uses <code>onStateChanged</code>method to send a
+<code>SUSPEND_EXIT</code> message to applications and services when it wakes up. </p>
+
+To access the reason, applications and services can call the <code>getBootReason()</code> method
+provided by the CPM. This method returns these values, as notified from the VMCU to the VHAL:</p>
+
+<ul>
+<li>BOOT_REASON_USER_POWER_ON</li>
+<li>BOOT_REASON_DOOR_UNLOCK</li>
+<li>BOOT_REASON_TIMER</li>
+<li>BOOT_REASON_DOOR_OPEN</li>
+<li>BOOT_REASON_REMOTE_START</li>
+</ul>
+
+<p><img src="/devices/automotive/images/automotive_power_deep_sleep_exit.png"></p>
+
+<p><b>Figure 4</b>. Exit deep sleep sequence diagram</p>
+
+<h2>Programming interfaces provided by CPM</h2>
+
+<p>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:</p>
+
+<ul>
+<li>Monitor the AP's power state changes</li>
+<li>Acquire boot reasons from the CPMS</li>
+<li>Request the VMCU to shut down the AP on the next suspend instruction</li>
+</ul>
+
+<p><code>PowerTestFragment.java</code> in <code>com.google.android.car.kitchensink.power</code>
+illustrates how to use these APIs in Java. Use these steps to call the APIs provided by the CPM:</p>
+
+<ol>
+<li>To acquire the CPM instance, call the Car API.</li>
+<li>Call the appropriate method on the object created in Step 1.</li>
+</ol>
+
+<h3>Creating a CarPowerManager object</h3>
+
+<p>To create a CPM object, call the Car object's <code>getCarManager()</code> method. This method is
+a facade used to create CM objects. Specify <code>android.car.Car.POWER_SERVICE</code> as an
+argument to create a CPM object.</p>
+
+<div>
+<pre class="prettyprint">
+Car car = Car.createCar(this, carCallbacks);
+car.connect();
+CarPowerManager powerManager =
+ (CarPowerManager)car.getCarManager(android.car.Car.POWER_SERVICE);
+</pre>
+</div>
+
+<h2>CarPowerStateListener and registration</h2>
+
+<p>System applications and services can receive power state change notifications by implementing
+<code>CarPowerManager.CarPowerStateListener</code>. This interface defines one method
+<code>onStateChanged()</code>, which is a callback function invoked when the power state of CPMS
+is changed. The following example defines a new anonymous class that implements the interface:</p>
+
+<div>
+<pre class="prettyprint">
+private final CarPowerManager.CarPowerStateListener listener =
+ new CarPowerManager.CarPowerStateListener () {
+ @Override
+ public void onStateChanged(int state) {
+ Log.i(TAG, "onStateChanged() state = " + state);
+ }
+};
+</pre>
+</div>
+
+<p>To instruct this listener object to monitor a power state transition, create a new execution
+thread and register the listener and this thread to the PM object: </p>
+
+<div>
+<pre class="prettyprint">
+executer = new ThreadPerTaskExecuter();
+powerManager.setListener(powerListener, executer);
+</pre>
+</div>
+
+<p>When the power state is changed, the <code>onStateChanged()</code> 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 <code>CarPowerManager.CarPowerStateListene</code>r and is shown in the
+following table:</p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Name</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>SHUTDOWN_CANCELED</td>
+<td>Shutdown is canceled and power state is returned to the normal state.</td>
+</tr>
+<tr>
+<td>SHUTDOWN_ENTER</td>
+<td>Enter the shutdown state. Applications are expected to clean up and be ready to shutdown.</td>
+</tr>
+<tr>
+<td>SUSPEND_ENTER</td>
+<td>Enter the suspend state. Applications are expected to clean up and be ready to suspend.</td>
+</tr>
+<tr>
+<td>SUSPEND_EXIT</td>
+<td>Wake up from suspend or resume from a cancelled suspend.</td>
+</tr>
+</tbody>
+</table>
+
+<h3>CarPowerStateListener unregistration</h3>
+
+<p>To unregister all listener objects registered to CPM, call the <code>clearListener</code> method:</p>
+
+<p><pre class="prettyprint">
+powerManager.clearListener();
+</pre>
+</div>
+
+<h3>Boot reason acquisition</h3>
+
+<p>To acquire the boot reason, call the <code>getBootReason</code> method, which communicates with
+the CPMS and returns one of the following five boot reasons:</p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Name</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>BOOT_REASON_USER_POWER_ON</td>
+<td>A user presses the power key or rotates the ignition switch to boot the device.</td>
+</tr>
+<tr>
+<td>BOOT_REASON_DOOR_UNLOCK</td>
+<td>Door unlocks, which causes the device to boot.</td>
+</tr>
+<tr>
+<td>BOOT_REASON_TIMER</td>
+<td>Timer expires and vehicle wakes up the AP.</td>
+</tr>
+<tr>
+<td>BOOT_REASON_DOOR_OPEN</td>
+<td>Door opens, which causes the device to boot.</td>
+</tr>
+<tr>
+<td>BOOT_REASON_REMOTE_START</td>
+<td>User activates remote start.</td>
+</tr>
+</tbody>
+</table>
+
+<p>These boot reasons are defined in the CPM. The following sample code demonstrates boot reason
+acquisition:</p>
+
+<div>
+<pre class="prettyprint">
+try{
+ int bootReason = carPowerManager.getBootReason();
+ if (bootReason == CarPowerManager.BOOT_REASON_TIMER){
+ doSomething;
+ }else{
+ doSomethingElse();
+ }
+}catch(CarNotConnectedException e){
+ Log.e("Failed to getBootReason()" + e);
+}
+</pre>
+</div>
+
+<p>This method throws a <code>CarNotConnectedException</code> when it fails to communicate with the
+CPMS.</p>
+
+<h3>Shutdown request on next suspend</h3>
+
+<p>The <code>requestShutdownOnNextSuspend()</code>method instructs CPMS to shut down instead of deep
+sleep at the next opportunity.</p>
+
+<h2>System integration on your Android implementation</h2>
+
+<p>Integrators are responsible for implementing the following items:</p>
+
+<ul>
+<li>Kernel interface to suspend Android</li>
+<li>The VHAL to:<ul type="circle">
+<li>Propagate the initiation of suspend or shutdown from the car to Android</li>
+<li>Send the shutdown ready message from Android to the car</li>
+<li>Initiate shutdown or suspend of Android via the Linux kernel interface</li>
+<li>Propagate the wake reason from the car to Android upon resume from suspend</li>
+</ul>
+<li>Wakesources to be disabled when the device is in suspend</li>
+<li>Applications to shut down quickly enough so as not to indefinitely postpone the shutdown
+process</li>
+</ul>
+
+<h3>Kernel interface: /sys/power/state</h3>
+
+<p>First, implement the Linux suspend power state. Android places a device into suspend mode when
+an application or service writes <code>mem</code> into a file located at
+<code>/sys/power/state.</code> This function may include the sending of a GPIO to the VMCU to notify
+the VMCU that the device has shut down completely. The Integrator is also responsible for removing
+any race conditions between VHAL sending the final message to the VMCU and the system going into
+suspend or shutdown mode.</p>
+
+<h3>VHAL responsibility</h3>
+
+<p>The VHAL provides an interface between the vehicle network and Android. The VHAL:</p>
+
+<ul>
+<li>Propagates the initiation of suspend or shutdown from the car to Android</li>
+<li>Sends the shutdown ready message from Android to the car</li>
+<li>Initiates the shutdown or suspend of Android via the Linux kernel interface</li>
+<li>Propagates the wake reason from the car to Android upon resume from suspend</li>
+</ul>
+
+<p>When the CPMS informs the VHAL that it is ready to shut down, the VHAL sends the shutdown ready
+message to the VMCU. Typically, on-chip peripherals such as UART, SPI, and USB transmit the
+message. Once the message has been sent, the VHAL calls the kernel command to suspend or shutdown
+the device. Before doing so, in the case of a shutdown, the VHAL or BSP may toggle a GPIO to
+instruct the VMCU that it is safe to remove power from the device.</p>
+
+<p>The VHAL must support the following properties, which control power management via the VHAL:</p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Name</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>AP_POWER_STATE_REPORT</td>
+<td>Android reports state transitions to the VMCU with this property, using VehicleApPowerStateSet enum values.</td>
+</tr>
+<tr>
+<td>AP_POWER_STATE_REQ</td>
+<td>The VMCU uses this property to instruct Android to transition to different power states, using VehicleApPowerStateReq enum values.</td>
+</tr>
+<tr>
+<td>AP_POWER_BOOTUP_REASON</td>
+<td>The VMCU reports the wake reason to Android, using the VehicleApPowerBootupReason enum values.</td>
+</tr>
+</tbody>
+</table>
+
+<h4>AP_POWER_STATE_REPORT</h4>
+
+<p>Use this property to report Android's current power management state.This property contains two
+integers:</p>
+
+<ul>
+<li><code>int32Values[0]</code>: <code>VehicleApPowerStateReport</code> enum of current state </li>
+<li><code>int32Values[1]</code>: Time in milliseconds to postpone or sleep/shutdown. This value
+depends on the first value.</li>
+</ul>
+
+<p>The first value can take one of the following values. <code>Types.hal</code> contains more
+specific descriptions, which are stored in the
+<code>hardware/interfaces/automotive/vehicle/2.0.</code></p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Value name</strong></th>
+<th><strong>Description</strong></th>
+<th><strong>Second value</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>BOOT_COMPLETE</td>
+<td>AP has completed boot up and can start shutdown.</td>
+<td></td>
+</tr>
+<tr>
+<td>DEEP_SLEEP_ENTRY</td>
+<td>AP is entering the deep sleep state.</td>
+<td>Must be set</td>
+</tr>
+<tr>
+<td>DEEP_SLEEP_EXIT</td>
+<td>AP is exiting the deep sleep state.</td>
+<td></td>
+</tr>
+<tr>
+<td>SHUTDOWN_POSTPONE</td>
+<td>Android is requesting to postpone shutdown .</td>
+<td>Must be set</td>
+</tr>
+<tr>
+<td>SHUTDOWN_START</td>
+<td>AP is starting shutdown. The VMCU can turn on AP after the time specified in the second
+value.</td>
+<td>Must be set</td>
+</tr>
+<tr>
+<td>DISPLAY_OFF</td>
+<td>User has requested to turn off the display of the head unit.</td>
+<td></td>
+</tr>
+<tr>
+<td>DISPLAY_ON</td>
+<td>User has requested to turn on the display of the head unit.</td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+<p>The state can be set asynchronously (in the case of <code>BOOT_COMPLETE</code>) or in response to
+a request via the VMCU. When the state is set to <code>SHUTDOWN_START</code>,
+<code>DEEP_SLEEP_ENTRY,</code> or <code>SHUTDOWN_POSTPONE</code>, an integer value in
+milliseconds is sent to notify the VMCU for how long the AP must postpone shutdown or sleep.</p>
+
+<h4>AP_POWER_STATE_REQ</h4>
+
+<p>This property is sent by the VMCU to transition Android into a different power state and contains
+two integers:</p>
+
+<ul>
+<li><code>int32Values[0]</code>: <code>VehicleApPowerStateReq</code> enum value, which represents
+the new state into which to transition</li>
+<li><code>int32Values[1]</code>: <code>VehicleApPowerStateShutdownParam</code> enum value. This is
+sent only for a <code>SHUTDOWN_PREPARE</code> message and conveys to Android what options it
+contains.</li>
+</ul>
+
+<p>The first integer value represents the new state into which Android is to transit. The semantics
+are defined in <code>types.hal</code> and provided in the following table:</p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Value name</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>OFF</td>
+<td>AP is turned off.</td>
+</tr>
+<tr>
+<td>DEEP_SLEEP</td>
+<td>AP is in deep sleep.</td>
+</tr>
+<tr>
+<td>ON_DISP_OFF</td>
+<td>AP is on, but display is off.</td>
+</tr>
+<tr>
+<td>N_FULL</td>
+<td>AP and display are on.</td>
+</tr>
+<tr>
+<td>SHUTDOWN_START</td>
+<td>AP is starting shutdown. The VMCU can turn on the AP after the time specified in the second
+value.</td>
+</tr>
+<tr>
+<td>SHUTDOWN_PREPARE</td>
+<td>The VMCU has requested the AP to shut down. The AP can either enter sleep state or start a full
+shutdown.</td>
+</tr>
+</tbody>
+</table>
+
+<p><code>VehicleApPowerStateShutdownParam</code> is also defined in <code>types.hal</code>. This
+enum has three elements, as described below:</p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Value name</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>SHUTDOWN_IMMEDIATELY</td>
+<td>The AP must shut down immediately. Postpone is not allowed.</td>
+</tr>
+<tr>
+<td>CAN_SLEEP</td>
+<td>The AP can enter deep sleep instead of shutting down completely.</td>
+</tr>
+<tr>
+<td>SHUTDOWN_ONLY</td>
+<td>The AP can only shut down when postponing is allowed.</td>
+</tr>
+</tbody>
+</table>
+
+<h4>AP_POWER_BOOTUP_REASON</h4>
+
+<p>This property is set by the VMCU whenever Android is booted up or resumed from suspend. This
+property instructs Android which event triggered the wakeup. This value must remain static until
+Android is rebooted or completes a suspend/wake cycle. This property can take a
+<code>VehicleApPowerBootupReason</code> value, which is defined in <code>types.hal</code> as
+follows:</p>
+
+<table>
+<thead>
+<tr>
+<th><strong>Value name</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>USER_POWER_ON</td>
+<td>Power on because the user pressed the power key or rotated the ignition switch.</td>
+</tr>
+<tr>
+<td>USER_UNLOCK</td>
+<td>Automatic power on triggered by a user unlocking a door (or any other type of automatic user
+detection).</td>
+</tr>
+<tr>
+<td>TIMER</td>
+<td>Automatic power on triggered by a timer. This occurs only when the AP has requested wakeup after
+a specific duration, as specified in <code>VehicleApPowerSetState</code>#SHUTDOWN_START.</td>
+</tr>
+</tbody>
+</table>
+
+<h3>Wake sources</h3>
+
+<p>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
+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,
+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
+and manages the turning off and on of the wake sources at suspend time.</p>
+
+<h3>Applications</h3>
+
+<p>OEMs must be careful to write applications so that they can be shut down quickly and not postpone
+the process indefinitely. </p>
+
+<h2>Appendix</h2>
+
+<h3>Directories in the source code tree</h3>
+
+<table>
+<thead>
+<tr>
+<th><strong>Content</strong></th>
+<th><strong>Directory</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>CarPowerManager-related code.</td>
+<td><code>packages/services/Car/car-lib/src/android/car/hardware/power</code></td>
+</tr>
+<tr>
+<td>CarPowerManagementService and so on.</td>
+<td><code>packages/services/Car/service/src/com/android/car</code></td>
+</tr>
+<tr>
+<td>Services dealing with the VHAL, such as <code>VehicleHal</code> and <code>HAlClient</code>.</td>
+<td><code>packages/services/Car/service/src/com/android/car/hal</code></td>
+</tr>
+<tr>
+<td>VHAL interface and property definitions.</td>
+<td><code>hardware/interfaces/automotive/vehicle/2.0</code></td>
+</tr>
+<tr>
+<td>Sample app to provide some idea about the <code>CarPowerManager</code>.</td>
+<td><code>packages/services/Car/tests/EmbeddedKitchenSinkApp/src/com/google/android/car/kitchensink</code></td>
+</tr>
+<tr>
+<td>libsuspend resides in this directory.</td>
+<td><code>system/core/libsuspend</code></td>
+</tr>
+</tbody>
+</table>
+
+<h3>Class diagram</h3>
+
+<p>This class diagram displays the Java classes and interfaces in the power management system:</p>
+
+<p><img src="/devices/automotive/images/automotive_power_class_diagram.png"></p>
+
+<p><b>Figure 5</b>. Power class diagram</p>
+
+<h3>Object relationship </h3>
+
+<p>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.</p>
+
+<p><img src="/devices/automotive/images/automotive_power_object_state.png"></p>
+
+<p><b>Figure 6</b>. Object reference diagram</p>
+
+ </body>
+</html>
diff --git a/en/devices/bootloader/boot-reason.html b/en/devices/bootloader/boot-reason.html
index 4071e32b..b7a1ffc4 100644
--- a/en/devices/bootloader/boot-reason.html
+++ b/en/devices/bootloader/boot-reason.html
@@ -232,9 +232,9 @@
<ul>
<li><code>"reboot,userrequested"</code></li>
<li><code>"shutdown,userrequested"</code></li>
- <li><code>"Shutdown,thermal"</code> (from <code>thermald</code>)</li>
+ <li><code>"shutdown,thermal"</code> (from <code>thermald</code>)</li>
<li><code>"shutdown,battery"</code></li>
- <li><code>"Shutdown,battery,thermal"</code> (from
+ <li><code>"shutdown,battery,thermal"</code> (from
<code>BatteryStatsService</code>)</li>
<li><code>"reboot,adb"</code></li>
<li><code>"reboot,shell"</code></li>
diff --git a/en/devices/camera/camera3_requests_hal.html b/en/devices/camera/camera3_requests_hal.html
index 314082a2..ca7c74ea 100644
--- a/en/devices/camera/camera3_requests_hal.html
+++ b/en/devices/camera/camera3_requests_hal.html
@@ -1,6 +1,6 @@
<html devsite>
<head>
- <title>HAL subsystem</title>
+ <title>HAL Subsystem</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
diff --git a/en/devices/camera/external-usb-cameras.md b/en/devices/camera/external-usb-cameras.md
index d39d849d..dd554f50 100644
--- a/en/devices/camera/external-usb-cameras.md
+++ b/en/devices/camera/external-usb-cameras.md
@@ -189,7 +189,8 @@ implementation
## Validation
-Devices with external camera support must pass camera CTS. The external USB
+Devices with external camera support must pass
+[camera CTS](/compatibility/cts/camera-hal#cts_tests). The external USB
webcam must remain plugged in the specific device during the entire test run,
otherwise some test cases will fail.
diff --git a/en/devices/sensors/index.html b/en/devices/sensors/index.html
index 1613131a..962ba868 100644
--- a/en/devices/sensors/index.html
+++ b/en/devices/sensors/index.html
@@ -24,124 +24,150 @@
<img style="float: right; margin: 0px 15px 15px 15px;" src="images/ape_fwk_hal_sensors.png" alt="Android Sensors HAL icon"/>
-<p>Android sensors give applications access to a mobile device's underlying physical sensors. They are data-providing virtual devices defined by <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a>, the sensor Hardware Abstraction Layer (HAL).</p>
+<p>Android sensors give applications access to a mobile device's underlying
+physical sensors. They are data-providing virtual devices defined by <a
+href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h"
+class="external">sensors.h</a>, the sensor Hardware Abstraction Layer (HAL).</p>
-<h2 id="what_are_“android_sensors”">What are Android sensors?</h2>
-<p>Android sensors are virtual devices that provide data coming from a set of physical sensors: accelerometers, gyroscopes, magnetometers, barometer, humidity, pressure, light, proximity and heart rate sensors.</p>
-<p>Not included in the list of physical devices providing data are camera, fingerprint sensor, microphone, and touch screen. These devices have their own reporting mechanism; the separation is arbitrary, but in general, Android sensors provide lower bandwidth data. For example, “100hz x 3 channels” for an accelerometer versus “25hz x 8 MP x 3 channels” for a camera or “44kHz x 1 channel” for a microphone.</p>
- <p>Android does not define how the different physical sensors are connected to the system on chip (SoC).</p>
+<h2 id="what_are_android_sensors">What are Android sensors?</h2>
+<p>Android sensors are virtual devices that provide data coming from a set of
+physical sensors: accelerometers, gyroscopes, magnetometers, barometer, humidity,
+pressure, light, proximity and heart rate sensors.</p>
+<p>Not included in the list of physical devices providing data are camera,
+fingerprint sensor, microphone, and touch screen. These devices have their own
+reporting mechanism; the separation is arbitrary, but in general, Android sensors
+provide lower bandwidth data. For example, “100hz x 3 channels” for an
+accelerometer versus “25hz x 8 MP x 3 channels” for a camera or “44kHz x 1
+channel” for a microphone.</p>
+ <p>Android does not define how the different physical sensors are connected
+ to the system on chip (SoC).</p>
<ul>
- <li> Often, sensor chips are connected to the SoC through a <a href="sensor-stack.html#sensor_hub">sensor hub</a>, allowing some low-power monitoring and processing of the data. </li>
- <li> Often, Inter-Integrated Circuit (I2C) or Serial Peripheral Interface
- (SPI) is used as the transport mechanism. </li>
- <li> To reduce power consumption, some architectures are hierarchical, with some
- minimal processing being done in the application-specific integrated
- circuit (ASIC - like motion detection on the accelerometer chip), and
- more is done in a microcontroller (like step detection
- in a sensor hub). </li>
- <li> It is up to the device manufacturer to choose an architecture based on
- accuracy, power, price and package-size characteristics. See <a
- href="sensor-stack.html">Sensor stack</a> for more information. </li>
- <li> Batching capabilities are an important consideration for power optimization.
- See <a href="batching.html">Batching</a> for more information. </li>
- </ul>
- <p>Each Android sensor has a “type” representing how the sensor behaves and what
- data it provides.</p>
+ <li>Often, sensor chips are connected to the SoC through a <a
+ href="/devices/sensors/sensor-stack#sensor_hub">sensor hub</a>, allowing
+ some low-power monitoring and processing of the data.</li>
+ <li>Often, Inter-Integrated Circuit (I2C) or Serial Peripheral Interface
+ (SPI) is used as the transport mechanism.</li>
+ <li>To reduce power consumption, some architectures are hierarchical, with
+ some minimal processing being done in the application-specific integrated
+ circuit (ASIC - like motion detection on the accelerometer chip), and more
+ is done in a microcontroller (like step detection in a sensor hub).</li>
+ <li>It is up to the device manufacturer to choose an architecture based on
+ accuracy, power, price and package-size characteristics. See <a
+ href="/devices/sensors/sensor-stack">Sensor stack</a> for more
+ information. </li>
+ <li>Batching capabilities are an important consideration for power
+ optimization. See <a href="/devices/sensors/batching">Batching</a> for
+ more information.</li> </ul>
+ <p>Each Android sensor has a “type” representing how the sensor behaves and
+ what data it provides.</p>
<ul>
- <li> The official Android <a href="sensor-types.html">Sensor types</a> are defined in <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a> under the names SENSOR_TYPE_…
+ <li>The official Android <a href="/devices/sensors/sensor-types">Sensor
+ types</a> are defined in <a
+ href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h"
+ class="external">sensors.h</a> under the names SENSOR_TYPE_…
<ul>
- <li> The vast majority of sensors have an official sensor type. </li>
- <li> Those types are documented in the Android SDK. </li>
- <li> Behavior of sensors with those types are tested in the Android
- Compatibility Test Suite (CTS). </li>
+ <li>The vast majority of sensors have an official sensor type.</li>
+ <li>Those types are documented in the Android SDK.</li>
+ <li>Behavior of sensors with those types are tested in the Android
+ Compatibility Test Suite (CTS).</li>
</ul>
</li>
- <li> If a manufacturer integrates a new kind of sensor on an Android device, the
- manufacturer can define its own temporary type to refer to it.
+ <li>If a manufacturer integrates a new kind of sensor on an Android
+ device, the manufacturer can define its own temporary type to refer to
+ it.
<ul>
- <li> Those types are undocumented, so application developers are unlikely to use
- them, either because they don’t know about them, or know that they are rarely
- present (only on some devices from this specific manufacturer). </li>
- <li> They are not tested by CTS. </li>
- <li> Once Android defines an official sensor type for this kind of
- sensor, manufacturers must stop using their own temporary type
- and use the official type instead. This way, the sensor will be
- used by more application developers. </li>
+ <li>Those types are undocumented, so application developers are
+ unlikely to use them, either because they don’t know about them, or
+ know that they are rarely present (only on some devices from this
+ specific manufacturer).</li>
+ <li>They are not tested by CTS.</li>
+ <li>Once Android defines an official sensor type for this kind of sensor,
+ manufacturers must stop using their own temporary type and use the
+ official type instead. This way, the sensor will be used by more
+ application developers.</li>
</ul>
- </li>
- <li> The list of all sensors present on the device is reported by the HAL
+ </li>
+ <li>The list of all sensors present on the device is reported by the HAL
implementation.
<ul>
- <li> There can be several sensors of the same type. For example, two proximity
- sensors or two accelerometers. </li>
- <li> The vast majority of applications request only a single sensor of a given type.
- For example, an application requesting the default accelerometer will get the
- first accelerometer in the list. </li>
- <li> Sensors are often defined by <a href="suspend-mode.html#wake-up_sensors">wake-up</a> and <a href="suspend-mode.html#non-wake-up_sensors">non-wake-up</a> pairs, both sensors sharing the same type, but differing by their wake-up
- characteristic. </li>
+ <li>There can be several sensors of the same type. For example, two
+ proximity sensors or two accelerometers.</li>
+ <li>The vast majority of applications request only a single sensor of
+ a given type. For example, an application requesting the default
+ accelerometer will get the first accelerometer in the list.</li>
+ <li>Sensors are often defined by <a
+ href="/devices/sensors/suspend-mode#wake-up_sensors">wake-up</a> and
+ <a
+ href="/devices/sensors/suspend-mode#non-wake-up_sensors">non-wake-up</a>
+ pairs, both sensors sharing the same type, but differing by their
+ wake-up characteristic.</li>
</ul>
- </li>
+ </li>
</ul>
<p>Android sensors provide data as a series of sensor events.</p>
- <p> Each <a href="hal-interface.html#sensors_event_t">event</a> contains:</p>
+ <p> Each <a href="/devices/sensors/hal-interface#sensors_event_t">event</a>
+ contains:</p>
<ul>
- <li> a handle to the sensor that generated it </li>
- <li> the timestamp at which the event was detected or measured </li>
- <li> and some data </li>
+ <li>a handle to the sensor that generated it</li>
+ <li>the timestamp at which the event was detected or measured</li>
+ <li>and some data</li>
</ul>
- <p>The interpretation of the reported data depends on the sensor type.
- See the <a href="sensor-types.html">sensor type</a> definitions for details on
- what data is reported for each sensor type.</p>
+ <p>The interpretation of the reported data depends on the sensor type. See
+ the <a href="/devices/sensors/sensor-types">sensor type</a>
+ definitions for details on what data is reported for each sensor type.</p>
<h2 id="existing_documentation2">Existing documentation</h2>
<h3 id="targeted_at_developers">Targeted at developers</h3>
<ul>
- <li> Overview
+ <li>Overview
<ul>
- <li><a href="https://developer.android.com/guide/topics/sensors/sensors_overview.html"> https://developer.android.com/guide/topics/sensors/sensors_overview.html </a></li>
+ <li><a href="https://developer.android.com/guide/topics/sensors/sensors_overview.html" class="external">https://developer.android.com/guide/topics/sensors/sensors_overview.html</a></li>
</ul>
</li>
- <li> SDK reference
+ <li>SDK reference
<ul>
- <li> <a href="https://developer.android.com/reference/android/hardware/SensorManager.html">https://developer.android.com/reference/android/hardware/SensorManager.html</a></li>
- <li><a href="https://developer.android.com/reference/android/hardware/SensorEventListener.html"> https://developer.android.com/reference/android/hardware/SensorEventListener.html</a></li>
- <li> <a href="https://developer.android.com/reference/android/hardware/SensorEvent.html">https://developer.android.com/reference/android/hardware/SensorEvent.html</a></li>
- <li><a href="https://developer.android.com/reference/android/hardware/Sensor.html"> https://developer.android.com/reference/android/hardware/Sensor.html</a></li>
+ <li><a href="https://developer.android.com/reference/android/hardware/SensorManager" class="external">https://developer.android.com/reference/android/hardware/SensorManager</a></li>
+ <li><a href="https://developer.android.com/reference/android/hardware/SensorEventListener" class="external">https://developer.android.com/reference/android/hardware/SensorEventListener</a></li>
+ <li><a href="https://developer.android.com/reference/android/hardware/SensorEvent" class="external">https://developer.android.com/reference/android/hardware/SensorEvent</a></li>
+ <li><a href="https://developer.android.com/reference/android/hardware/Sensor" class="external"> https://developer.android.com/reference/android/hardware/Sensor</a></li>
</ul>
</li>
- <li> StackOverflow and tutorial websites
+ <li>Stack Overflow and tutorial websites
<ul>
- <li> Because sensors documentation was sometimes lacking, developers resorted to Q&amp;A
- websites like StackOverflow to find answers. </li>
- <li> Some tutorial websites exist as well, but do not cover the latest features like
- batching, significant motion and game rotation vectors. </li>
- <li> The answers over there are not always right, and show where more documentation
- is needed. </li>
+ <li>Because sensors documentation was sometimes lacking, developers
+ resorted to Q&amp;A websites like Stack Overflow to find answers.
+ </li>
+ <li>Some tutorial websites exist as well, but do not cover the latest
+ features like batching, significant motion and game rotation vectors.
+ </li>
+ <li>The answers over there are not always right, and show where more
+ documentation is needed.</li>
</ul>
</li>
</ul>
<h3 id="targeted_at_manufacturers_public">Targeted at manufacturers</h3>
<ul>
- <li> Overview
+ <li>Overview
<ul>
- <li>This <a href="/devices/sensors/index.html">Sensors</a>
+ <li>This <a href="/devices/sensors/">Sensors</a>
page and its sub-pages. </li>
</ul>
- </li>
- <li> Hardware abstraction layer (HAL)
+ </li>
+ <li>Hardware abstraction layer (HAL)
<ul>
- <li> <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h</a></li>
- <li> Also known as “sensors.h” </li>
- <li> The source of truth. First document to be updated when new features are
- developed. </li>
+ <li><a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h" class="external">/platform/hardware/libhardware/+/master/include/hardware/sensors.h</a></li>
+ <li>Also known as “sensors.h”</li>
+ <li>The source of truth. First document to be updated when new
+ features are developed.</li>
</ul>
</li>
- <li> Android CDD (Compatibility Definition Document)
+ <li>Android CDD (Compatibility Definition Document)
<ul>
- <li><a href="/compatibility/android-cdd.pdf">https://source.android.com/compatibility/android-cdd.pdf</a></li>
- <li> See sections relative to sensors. </li>
- <li> The CDD is lenient, so satisfying the CDD requirements is not enough to ensure
- high quality sensors. </li>
+ <li><a
+ href="/compatibility/9/android-9-cdd">https://source.android.com/compatibility/9/android-9-cdd</a></li>
+ <li>See sections relative to sensors.</li>
+ <li>The CDD is lenient, so satisfying the CDD requirements is not
+ enough to ensure high quality sensors.</li>
</ul>
</li>
</ul>
diff --git a/en/devices/tech/admin/index.html b/en/devices/tech/admin/index.html
index 39ba66e6..fcceee57 100644
--- a/en/devices/tech/admin/index.html
+++ b/en/devices/tech/admin/index.html
@@ -23,42 +23,57 @@
-<p>Devices running Android 5.0 and later with the managed_users feature
-declared can be used in a <a href="http://www.android.com/work/">corporate
-environment</a> under the auspices of each company’s information technology (IT)
-department. This is possible with the introduction of <a href="multi-user.html">multiple
-users</a>, <a href="managed-profiles.html">managed profiles</a>, and enterprise
-mobility management (EMM) applications, as well as enhancements to default
-<a
-href="/security/encryption/index.html">encryption</a>,
-<a
-href="/security/verifiedboot/index.html">verified
-boot</a>, and <a
-href="/security/selinux/index.html">SELinux</a>.</p>
+<p>
+ Devices running Android 5.0 and later with the <code>managed_users</code> feature
+ declared can be used in a <a href="http://www.android.com/work/"
+ class="external">corporate environment</a> under the auspices of each company’s
+ information technology (IT) department. This is possible with the introduction of
+ <a href="/devices/tech/admin/multi-user">multiple users</a>,
+ <a href="/devices/tech/admin/managed-profiles">managed profiles</a>, and
+ enterprise mobility management (EMM) applications, as well as enhancements to default
+ <a href="/security/encryption/index">encryption</a>,
+ <a href="/security/verifiedboot/index">verified boot</a>, and
+ <a href="/security/selinux/index">SELinux</a>.
+</p>
-<p>With these enhancements, either users or their IT departments may create
-managed profiles that separate corporate employer data from personal user
-information. Follow the documents within this section of the site to properly
-implement corporate device administration.</p>
+<p>
+ With these enhancements, either users or their IT departments may create
+ managed profiles that separate corporate employer data from personal user
+ information. Follow the documents within this section of the site to properly
+ implement corporate device administration.
+</p>
-<h2 id=summary>Summary</h2>
+<h2 id="summary">Summary</h2>
-<p>Follow this flow to employ device administration:</p>
+ <p>Follow this flow to employ device administration:</p>
-<ol>
- <li>Gain an understanding of key concepts, such as <a
-href="multi-user.html">multiple users</a> and <a
-href="managed-profiles.html">managed profiles</a>.
- <li><a href="implement.html">Implement device administration</a> via custom
-overlay files.
- <li><a href="testing-setup.html">Test</a> and validate your devices with EMM providers and applications.
-</ol>
+ <ol>
+ <li>
+ Gain an understanding of key concepts, such as
+ <a href="/devices/tech/admin/multi-user">multiple users</a> and
+ <a href="/devices/tech/admin/managed-profiles">managed profiles</a>.
+ </li>
+ <li>
+ <a href="/devices/tech/admin/implement">Implement device
+ administration</a> via custom overlay files.
+ </li>
+ <li>
+ <a href="/devices/tech/admin/testing-setup">Test</a> and validate
+ your devices with EMM providers and applications.
+ </li>
+ </ol>
-<h2 id=supporting_documentation>Supporting documentation</h2>
+<h2 id="supporting_documentation">Supporting documentation</h2>
-<p><a href="http://developer.android.com/guide/topics/admin/device-admin.html">Device Administration API</a></p>
+ <p>
+ <a href="http://developer.android.com/guide/topics/admin/device-admin.html"
+ class="external">Device Administration API</a>
+ </p>
-<p><a href="https://developer.android.com/training/enterprise/index.html">Building Apps for Work</a></p>
+ <p>
+ <a href="https://developer.android.com/training/enterprise/index.html"
+ class="external">Building Apps for Work</a>
+ </p>
</body>
</html>
diff --git a/en/devices/tech/connect/call-notification.html b/en/devices/tech/connect/call-notification.html
index a8f5c2c6..a7a6c9a9 100644
--- a/en/devices/tech/connect/call-notification.html
+++ b/en/devices/tech/connect/call-notification.html
@@ -114,7 +114,7 @@ functionality. For details, refer to the following documentation:</p>
<h2 id=implement>Implementation</h2>
<p>Device implementers may need to update Telecom/Telephony components that
-expose APIs available for use by by the default Dialer.</p>
+expose APIs available for use by the default Dialer.</p>
</body>
</html>
diff --git a/en/devices/tech/connect/wifi-passpoint.md b/en/devices/tech/connect/wifi-passpoint.md
index 4ee96591..9f540339 100644
--- a/en/devices/tech/connect/wifi-passpoint.md
+++ b/en/devices/tech/connect/wifi-passpoint.md
@@ -91,7 +91,7 @@ application/x-x509-ca-cert
</code>
</td>
-<td>Optional for EAP-TLS and EAP-TTLS</td>
+<td>Required for EAP-TLS and EAP-TTLS</td>
<td>A single X.509v3 base64-encoded certificate payload.</td>
</tr>
<tr>
diff --git a/en/devices/tech/debug/asan.html b/en/devices/tech/debug/asan.html
index 1c12ad62..9ea32939 100644
--- a/en/devices/tech/debug/asan.html
+++ b/en/devices/tech/debug/asan.html
@@ -21,55 +21,81 @@
limitations under the License.
-->
-
-
<p>AddressSanitizer (ASan) is a fast compiler-based tool for detecting memory bugs
-in native code. It is comparable to Valgrind (Memcheck tool), but, unlike it,
-ASan:</p>
+in native code. Android supports both regular ASan and hardware-accelerated ASan (HWASan).
+HWAsan is based on memory tagging and is only available on AArch64 because it relies on
+the Top-Byte-Ignore feature.</p>
+<p>These tools detect:</p>
<ul>
- <li> + detects overflows on stack and global objects
- <li> - does not detect uninitialized reads and memory leaks
- <li> + is much faster (two-three times slowdown compared to Valgrind’s 20-100x)
- <li> + has less memory overhead
+<li>Stack and heap buffer overflow/underflow.
+<li>Heap use after free.
+<li>Stack use outside scope.
+<li>Stack use after return (HWAsan only on Android).
+<li>Double free/wild free.
</ul>
-<p>This document describes how to build and run parts of the Android platform with
-AddressSanitizer. If you are looking to build a standalone (i.e. SDK/NDK)
-application with AddressSanitizer, see the <a
-href="https://github.com/google/sanitizers/wiki/AddressSanitizerOnAndroid">AddressSanitizerOnAndroid</a>
-public project site instead.</p>
+<p>ASan runs on both 32-bit and 64-bit ARM, plus x86 and x86-64. ASan's CPU overhead
+is roughly 2x, code size overhead is between 50% and 2x, and a large memory overhead
+(dependent on your allocation patterns, but on the order of 2x).</p>
-<p>AddressSanitizer consists of a compiler (<code>external/clang</code>) and a runtime library
-(<code>external/compiler-rt/lib/asan</code>).</p>
+<p>HWASan has similar CPU and code size overheads, but a much smaller RAM overhead (15%).
+HWASan is non-deterministic. There are only 256 possible tag values, so there is a flat 0.4%
+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.</p>
-<p class="note"><strong>Note</strong>: Use the current master
-branch to gain access to the <a href="#sanitize_target">SANITIZE_TARGET</a>
-feature and the ability to build the entire Android platform with
-AddressSanitizer at once. Otherwise, you are limited to using
-<code>LOCAL_SANITIZE</code>.</p>
+<p>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,
+Valgrind detects uninitialized reads and memory leaks that ASan does not.
+Valgrind may be useful for debugging apps but is not practical for the entire OS,
+which is why the Android team uses ASan instead.</p>
-<h2 id=building_with_clang>Building with Clang</h2>
+<p>This document describes how to build and run parts/all of the Android OS itself with
+AddressSanitizer. If you are building an SDK/NDK application with AddressSanitizer, see
+<a href="https://github.com/google/sanitizers/wiki/AddressSanitizerOnAndroid" class="external">AddressSanitizerOnAndroid</a>
+instead.</p>
-<p>As a first step to building an ASan-instrumented binary, make sure that your
-code builds with Clang. This is done by default on the master branch, so there should be nothing
-you need to do. If you believe that the module you'd like to test is being built with GCC,
-you can switch to Clang by adding <code>LOCAL_CLANG:=true</code>
-to the build rules. Clang may find bugs in your code that GCC missed.</p>
-<h2 id=building_executables_with_addresssanitizer>Building executables with AddressSanitizer</h2>
+<h2 id="using-hwasan">Using HWAsan</h2>
-<p>Add <code>LOCAL_SANITIZE:=address</code> to the build rule of the
-executable.</p>
+<p>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
+larger libraries. See the <code>walleye_hwasan</code> target for an example.</p>
-<pre class="devsite-click-to-copy">
-LOCAL_SANITIZE:=address
+<p>Use the following commands to build the entire platform using HWASan:</p>
+
+<pre class="prettyprint">
+<code class="devsite-terminal">lunch walleye_hwasan-userdebug</code>
+<code class="devsite-terminal">make SANITIZE_TARGET=hwaddress</code>
</pre>
+<p>Unlike ASan, with HWASan there's no need to build twice, incremental builds just work,
+there are no special flashing instructions or wiping, static executables are supported,
+and it's okay to skip sanitization of any library other than <code>libc</code>.
+There's also no requirement that if a library is sanitized, any executable that links
+to it must also be sanitized.
+
+<p>To skip sanitization of a module, use <code>LOCAL_NOSANITIZE := hwaddress</code> or
+<code>sanitize: { hwaddress: false }</code>.</p>
+
+<aside class="note">
+<strong>Note:</strong> Currently there is no support for sanitizing individual modules with HWASan. Use ASan to sanitize individual modules.
+</aside>
+
+<h2 id="sanitizing_individual_executables_with_asan">Sanitizing individual executables with ASan</h2>
+
+<p>Add <code>LOCAL_SANITIZE:=address</code> or <code>sanitize: { address: true } }</code> to
+the build rule for the executable. You can search the code for existing examples or to find
+the other available sanitizers.</p>
+
<p>When a bug is detected, ASan prints a verbose report both to the standard
output and to <code>logcat</code> and then crashes the process.</p>
-<h2 id=building_shared_libraries_with_addresssanitizer>Building shared libraries with AddressSanitizer</h2>
+<h2 id="sanitizing_shared_libraries_with_asan">Sanitizing shared libraries with ASan</h2>
<p>Due to the way ASan works, a library built with ASan cannot be used by an
executable that's built without ASan.</p>
@@ -151,7 +177,7 @@ script.
<p>The second approach can provide more data (i.e. file:line locations) because of
the availability of symbolized libraries on the host.</p>
-<h2 id=addresssanitizer_in_the_apps>AddressSanitizer in the apps</h2>
+<h2 id=addresssanitizer_in_the_apps>AddressSanitizer in apps</h2>
<p>AddressSanitizer cannot see into Java code, but it can detect bugs in the JNI
libraries. For that, you'll need to build the executable with ASan, which in
@@ -204,8 +230,8 @@ the log.</p>
<h2 id=sanitize_target>SANITIZE_TARGET</h2>
-<p>The master branch has support for building the entire Android platform with
-AddressSanitizer at once.</p>
+<p>Since Android 7.0 Nougat, there is support for building the entire Android platform with
+ASan at once. (If you're building a release newer than Android 9.0 Pie, HWASan is a better choice.)</p>
<p>Run the following commands in the same build tree.</p>
@@ -221,8 +247,6 @@ flashed to the device as well. Use the following command line:</p>
fastboot flash userdata && fastboot flashall
</pre>
-<p>At the moment of this writing, modern Nexus and Pixel devices boot to the UI in this mode.</p>
-
<p>This works by building two sets of shared libraries: normal in
<code>/system/lib</code> (the first make invocation), ASan-instrumented in
<code>/data/asan/lib</code> (the second make invocation). Executables from the
diff --git a/en/devices/tech/debug/gdb.html b/en/devices/tech/debug/gdb.html
index e43ca3c3..49d62aa3 100644
--- a/en/devices/tech/debug/gdb.html
+++ b/en/devices/tech/debug/gdb.html
@@ -25,7 +25,21 @@
<p>The GNU Project debugger (GDB) is a commonly used Unix debugger. This page
details using <code>gdb</code> to debug Android apps and processes for platform
developers. For third-party app development, see
-<a href="https://developer.android.com/studio/debug/index.html">Debug Your App</a>.</p>
+<a class="external"
+href="https://developer.android.com/studio/debug/index.html">Debug Your
+App</a>.</p>
+
+<h2 id="prerequisites">Prerequisites</h2>
+
+<p>To use GDB for debugging apps and processes:</p>
+
+ <ul>
+ <li>Set up environment with <code>envsetup.sh</code>
+ <li>Run the <code>lunch</code> command</li>
+ </ul>
+
+<p>For more help with setting up your environment, see
+ <a href="/setup/build/building#initialize">Preparing to Build</a>.</p>
<h2 id=running>Debugging running apps or processes</h2>
@@ -42,8 +56,9 @@ gdbclient.py -p 1234
the host, configures <code>gdb</code> to find symbols, and connects
<code>gdb</code> to the remote <code>gdbserver</code>.</p>
-<aside class="note"><strong>Note:</strong> in Android 6 and earlier the script was a shell script
-called <code>gdbclient</code> instead of a Python script called <code>gdbclient.py</code>.</aside>
+<aside class="note"><strong>Note:</strong> In Android 6 and lower the script was
+a shell script called <code>gdbclient</code> instead of a Python script called
+<code>gdbclient.py</code>.</aside>
<h2 id=starts>Debugging native process startup</h2>
@@ -99,7 +114,7 @@ your app from the list, then press <strong>Wait for debugger</strong>.</li>
<li>Start the app, either from the launcher or by using the command line to run:
<pre class="devsite-terminal devsite-click-to-copy">
-am start -a android.intent.action.MAIN -n <var>APP_NAME</var>/.<var>APP_ACTIVITY</var>
+adb shell am start -a android.intent.action.MAIN -n <var>APP_NAME</var>/.<var>APP_ACTIVITY</var>
</pre></li>
<li>Wait for the app to load and a dialog to appear telling you the app is
@@ -136,7 +151,6 @@ instructions on how to connect <code>gdb</code> using the command:
gdbclient.py -p <var>PID</var>
</pre>
-
<h2 id=symbols>Debugging without symbols</h2>
<p>For 32-bit ARM, if you don’t have symbols, <code>gdb</code> can get confused
diff --git a/en/devices/tech/debug/native_stack_dump.md b/en/devices/tech/debug/native_stack_dump.md
new file mode 100644
index 00000000..6a964478
--- /dev/null
+++ b/en/devices/tech/debug/native_stack_dump.md
@@ -0,0 +1,179 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+{% include "_versions.html" %}
+
+<!--
+ Copyright 2019 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Dumping User and Kernel Stacks on Kernel Events
+
+Dumping the native kernel and userspace stack when a certain code path in the
+kernel is executed can help with understanding the code flow when you are debugging
+a certain behavior, such as an error you found in the logs. One such case is when
+you notice SELinux denial messages in logs but want to know which path triggered
+it to better understand why it happened.
+
+In this article we will show you how to use kernel instrumentation and BPF Compiler Collection (BCC) to
+dump both the user and kernel stack when a kernel event occurs in an Android
+system. BCC is a toolkit for creating efficient kernel tracing.
+
+## Installing adeb
+
+The [adeb](https://android.googlesource.com/platform/external/adeb)
+project installs a chroot environment on your Android device. We will use adeb in later
+steps in the articles.
+
+Install adeb using the instructions in the [adeb README](https://android.googlesource.com/platform/external/adeb/+/master/README.md).
+
+Run the following command to install adeb on your target Android device:
+<pre class="devsite-terminal devsite-click-to-copy">
+adeb prepare --full
+</pre>
+adeb comes prepackaged with BCC, so the previous step also installs BCC's `trace` utility
+we need for later steps.
+
+## Example: Understanding which path triggered an SELinux denial
+
+### Adding a tracepoint to the kernel
+The diff below adds a tracepoint at the point where an SELinux denial is logged
+in the kernel, we will need it in later parts of this article to use with BCC.
+You can apply the diff to your kernel sources to add an SELinux denial tracepoint.
+If the diff does not apply cleanly, patch it in manually using the diff as a reference.
+
+<pre class="prettyprint">
+diff --git a/include/trace/events/selinux.h b/include/trace/events/selinux.h
+new file mode 100644
+index 000000000000..dac185062634
+--- /dev/null
++++ b/include/trace/events/selinux.h
+@@ -0,0 +1,34 @@
++#undef TRACE_SYSTEM
++#define TRACE_SYSTEM selinux
++
++#if !defined(_TRACE_SELINUX_H) || defined(TRACE_HEADER_MULTI_READ)
++#define _TRACE_SELINUX_H
++
++#include &lt;linux/ktime.h&gt;
++#include &lt;linux/tracepoint.h&gt;
++
++TRACE_EVENT(selinux_denied,
++
++ TP_PROTO(int cls, int av),
++
++ TP_ARGS(cls, av),
++
++ TP_STRUCT__entry(
++ __field( int, cls )
++ __field( int, av )
++ ),
++
++ TP_fast_assign(
++ __entry->cls = cls;
++ __entry->av = av;
++ ),
++
++ TP_printk("denied %d %d",
++ __entry->cls,
++ __entry->av)
++);
++
++#endif /* _TRACE_SELINUX_H */
++
++/* This part ust be outside protection */
++#include &lt;trace/define_trace.&gt;
+diff --git a/security/selinux/avc.c b/security/selinux/avc.c
+index 84d9a2e2bbaf..ab04b7c2dd01 100644
+--- a/security/selinux/avc.c
++++ b/security/selinux/avc.c
+@@ -34,6 +34,9 @@
+ #include "avc_ss.h"
+ #include "classmap.h"
+
++#define CREATE_TRACE_POINTS
++#include &lt;trace/events/selinux.h&gt;
++
+ #define AVC_CACHE_SLOTS 512
+ #define AVC_DEF_CACHE_THRESHOLD 512
+ #define AVC_CACHE_RECLAIM 16
+@@ -713,6 +716,12 @@ static void avc_audit_pre_callback(struct audit_buffer *ab, void *a)
+ struct common_audit_data *ad = a;
+ audit_log_format(ab, "avc: %s ",
+ ad->selinux_audit_data->denied ? "denied" : "granted");
++
++ if (ad->selinux_audit_data->denied) {
++ trace_selinux_denied(ad->selinux_audit_data->tclass,
++ ad->selinux_audit_data->audited);
++ }
++
+ avc_dump_av(ab, ad->selinux_audit_data->tclass,
+ ad->selinux_audit_data->audited);
+ audit_log_format(ab, " for ");
+</pre>
+
+### Tracing the user and kernel stacks
+To trace stacks when the SELinux denial tracepoint is hit, run the following command:
+<pre class="prettyprint">
+<code class="devsite-terminal">adeb shell</code>
+<code class="devsite-terminal">trace -K -U 't:selinux:selinux_denial'</code>
+</pre>
+
+You should see something like this when denials are triggered:
+<pre class="prettyprint">
+2286 2434 Binder:2286_4 selinux_denied
+ avc_audit_pre_callback+0xd8 [kernel]
+ avc_audit_pre_callback+0xd8 [kernel]
+ common_lsm_audit+0x64 [kernel]
+ slow_avc_audit+0x74 [kernel]
+ avc_has_perm+0xb8 [kernel]
+ selinux_binder_transfer_file+0x158 [kernel]
+ security_binder_transfer_file+0x50 [kernel]
+ binder_translate_fd+0xcc [kernel]
+ binder_transaction+0x1b64 [kernel]
+ binder_ioctl+0xadc [kernel]
+ do_vfs_ioctl+0x5c8 [kernel]
+ sys_ioctl+0x88 [kernel]
+ __sys_trace_return+0x0 [kernel]
+ __ioctl+0x8 [libc.so]
+ android::IPCThreadState::talkWithDriver(bool)+0x104 [libbinder.so]
+ android::IPCThreadState::waitForResponse(android::Parcel*, int*)+0x40
+ [libbinder.so]
+ android::IPCThreadState::executeCommand(int)+0x460 [libbinder.so]
+ android::IPCThreadState::getAndExecuteCommand()+0xa0 [libbinder.so]
+ android::IPCThreadState::joinThreadPool(bool)+0x40 [libbinder.so]
+ [unknown] [libbinder.so]
+ android::Thread::_threadLoop(void*)+0x12c [libutils.so]
+ android::AndroidRuntime::javaThreadShell(void*)+0x90 [libandroid_runtime.so]
+ __pthread_start(void*)+0x28 [libc.so]
+ __start_thread+0x48 [libc.so]
+</pre>
+
+The call chain above is a unified kernel and user native call chain giving you
+a better view of the code flow starting from userspace all the way down to the kernel where
+the denial happens. In the example call chain above, a binder transaction
+initiated from userspace involved passing a file descriptor. Since the file
+descriptor did not have the needed SELinux policy settings, SELinux denied it and
+the binder transaction failed.
+
+The same tracing technique can be used for dumping the stack on system calls, kernel
+function entry, and more by changing the arguments passed to the `trace` command
+in most cases.
+
+## Additional references
+
+For more information on `trace`, see the [BCC trace tool documentation](https://android.googlesource.com/platform/external/bcc/+/master/tools/trace_example.txt).
+For more information about running BCC on Android devices, see the
+[adeb project's BCC howto](https://android.googlesource.com/platform/external/adeb/+/master/BCC.md).
diff --git a/en/devices/tech/display/color-mgmt.html b/en/devices/tech/display/color-mgmt.html
index d73f091d..a61c9b76 100644
--- a/en/devices/tech/display/color-mgmt.html
+++ b/en/devices/tech/display/color-mgmt.html
@@ -89,7 +89,7 @@ display referred space with the same white point and color primaries as sRGB
support and can be implemented in the Android EGL wrapper. To be useful, this
extension requires support for 16-bit floating point (FP16).</li>
<li>
-<a href="https://github.com/KhronosGroup/EGL-Registry/pull/10/files" class="external">EGL_KHR_gl_colorspace_display_p3
+<a href="https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_display_p3.txt" class="external">EGL_EXT_gl_colorspace_display_p3
and EGL_EXT_gl_colorspace_display_p3_linear</a>. For applications that want
to use Display-P3 format default framebuffers to more easily achieve sRGB
rendering to display devices, this extension allows creating EGLSurfaces that
diff --git a/en/devices/tech/ota/index.html b/en/devices/tech/ota/index.html
index 946a6f4c..6c0431c8 100644
--- a/en/devices/tech/ota/index.html
+++ b/en/devices/tech/ota/index.html
@@ -25,50 +25,53 @@
<p>
Android devices in the field can receive and install over-the-air (OTA)
- updates to the system and application software. This section describes
- the structure of the update packages and the tools provided to build
- them. It is intended for developers who want to make the OTA update
- system work on new Android devices and those who are building update
- packages for use with released devices. OTA updates are designed to
- upgrade the underlying operating system and the read-only apps installed
- on the system partition; these updates do <em>not</em> affect
- applications installed by the user from Google Play.
+ updates to the system, application software, and time zone rules. This
+ section describes the structure of update packages and the tools provided
+ to build them. It is intended for developers who want to make OTA updates
+ work on new Android devices and those who want to build update packages
+ for released devices.
</p>
+ <p>OTA updates are designed to upgrade the underlying operating system, the
+ read-only apps installed on the system partition, and/or time zone rules;
+ these updates do <em>not</em> affect applications installed by the user
+ from Google Play.
+ </p>
+
+ <h2 id="ab_updates">A/B (Seamless) system updates</h2>
<p>
- The Android Open Source Project (AOSP) includes a
+ Modern Android devices have two copies of each partition (A and B) and can
+ apply an update to the currently unused partition while the system is
+ running but idle. A/B devices do not need space to download the update
+ package because they can apply the update as they read it from the
+ network; this is known as <em>streaming A/B</em>. For more information
+ about OTA updates for A/B devices, see
+ <a href="/devices/tech/ota/ab/index.html">A/B (Seamless) System
+ Updates</a>. For a sample app that provides examples on using Android
+ system update APIs (i.e., <code>update_engine</code>) to install A/B
+ updates, refer to
<a href="https://android.googlesource.com/platform/bootable/recovery/+/master/updater_sample/"
- class="external">SystemUpdaterSample</a> app that gives examples on
- how to use Android system update APIs to install OTA updates. The sample
- app is an example on how to use <code>update_engine</code> for A/B
- updates.
- For more information, see <a href="https://android.googlesource.com/platform/bootable/recovery/+/master/updater_sample/README.md"
- class="external"><code>updater_sample/README.md</code></a>.
+ class="external">SystemUpdaterSample</a> (app details available in
+ <a href="https://android.googlesource.com/platform/bootable/recovery/+/master/updater_sample/README.md"
+ class="external"><code>updater_sample/README.md</code></a>).
</p>
- <h2 id="ab_updates">A/B (seamless) system updates</h2>
-
+ <h2 id="nonab_updates">Non-A/B system updates</h2>
<p>
- Modern A/B devices have two copies of each partition, A and B. Devices
- apply the update to the currently unused partition while the system is
- running but idle. A/B devices do not need space to download the update
- package because they can apply the update as they read it from the
- network. This is called <em>streaming A/B</em>. A/B updates are also
- known as <em>seamless updates</em>. For more information about OTA
- updates for A/B devices, see
- <a href="/devices/tech/ota/ab/index.html">A/B (Seamless) System
- Updates
- </a>.
+ Older Android devices have a dedicated recovery partition containing the
+ software needed to unpack a downloaded update package and apply the
+ update to the other partitions. For more information, see
+ <a href="/devices/tech/ota/nonab/index.html">Non-A/B System Updates</a>.
</p>
- <h2 id="nonab_updates">Non-A/B system updates</h2>
-
+ <h2 id=time-zone-updates>Time zone rule updates</h2>
<p>
- Older devices have a special recovery partition containing the software
- needed to unpack a downloaded update package and apply the update to
- the other partitions. For more information, see
- <a href="/devices/tech/ota/nonab/index.html">Non-A/B System Updates
- </a>.
+ As of Android 8.1, OEMs can push updated time zone rules data to devices
+ without requiring a system update. This mechanism enables users to
+ receive timely updates (thus extending the useful lifetime of an Android
+ device) and OEMs to test time zone updates independently of system image
+ updates. For details, see
+ <a href="/devices/tech/config/timezone-rules">Time Zone Rules</a>.
</p>
</body>