diff options
author | Treehugger Robot <treehugger-gerrit@google.com> | 2018-04-11 22:20:55 +0000 |
---|---|---|
committer | Gerrit Code Review <noreply-gerritcodereview@google.com> | 2018-04-11 22:20:55 +0000 |
commit | 6930a80a9ae47f2686acbc17fbd5d18c24918066 (patch) | |
tree | 8afafd84cf03b8bbf57a9b0608fe29a98e8c0865 /en/devices | |
parent | 08f4f1a3b11912f54ae9bf6c7acd904bfe21de3e (diff) | |
parent | 804f3183c40817391c886feab3005bf47f08d29e (diff) | |
download | source.android.com-6930a80a9ae47f2686acbc17fbd5d18c24918066.tar.gz |
Merge "Docs: Changes to source.android.com"android-o-mr1-iot-preview-8android-n-iot-release-lg-thinq-wk7o-mr1-iot-preview-8
Diffstat (limited to 'en/devices')
-rw-r--r-- | en/devices/architecture/dto/multiple.html | 14 | ||||
-rw-r--r-- | en/devices/architecture/hidl-cpp/index.html | 2 | ||||
-rw-r--r-- | en/devices/architecture/hidl-java/index.html | 2 | ||||
-rw-r--r-- | en/devices/architecture/hidl/versioning.html | 48 | ||||
-rw-r--r-- | en/devices/tech/config/filesystem.html | 3 | ||||
-rw-r--r-- | en/devices/tech/config/namespaces_libraries.html | 20 | ||||
-rw-r--r-- | en/devices/tech/config/perms-whitelist.html | 6 | ||||
-rw-r--r-- | en/devices/tech/config/uicc.html | 2 | ||||
-rw-r--r-- | en/devices/tech/ota/ab/index.html | 3 | ||||
-rw-r--r-- | en/devices/tech/ota/index.html | 4 | ||||
-rw-r--r-- | en/devices/tech/perf/boot-times.html | 22 |
11 files changed, 110 insertions, 16 deletions
diff --git a/en/devices/architecture/dto/multiple.html b/en/devices/architecture/dto/multiple.html index 52f47a46..f431a9d7 100644 --- a/en/devices/architecture/dto/multiple.html +++ b/en/devices/architecture/dto/multiple.html @@ -43,12 +43,18 @@ DTs.</figcaption> <p>The bootloader should be able to:</p> <ul> -<li>read the SoC ID and select the main DT correspondingly, and</li> -<li>read the board ID and select the overlay DT accordingly.</li> +<li>Read the SoC ID and select the corresponding main device tree, and</li> +<li>Read the board ID and select the set of overlay device trees accordingly. +</li> </ul> -<p>Only one main DT and one overlay DT are selected for use at runtime, and the -selected pair must be compatible.</p> +<p>Only one main DT should be selected for use at runtime. Multiple overlay DTs +may be selected but they must be compatible with the chosen main DT. Using +multiple overlays can help avoid storing one overlay per board within the DTBO +partition and enable the bootloader to determine the subset of required overlays +based on the board ID (or possibly by probing the peripherals). For +example, Board A may need the devices added by the overlays 1, 3, and 5 while +Board B may need the devices added by the overlays 1, 4, and 5.</p> <h2 id=partition>Partitioning</h2> <p>To partition, determine a bootloader runtime-accessible and trusted location diff --git a/en/devices/architecture/hidl-cpp/index.html b/en/devices/architecture/hidl-cpp/index.html index 7d8466cb..28c4aa0a 100644 --- a/en/devices/architecture/hidl-cpp/index.html +++ b/en/devices/architecture/hidl-cpp/index.html @@ -117,7 +117,7 @@ a binderized service. Example daemon code (for pure binderized service):</p> <pre class="prettyprint"> int main(int /* argc */, char* /* argv */ []) { - Nfc nfc = new Nfc(); + sp<INfc> nfc = new Nfc(); const status_t status = nfc->registerAsService(); if (status != ::android::OK) { return 1; // or handle error diff --git a/en/devices/architecture/hidl-java/index.html b/en/devices/architecture/hidl-java/index.html index 3b94247e..c4218160 100644 --- a/en/devices/architecture/hidl-java/index.html +++ b/en/devices/architecture/hidl-java/index.html @@ -136,7 +136,7 @@ to run the service is:</p> import android.hardware.foo.V1_0.IFoo; import android.hardware.foo.V1_0.IFooCallback.Stub; .... -class FooCallback extends IFoo.Stub { +class FooCallback extends IFooCallback.Stub { // implement methods } .... diff --git a/en/devices/architecture/hidl/versioning.html b/en/devices/architecture/hidl/versioning.html index 13bce259..52552f0c 100644 --- a/en/devices/architecture/hidl/versioning.html +++ b/en/devices/architecture/hidl/versioning.html @@ -112,6 +112,54 @@ types from the older version of the package, and inheritance of a subset of old-package interfaces.</li> </ul> +<h2 id=structuring>Structuring interfaces</h2> + +<p>For a well structured interface, adding new types of functionality that +are not part of the original design should require a modification to the HIDL +interface. Conversely, if you can or expect to make a change on both sides of +the interface that introduces new functionality without changing the interface +itself, then the interface is not structured.</p> + +<p>Treble supports separately-compiled vendor and system components in which the +<code>vendor.img</code> on a device and the <code>system.img</code> can be +compiled separately. All interactions between <code>vendor.img</code> and +<code>system.img</code> must be explicitly and thoroughly defined so they can +continue to work for many years. This includes many API surfaces, but a major +surface is the IPC mechanism HIDL uses for interprocess communication on the +<code>system.img</code>/<code>vendor.img</code> boundary.</p> + +<h3 id="structuring-requirements">Requirements</h3> +<p>All data passed through HIDL must be explicitly defined. To ensure an +implementation and client can continue to work together even when compiled +separately or developed on independently, data must adhere to the following +requirements:</p> + +<ul> +<li>Can be described in HIDL directly (using structs enums, etc.) with +semantic names and meaning.</li> +<li>Can be described by a public standard such as ISO/IEC 7816.</li> +<li>Can be described by a hardware standard or physical layout of hardware.</li> +<li>Can be opaque data (such as public keys, ids, etc.) if necessary.</li> +</ul> + +<p>If opague data is used, it must be read only by one side of the HIDL +interface. For example, if <code>vendor.img</code> code gives a component on the +<code>system.img</code> a string message or <code>vec<uint8_t></code> +data, that data cannot be parsed by the <code>system.img</code> itself; it can +only be passed back to <code>vendor.img</code> to interpret. <strong>When +passing a value from <code>vendor.img</code> to vendor code on +<code>system.img</code> or to another device, the format of the data and how it +is to be interpreted must be exactly described and is still part of the +interface</strong>.</p> + +<h3 id="structuring-guidelines">Guidelines</h3> + +<p>You should be able to write an implementation or client of a HAL using only +the .hal files (i.e. you should not need to look at the Android source or public +standards). We recommend specifying the exact required behavior. Statements such +as "an implementation may do A or B" encourage implementations to become +intertwined with the clients they are developed with.</p> + <h2 id=code-layout>HIDL code layout</h2> <p>HIDL includes core and vendor packages.</p> diff --git a/en/devices/tech/config/filesystem.html b/en/devices/tech/config/filesystem.html index 10b7f0b4..73633943 100644 --- a/en/devices/tech/config/filesystem.html +++ b/en/devices/tech/config/filesystem.html @@ -244,7 +244,8 @@ the autogenerated header file by adding to your module's <code>Android.mk</code> and including the empty faux library. For example, in <code>Android.mk</code>, add the following:</p> -<pre class="prettyprint"> LOCAL_STATIC_LIBRARIES := liboemaids</pre> +<pre class="prettyprint">LOCAL_HEADER_LIBRARIES := oemaids_headers</pre> + <p>In your C code, <code>#include "generated_oem_aid.h"</code> and start using the declared identifiers. For example, in <code>my_file.c</code>, add the following: </p> diff --git a/en/devices/tech/config/namespaces_libraries.html b/en/devices/tech/config/namespaces_libraries.html index b91cbe23..1e94bf1b 100644 --- a/en/devices/tech/config/namespaces_libraries.html +++ b/en/devices/tech/config/namespaces_libraries.html @@ -61,6 +61,26 @@ additional native libraries accessible to apps by putting them under the <code>/vendor/etc/public.libraries.txt</code> </p> +<p> +Starting from Android 8.0, vendor public libraries have the following additional +restrictions and required setups: +</p> + +<ol> + <li>The native library in vendor must be properly labeled so it can be + accessible to apps. If access is required by any apps (including third + party apps), the library must be labeled as <code>same_process_hal_file</code> + in a vendor-specific <code>file_contexts</code> file as follows: + <pre class="devsite-click-to-copy">/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0</pre> + where <code>libnative.so</code> is the name of the native library. + </li> + <li>The library, either directly or transitively via its dependencies, must not + depend on system libraries other than VNDK-SP and LLNDK libraries. The list of + VNDK-SP and LLNDK libraries can be found at + <code>development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv</code>. + </li> +</ol> + <h2 id="updating-app-non-public">Updating apps to not use non-public native libraries</h2> <p> diff --git a/en/devices/tech/config/perms-whitelist.html b/en/devices/tech/config/perms-whitelist.html index c3de0de0..918f89eb 100644 --- a/en/devices/tech/config/perms-whitelist.html +++ b/en/devices/tech/config/perms-whitelist.html @@ -135,7 +135,7 @@ transitional log-mode: </p> -<pre class="devsite-click-to-copy">ro.control_privapp_permission=log</pre> +<pre class="devsite-click-to-copy">ro.control_privapp_permissions=log</pre> <p> Violations are reported in the log file, but permissions are still granted. @@ -158,11 +158,11 @@ PackageManager: Privileged permission {PERMISSION_NAME} for package {PACKAGE_NAM <p> After whitelists are in place, enable runtime enforcement by setting the build - property <code>ro.control_privapp_permission=enforce</code>. + property <code>ro.control_privapp_permissions=enforce</code>. </p> <aside class="note"><strong>Note:</strong> The - <code>ro.control_privapp_permission</code> property state must adhere to + <code>ro.control_privapp_permissions</code> property state must adhere to <a href="/compatibility/android-cdd#9_1_permissions">CDD section 9.1 requirements</a>.</aside> diff --git a/en/devices/tech/config/uicc.html b/en/devices/tech/config/uicc.html index 1fa6952c..96c1d360 100644 --- a/en/devices/tech/config/uicc.html +++ b/en/devices/tech/config/uicc.html @@ -29,7 +29,7 @@ Android platform loads certificates stored on a UICC and grants permission to apps signed by these certificates to make calls to a handful of special APIs. </p> <p>Android 7.0 extends this feature to support other storage sources, such as -Access File Rule (ARF), for UICC carrier privilege rules, dramatically +Access Rule File (ARF), for UICC carrier privilege rules, dramatically increasing the number of carriers that can use the APIs. For an API reference, see <a href="#carrierconfigmanager">CarrierConfigManager</a>; for instructions, see <a href="/devices/tech/config/carrier.html">Carrier diff --git a/en/devices/tech/ota/ab/index.html b/en/devices/tech/ota/ab/index.html index 48a9fea5..c2a9c447 100644 --- a/en/devices/tech/ota/ab/index.html +++ b/en/devices/tech/ota/ab/index.html @@ -31,6 +31,9 @@ updates successfully. </p> + <p>For more information about A/B system updates and how they work, see + <a href="#slots">Partition selection (slots)</a>. + <p>A/B system updates provide the following benefits:</p> <ul> diff --git a/en/devices/tech/ota/index.html b/en/devices/tech/ota/index.html index 1565e3b2..7b2f0dd0 100644 --- a/en/devices/tech/ota/index.html +++ b/en/devices/tech/ota/index.html @@ -35,7 +35,7 @@ applications installed by the user from Google Play. </p> - <h2 id="ab_updates">A/B updates</h2> + <h2 id="ab_updates">A/B (seamless) system updates</h2> <p> Modern A/B devices have two copies of each partition, A and B. Devices @@ -50,7 +50,7 @@ </a>. </p> - <h2 id="nonab_updates">Non-A/B updates</h2> + <h2 id="nonab_updates">Non-A/B system updates</h2> <p> Older devices have a special recovery partition containing the software diff --git a/en/devices/tech/perf/boot-times.html b/en/devices/tech/perf/boot-times.html index a7588301..fb6ad441 100644 --- a/en/devices/tech/perf/boot-times.html +++ b/en/devices/tech/perf/boot-times.html @@ -255,17 +255,27 @@ us uncover many meaningful bugs in some Android device drivers). Many processes launch during boot, but only components in critical path (bootloader > kernel > init > file system mount > zygote > system server) directly affect boot time. Profile <strong>initcall</strong> during kernel -booting to identify peripheral/components that are not critical to the -start init process, then delay those peripherals/components until later -in the boot process. +booting to identify peripheral/components that are slow and not critical +to start init process, then delay those peripherals/components until later +in the boot process by moving into loadable kernel modules. Moving to +asynchronous device/driver probe can also help to parallel slow components +in kernel > init critical path. </p> <pre class="prettyprint"> BoardConfig-common.mk: BOARD_KERNEL_CMDLINE += initcall_debug ignore_loglevel + +driver: + .probe_type = PROBE_PREFER_ASYNCHRONOUS, </pre> +<p class="note"> +<strong>Note:</strong> Driver dependencies must be resolved carefully by adding +<code>EPROBEDEFER</code> support. +</p> + <h2 id="optimizing-i-o-efficiency">Optimizing I/O efficiency</h2> <p> @@ -422,6 +432,12 @@ early stage init should be deferred to boot completed.</li></ul> </li> </ul> +<p class="note"> +<strong>Note:</strong> Property service is part of init process, so calling +<code>setproperty</code> during boot can lead a long delay if init is busy in +builtin commands. +</p> + <h3 id="using-scheduler-tuning">Using scheduler tuning</h3> <p> |