en/devices/tech/connect/connect_tests.html - platform/docs/source.android.com - Git at Google

 <html devsite>
   <head>
     <title>Network Connectivity Tests</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 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>

   </body>
 </html>
	<html devsite>
	<head>
	<title>Network Connectivity Tests</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 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>

	</body>
	</html>