src/devices/tech/config/connect_tests.jd

page.title=Network Connectivity Tests
@jd:body

<!--
    Copyright 2016 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.
-->
<div id="qv-wrapper">
  <div id="qv">
    <h2>In this document</h2>
    <ol id="auto-toc">
    </ol>
  </div>
</div>
<p>Android Connectivity Testing Suite (ACTS) tests fill the testing gap
between Android’s framework APIs and chipset certifications. These tests
validate the functionality of various aspects of the Bluetooth, Wi-Fi, and
cellular radios as used by the Android framework.</p>

<h2 id=users>Who should run ACTS tests?</h2>

<p>ACTS tests should be run by developers and integrators who are working on
connectivity (Bluetooth, Wi-Fi, and cellular) portions of the Android stack. If
you are adding new features, integrating a chipset or driver changes, these
tests are here to help you ensure that your changes are functional and stable
and that they meet basic standards of performance.</p>

<p>These tests are optional and are not required for any Android device
certification.</p>

<h2 id=how>How to run ACTS</h2>

<p>ACTS tests make use of privileged Android APIs to unlock a deeper level of
testing than would otherwise be possible. Thus, only engineering and userdebug
builds may be tested with ACTS.</p>

<p>ACTS tests are designed to run with minimal, mostly off-the-shelf hardware;
however, they do require some equipment, which varies based on the type of
testing. For many tests, two Android devices or a device and a WiFi access
point is sufficient. Please consult documentation specific to one of the major
test areas (Bluetooth, Wi-Fi, or cellular) to determine the specific setup
requirements.</p>

<h2 id=test-types>Test types</h2>

<h3 id=script-android>Scripting Layer for Android</h3>

<p>The <a
href="https://android.googlesource.com/platform/external/sl4a/+/master/README.md">Scripting
Layer for Android</a>, in <code><a
href="https://android.googlesource.com/platform/external/sl4a/"><platform>/external/sl4a</a></code>,
is a fork from an open source project of the same name. This tool provides a
thin RPC server to expose Android’s Java APIs. This allows tests to reside
off-device, which enables coordinated automation of devices and equipment for
richer more dynamic testing. Over the last 18 months, Google has trimmed,
updated, extended, and used this project to remotely exercise Android’s Java
APIs for testing wireless connectivity.</p>

<h3 id=script-native>Scripting Layer for Native</h3>

<p>The <a
href="https://android.googlesource.com/platform/packages/apps/Test/connectivity/+/master/sl4n/README.md">Scripting
Layer for Native</a>, in <code><a
href="https://android.googlesource.com/platform/packages/apps/Test/connectivity/"><platform>/packages/apps/Test/connectivity</a></code>,
is a new internally-grown RPC server for exposing Android’s native APIs in the
same manner as the Scripting Layer for Android exposes the Java APIs. This tools
is currently being used to test Brillo, and we expect this project will expand
rapidly to meet the test needs of the increasingly-critical native wireless
APIs.</p>

<h3 id=script-android>Android Comms Test Suite</h3>

<p>The <a
href="https://android.googlesource.com/platform/tools/test/connectivity/+/master/acts/README.md">Android
Comms Test Suite</a>, in <code><a
href="https://android.googlesource.com/platform/tools/test/connectivity/"><platform>/tools/test/connectivity</a></code>,
is a lightweight Python-based automation tool set that is used to perform
automated testing of current and upcoming Android devices. It provides a simple
execution interface; a set of pluggable libraries for accessing devices such as
attenuators and Android devices; and a collection of utility functions to
further ease test development. We think it’s an ideal desktop tool for a
wireless stack developer or integrator whether exercising a new code path,
performing basic sanity testing, or running extended regression test suites.</p>

<p>The test suite also includes a bundle of tests, many of which can be run with as
little as one or two Android devices with wifi, cellular, or bluetooth
connectivity, including:</p>

<ul>
<li>Wifi tests for AP IOT, Enterprise Connection, WifiScanner, Autojoin, and
RTT.
<li>Bluetooth tests for BLE, GATT, SPP, and Bonding.
<li>Cellular tests for CS and IMS calling, data connectivity, messaging, network
switching, and hotspot.</li>
</ul>

<p>We believe that the release of these tools will help developers, integrators,
and testers alike by lowering the barriers to basic testing and serving as a
rallying point around which the entire community can collaborate on improved
system test.</p>

<h2 id=failures-contributors>Failures and contributions</h2>

<p>ACTS tests are not a certification suite, and technically the tests do not
need to pass in order to release an Android device, though failing tests are
are likely to translate into a poor user experience. That said, if tests fail,
do not despair. Some of the tests are intentionally hard. Their purpose is to
help developers release high-performing devices.</p>

<p>ACTS is a relatively new undertaking, and involvement from the development
community is crucial. To add tests, report issues, or ask questions, please
start the conversation by opening a bug on the <a
href="https://code.google.com/p/android/issues/entry">Android Issue Tracker</a>
with the template connectivity-testing.</p>