page.title=Features page.metaDescription=Learn about the Android Studio features. page.tags=studio, features @jd:body
If you're new to Android Studio or exploring recent updates, this page provides an introduction to some key Android Studio features.
For specific Android Studio how-to documentation, see the pages in the Workflow section, such as Managing Projects from Android Studio and Building and Running from Android Studio.
Multi-language support is enhanced with the Translations Editor plugin so you can easily add a variety of locales to the app's translation file. With BCP 47 support, the editor combines language and region codes into a single selection for targeted localizations. Color codes indicate whether a locale is complete or still missing string translations.
To access the Translations Editor, open a strings.xml
file and click the
Open Editor link, or click the globe icon
() in the Design layout view.
Figure 1. Add locales and strings in the Translations Editor.
Clicking Import Samples from the File menu or Welcome page provides seamless access to Google code samples on GitHub.
Figure 2. Get code samples from GitHub.
Figure 3. Imported code sample.
Android Studio supports templates for Google Services and expands the available device types.
For easy cross-platform development, the Project Wizard provides templates for creating your apps for Android Wear and TV.
Figure 4. Supported form factors.
During app creation, the Project Wizard also displays an API Level dialog to help you choose the best minSdkVersion for your project.
Quick cloud integration. Using Google App Engine to connect to the Google cloud and create a cloud end-point is as easy as selecting File > New Module > App Engine Java Servlet Module and specifying the module, package, and client names.
Figure 5 Google App Engine integration.
Android Studio provides setting dialogs so you can manage the most important Android Studio and
project settings from the File > Project Structure and
File > Settings menus. For example, you can use the
File > Project Structure menu or
the build.gradle
file to update your productFlavor
settings.
Additional settings from the File > Project Structure menus include:
buildTypes
Use the File > Settings menu to modify the Android Studio or project behavior, such a UI themes, system settings, and version control.
Android Studio provides the {@code finger} command, allowing you to simulate, and thus validate, fingerprint authentication for your app. After you set up your app to accept fingerprint authentication, your emulator or device should display the fingerprint authentication screen, as shown below.
Figure 6 Fingerprint authentication.
Open a terminal session, and telnet to the emulator. For example:
{@code telnet localhost 5554}
Enter the finger
command to simulate finger touch and removal:
finger touch <fingerprint-id>
to simulate a finger touching the sensorfinger remove
to simulate finger removal Your app should respond as if a user touched, and then removed their finger from, the fingerprint sensor.
Android Studio supports enabling these developer services in your app:
Enabling a developer service adds the required dependencies and, when applicable, also modifies
the related configuration files. To activate the service, you must perform
service-specific updates, such as loading an ad in the MainActivity
class for ad
display.
To enable an Android developer service, select the File > Project Structure
menu option and click a service under the Developer Services sub-menu. The service
configuration page appears. In the service configuration page, click the service check box to
enable the service and click OK. Android Studio updates your library dependencies
for the selected service and, for Analytics, updates the AndroidManifest.xml
and
other tracker configuration files. You can enable multiple services within the same app. For more
detail about starting the services, refer to each service's specific activation instructions.
By default, Android Studio treats all library resources as public: A public library resource is available to library clients for use outside the library, and appears in code completion suggestions and other resource references. Android Studio also, however, supports the use of private library resources. A private library resource can only be used within the source library, and does not appear in code completion lists and other resource references.
You cannot explicitly declare a library resource as private. Instead, if you declare any library resources as public, Android Studio assumes all the other library resources are private.
An app treats all Android library resources as public unless you explicitly declare at least one resource in the library as public. Declaring one public resource causes your app to treat all other, undeclared resources in the library as private.
Note: Declaring public and private resources requires the Android Plugin for Gradle version 1.3 or higher.
To declare a resource as public and set other undeclared resources as private, add a
<public>
declaration with the resource name and type in the resource file.
This example shows the public declaration for the mylib_app_name
string resource.
<resources> <public name="mylib_app_name" type="string"/> </resources>
For large numbers of declarations, we recommended that you place the public marker declarations
in a separate file named public.xml
.
To help enforce private resource access, a lint warning appears when a client of a library references a private resource. Many Android libraries, such as the Design Support Library and the v7 appcompat Library, declare public resources to display only resources that developers can directly reference.
Note: If your app requires a private resource, copy the private resource from the library to the location in your app where it is needed.
When the build system builds an Android Archive (AAR) file, it extracts the
<public>
resource declarations into a public.txt
file, which is
packaged inside the AAR file next to the R.txt
file. The public.txt
file
contains a simple list of the declared public resources, describing their names and types.
For a complete list of the available Android resource types, see Resource Types and More Resource Types.
Android Studio supports the
Material Design themes, widgets, and
graphics, such as shadow layers and API version rendering (showing the layout across different
UI versions). Also, the drawable XML tags and attributes, such as <ripple>
and <animated-selector>
, are supported.
Android Studio supports adding a separate test
module to your app so you can
generate a test APK. This test
module resides at the same level as your app and
contains: the tests and instrumentation used to run the test APK on an Android device; an
Android Manifest.xml
file for test APK configuration settings; and, a
build.gradle
file for build settings.
The test
module cannot contain a src/androidTest/
folder and does
not support build variants. If you have different product flavors in your main application APK,
create a different test module for each build variant.
To create a test APK module:
test
module consisting of the following directories and files:
./test/
./test/build.gradle
./test/src/main/java/com/android/tests/basic/MainTest.java
./test/src/main/AndroidManifest.xml
build.gradle
file, add the required properties to the
android
block.
targetProjectPath ':<app name>'
specifies the main application APK
to test. targetVariant ':<buildType>'
specifies the target build type.Here is an example of build.gradle
file property settings:
android { compileSdkVersion 19 buildToolsVersion = ‘21.1.3’ targetProjectPath ':app' targetVariant 'debug' }
Here is an example of <instrumentation>
settings in the manifest file:
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.tests.basic.test"> <uses-sdk android:minSdkVersion="16" android:targetSdkVersion="16" /> <application> >uses-library android:name="android.test.runner" /> </application> <instrumentation android:name="android.test.InstrumentationTestRunner" android:targetPackage="com.android.tests.basic" android:handleProfiling="false" android:functionalTest="false" android:label="Tests for com.android.tests.basic"/> </manifest<
Note: The targetPackage
in the instrumentation
settings specifies the package of the test variant.
build.gradle
file for the tested app, include additional artifacts
that the test APK requires, such as the classes.jar
file, by adding the
{@code publishNonDefault} property to the {@code Android} block, and assigning that property
a value of {@code true}.
Here is an example of the build.gradle
file that includes additional
artifacts:
android { compileSdkVersion 19 buildToolsVersion = ‘21.1.3’ publishNonDefault true }
In the {@code test} module in this example, the {@code build.gradle} file specifies the properties for the project path and target build type variant.
Figure 3. Test module for APK testing.
Note: By default, the test module's build variant uses the
debug
build type. You can configure additional build types using the
testBuildType
property in the defaultConfig
block in the main
app's build.gradle
file.