aboutsummaryrefslogtreecommitdiff
path: root/en/devices
diff options
context:
space:
mode:
Diffstat (limited to 'en/devices')
-rw-r--r--en/devices/tech/admin/testing-provision.html55
-rw-r--r--en/devices/tech/config/perms-whitelist.html8
-rw-r--r--en/devices/tech/connect/esim-modem-requirements.md79
-rw-r--r--en/devices/tech/debug/fuzz-sanitize.html8
4 files changed, 93 insertions, 57 deletions
diff --git a/en/devices/tech/admin/testing-provision.html b/en/devices/tech/admin/testing-provision.html
index 0891ffa4..ddd83775 100644
--- a/en/devices/tech/admin/testing-provision.html
+++ b/en/devices/tech/admin/testing-provision.html
@@ -23,29 +23,32 @@
-<p>The Android for Work (AfW) Test Harness is a test suite for validating the
-AfW compatibility of Android devices. It includes support apps, test cases,
-configuration files, and a test runner (<code>afw-test-tradefed</code>) built on
-<code>cts-tradefed</code>. You should setup and run the AfW Test Harness after
-completing <a href="/devices/tech/admin/provision.html">Provisioning
-for Device Administration</a>.</p>
-
-<p class=note><strong>Note:</strong> Building and running the AfW Test Harness
+<p>The Android Enterprise (AE) Test Harness is a test suite for validating the
+enterprise compatibility of Android devices. It includes support apps, test
+cases, configuration files, and a test runner (<code>afw-test-tradefed</code>)
+built on <code>cts-tradefed</code>. You should setup and run the AE Test Harness
+after completing <a href="/devices/tech/admin/provision.html">Provisioning for
+Device Administration</a>.</p>
+
+<p class=note><strong>Note:</strong> Building and running the AE Test Harness
is similar to building and running the Android
<a href="/compatibility/cts/index.html">Compatibility Test Suite (CTS)</a>.</p>
+<p>Many of the tools, directories, and branch names include the <em>AfW</em>
+label. Android for Work (AfW) is a previous name for Android's enterprise
+features.</p>
+
<h2 id=setup_env>Setting up a development environment</h2>
-<p>The development environment for the AfW Test Harness is similar to Android
-OS. Follow the steps in
-<a href="/setup/requirements.html">Requirements</a> to set up a
-development machine.</p>
+<p>The development environment for the AE Test Harness is similar to Android OS.
+Follow the steps in <a href="/setup/requirements.html">Requirements</a> to set up
+a development machine.</p>
<h2 id=download_source>Downloading source code</h2>
-<p>Download the AfW Test Harness source code using the steps in
-<a href="/setup/downloading.html">Downloading the Source</a>. The AfW
+<p>Download the AE Test Harness source code using the steps in
+<a href="/setup/downloading.html">Downloading the Source</a>. The AE
Test Harness source code is in the <code>./test/AfwTestHarness</code> project.
-The branch name determines the version of AfW Test Harness to download (each
-Android platform has a separate version of AfW Test Harness). For Android 7.0,
+The branch name determines the version of AE Test Harness to download (each
+Android platform has a separate version of AE Test Harness). For Android 7.0,
the branch name is <code>afw-test-harness-nougat-dev</code>. To initialize
the repo and download source code for this branch, use:</p>
@@ -88,7 +91,7 @@ the corresponding tag. Available branches include:</p>
with the source code.</p>
<h3 id=view_studio>Viewing in Android Studio</h3>
-<p>To view and edit AfW source code in Android Studio:</p>
+<p>To view and edit the source code in Android Studio:</p>
<ol>
<li>Run the following commands
<pre class="devsite-click-to-copy">
@@ -99,9 +102,9 @@ with the source code.</p>
<li>In Android Studio, open <code>android.ipr</code>.</li>
</ol>
-<p>The AfW Test Harness source code is in <code>test/AfwTestHarness</code>.</p>
+<p>The AE Test Harness source code is in <code>test/AfwTestHarness</code>.</p>
-<h2 id=config_harness>Configuring the AfW Test Harness</h2>
+<h2 id=config_harness>Configuring the AE Test Harness</h2>
<p>You can customize the harness by configuring
<code>test/AfwTestHarness/afw-test.props</code>. To run the harness
successfully, complete the following steps:</p>
@@ -121,12 +124,12 @@ with the following properties:
work_account_username
work_account_password
</pre>
-<p>The AfW Test Harness uses Test DPC to test provisioning flows, so accounts
+<p>The AE Test Harness uses Test DPC to test provisioning flows, so accounts
<strong>must</strong> bind to Test DPC to run the test harness.</p>
</li>
</ol>
-<h2 id=build_harness>Building the AfW Test Harness</h2>
+<h2 id=build_harness>Building the AE Test Harness</h2>
<p>Initialize the build configuration using:</p>
<pre class="devsite-click-to-copy">
<code class="devsite-terminal">source build/envsetup.sh</code>
@@ -145,8 +148,8 @@ harness. This directory is also zipped into a file
(<code>out/host/linux-x86/afw-th/android-afw-test-harness.zip</code>)
for distribution.</p>
-<h2 id=run_harness>Running the AfW Test Harness</h2>
-<p>Use the following steps to run the AfW Test Harness:</p>
+<h2 id=run_harness>Running the AE Test Harness</h2>
+<p>Use the following steps to run the AE Test Harness:</p>
<ol>
<li>In your build environment, launch the test runner using:
<pre class="devsite-terminal devsite-click-to-copy">
@@ -194,7 +197,7 @@ To view all packages, use the command <code>list packages</code>. For more
options, use the command <code>run cts --help</code>.</li>
</ol>
-<h2 id=debug_harness>Debugging the AfW Test Harness</h2>
+<h2 id=debug_harness>Debugging the AE Test Harness</h2>
<p>Run all commands in the afw-test-tradefed console (<code>cts-tf</code>),
which you can launch by running <code>afw-test-tradefed</code>.</p>
<ul>
@@ -247,8 +250,8 @@ out/host/linux-x86/afw-th/android-cts/repository/logs/<em>start-time</em>/host_l
</li>
</ul>
</li>
-<li>A test package automates an AfW provisioning flow by going through UI pages
-and recording a navigation log in the device logcat file for each page.
+<li>A test package automates an enterprise provisioning flow by going through UI
+pages and recording a navigation log in the device logcat file for each page.
Example: <code>afwtest.AutomationDriver:
Navigating:com.android.afwtest.uiautomator.pages.gms.AddAccountPage</code>
<br>UI pages for test package
diff --git a/en/devices/tech/config/perms-whitelist.html b/en/devices/tech/config/perms-whitelist.html
index 918f89eb..8f91f9fa 100644
--- a/en/devices/tech/config/perms-whitelist.html
+++ b/en/devices/tech/config/perms-whitelist.html
@@ -31,6 +31,14 @@
permissions.
</p>
+<aside class="note">
+ <strong>Note:</strong>
+ Whitelisting is required only for
+ <a href="https://developer.android.com/guide/topics/manifest/permission-element">permissions</a>
+ declared by applications with
+ <a href="https://developer.android.com/guide/topics/manifest/manifest-element#package">package</a>="android".
+</aside>
+
<h2 id="adding-whitelists">Adding whitelists</h2>
<p>
Permission whitelists for applications can be listed in a single or multiple
diff --git a/en/devices/tech/connect/esim-modem-requirements.md b/en/devices/tech/connect/esim-modem-requirements.md
index a67fb83d..f1c16776 100644
--- a/en/devices/tech/connect/esim-modem-requirements.md
+++ b/en/devices/tech/connect/esim-modem-requirements.md
@@ -24,22 +24,40 @@ removable eSIM 4FF card.
## General requirements
-These are the modem requirements for general eSIM support. The LPA needs the
-modem to support all of these requirements to function properly.
+These are the modem requirements for general eSIM support. The Local Profile
+Assistant (LPA) needs the modem to support all of these requirements to function
+properly.
### Handle the default boot profile correctly
When there is no operational or test profile enabled on eSIM, the default boot
profile is enabled. The modem shall recognize the eSIM with the default boot
-profile enabled as a valid SIM. The modem shall report card as valid to upper
-layers and shall not turn off the SIM power.
+profile enabled as a valid SIM, shall report the card as valid to upper layers,
+and shall not turn off the SIM power.
### Send terminal capabilities correctly
-When opening a logical channel to ISD-R, the modem shall send correct terminal
-capabilities to the eSIM. The terminal capability must encode support for eUICC
-capabilities: "Local Profile Management" and "Profile Download" per ETSI TS 102
-221.
+On power-up, the modem shall send correct terminal capabilities to the eSIM. The
+terminal capability shall encode support for eUICC capabilities: "Local Profile
+Management" and "Profile Download".
+
+See
+[ETSI TS 102 221 Section 11.1.19.2.4](https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/15.00.00_60/ts_102221v150000p.pdf):
+“Additional Terminal capability indications related to eUICC". Bytes [1-3] shall
+be: ‘83 (Tag) ‘01’ (Length) ‘07’ (eUICC capabilities).
+
+### (Optional) Support eSIM OS OTA updates
+
+Note: As eSIM OS over-the-air (OTA) updates are not standardized, this depends
+on the vendor providing the eSIM OS.
+
+The modem shall support all requirements for eSIM OS OTA updates, for example
+switching to passthrough mode and keeping the eSIM powered on during the OTA
+update procedure.
+
+## HAL requirements
+
+These are API implementations that are required for general eSIM support.
### Implement setSimPower API in Radio HAL v1.1
@@ -55,37 +73,42 @@ API, which indicates whether a slot contains an eSIM.
### Implement getIccCardStatus API in IRadio HAL v1.2
-The modem shall provide the ATR and slot ID of the card status as specified in
-the
-[getIccCardStatus](/reference/hidl/android/hardware/radio/1.0/IRadio#getIccCardStatus)
-API. This API was first introduced in v1.0 and, in v1.2,
+The modem shall provide the Answer To Reset (ATR) and slot ID of the card status
+in the
+[getIccCardStatusResponse](https://source.android.com/reference/hidl/android/hardware/radio/1.0/IRadioResponse#geticccardstatusresponse)
+API. This API was introduced in v1.0 and, in v1.2,
[CardStatus](https://android.googlesource.com/platform/hardware/interfaces/+/master/radio/1.2/types.hal#341){: .external}
was changed to include
[ATR](https://android.googlesource.com/platform/hardware/interfaces/+/master/radio/1.2/types.hal#351){: .external}.
-### (Optional) Support eSIM OS OTA
+### Set CardState:RESTRICTED on SIM lock (subsidy lock)
-As the eSIM OS OTA is not standardized, this depends on the vendor providing
-eSIM OS. The modem shall support all requirements for eSIM OS OTA, for example
-switching to passthrough mode and keeping the eSIM powered on during the OTA
-procedure.
+If the eSIM is SIM locked (subsidy locked), the modem shall set card state as
+[`CardState:RESTRICTED`](https://source.android.com/reference/hidl/android/hardware/radio/1.0/types#cardstate)
+in the
+[getIccCardStatusResponse](https://source.android.com/reference/hidl/android/hardware/radio/1.0/IRadioResponse#geticccardstatusresponse)
+API.
-## Logging requirements
+### (Optional) Implement setSimSlotsMapping API in IRadioConfig HAL v1.0
-These are general modem logging requirements to properly debug eSIM issues.
+Note: Only required in device configurations that require slot switching, for
+example, where the device has one eSIM slot and one physical/removable SIM
+(pSIM) slot, and only one can be active at the same time.
-### Provide PC based tools to capture detailed modem logs
+The modem shall support the
+[setSimSlotsMapping API](https://android.googlesource.com/platform/hardware/interfaces/+/master/radio/config/1.0/IRadioConfig.hal#81){: .external},
+which sets the mapping from physical slots to logical slots. The LPA uses this
+API to select the active SIM slot.
+
+## Logging requirements
-Logging shall capture all the OTA packets for Cellular RATs (4G, 3G, 2G) and IMS
-(SIP, RTP, RTCP, XCAP). ESP protected SIP packets shall be logged without ESP.
-OTA parser shall be compliant to 3GPP specs.
+These are general modem logging requirements for debugging eSIM issues.
-Logging shall support capture IP packets on all network interfaces.
+### Log capture
-Logging shall support capturing debug logs and protocol layer information
-including protocol layer states, radio power measurements, network cell
-information, packet TX/RX statistics, inter-layer messaging, inter-processor
-communication, SIM functionality & APDU logging, and RIL logging.
+Logging shall capture inter-processor communication, SIM functionality, Radio
+Interface Layer (RIL) logging, and application protocol data unit (APDU)
+logging.
### On-device logging
diff --git a/en/devices/tech/debug/fuzz-sanitize.html b/en/devices/tech/debug/fuzz-sanitize.html
index 55c517da..2c3308ca 100644
--- a/en/devices/tech/debug/fuzz-sanitize.html
+++ b/en/devices/tech/debug/fuzz-sanitize.html
@@ -1,6 +1,6 @@
<html devsite>
<head>
- <title>Dynamic Analysis</title>
+ <title>Security Testing</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
@@ -21,8 +21,8 @@
limitations under the License.
-->
- <p>This section summarizes useful tools for dynamic analysis and debugging
- from a security perspective. It covers some tools for fuzzing, sanitizing,
+ <p>This section summarizes tools for security testing and debugging.
+ It covers some tools for fuzzing, sanitizing,
and preemptively mitigating exploits. For general debugging, see
<a href="/devices/tech/debug/">the debugging section</a>.</p>
@@ -31,4 +31,6 @@ While Android has supported fuzzing tools for many releases, Android 8.0
and later include more fuzzing support, tighter fuzzing tool integration in the
Android build system, and greater dynamic analysis support on the Android kernels.
</p>
+<p>In addition to security-specific testing, Android includes general
+<a href="/compatibility/tests">platform testing</a> for compatibility.</p>
</body></html>