icon in the toolbar.- Important: Support for the Android Developer Tools (ADT) in Eclipse is ending, - per our announcement. You should migrate your app development projects to - Android Studio as soon as possible. For more information on transitioning to Android Studio, see - Migrating to Android Studio. -
- -Android offers a custom plugin for the Eclipse IDE, called Android -Development Tools (ADT). This plugin provides a powerful, integrated -environment in which to develop Android apps. It extends the capabilities -of Eclipse to let you quickly set up new Android projects, build an app -UI, debug your app, and export signed (or unsigned) app packages (APKs) for distribution. -
- -You should install the ADT plugin -only if you already have an Eclipse installation that you want to continue using. -Your existing Eclipse installation must meet these requirements:
-Note: Eclipse 3.6 (Helios) is no longer -supported with the latest version of ADT.
To add the ADT plugin to Eclipse:
-https://dl-ssl.google.com/android/eclipse/-
Note: The Android Developer Tools update site requires - a secure connection. Make sure the update site URL you enter starts with HTTPS.
-If you get a security warning saying that the authenticity or validity of -the software can't be established, click OK.
Once Eclipse restarts, you - must specify the location of your Android SDK directory:
- -Your Eclipse IDE is now set up to develop Android apps, but you need to add -the latest SDK platform tools and an Android platform to your environment. -To get these packages for your SDK, continue to -Adding Platforms and Packages.
- - -If you are having trouble downloading the ADT plugin after following the -steps above and you are behind a firewall (such as a corporate firewall), make sure that -you have properly configured your proxy settings in Eclipse. In Eclipse, -you can configure proxy information from the main Eclipse menu in -Window (on Mac OS X, Eclipse) > -Preferences > General > Network -Connections. -
- -If you are still unable to use Eclipse to download the ADT plugin as a -remote update site, you can download the ADT zip file to your local machine and -manually install it:
- -| Package | -Size | -MD5 Checksum | -
|---|---|---|
| - {@adtZipDownload} - | -{@adtZipBytes} bytes | -{@adtZipChecksum} | -
If you get a security warning saying that the authenticity or validity of -the software can't be established, click OK.
To update your plugin once you've installed using the zip file, you will have -to follow these steps again instead of the default update instructions.
- -Note that there are features of ADT that require some optional -Eclipse packages (for example, WST). If you encounter an error when -installing ADT, your Eclipse installation might not include these packages. -For information about how to quickly add the necessary packages to your -Eclipse installation, see the troubleshooting topic -ADT -Installation Error: "requires plug-in org.eclipse.wst.sse.ui".
- -If you encounter this error when installing the ADT Plugin for Eclipse: -
-An error occurred during provisioning. -Cannot connect to keystore. -JKS-
-...then your development machine lacks a suitable Java VM. Installing Sun -Java 6 will resolve this issue and you can then reinstall the ADT -Plugin.
- diff --git a/docs/html/sdk/installing/migrate.jd b/docs/html/sdk/installing/migrate.jd index 6dedad6d52c07..61e6798dc0e55 100644 --- a/docs/html/sdk/installing/migrate.jd +++ b/docs/html/sdk/installing/migrate.jd @@ -1,4 +1,4 @@ -page.title=Migrating to Android Studio +page.title=Migrating from Eclipse ADT @jd:body diff --git a/docs/html/tools/building/building-cmdline-ant.jd b/docs/html/tools/building/building-cmdline-ant.jd deleted file mode 100644 index add6ca26c558b..0000000000000 --- a/docs/html/tools/building/building-cmdline-ant.jd +++ /dev/null @@ -1,389 +0,0 @@ -page.title=Building and Running from the Command Line -parent.title=Building and Running -parent.link=index.html -@jd:body - -- Important: Support for Ant as a build tool for Android is ending, per our - announcement. You should migrate your app development projects to - Android Studio and Gradle as soon as possible. For more information on transitioning to these - tools, see Migrating to Android Studio. -
- -There are two ways to build your application using the Ant build script: one for - testing/debugging your application — debug mode — and one for building your - final package for release — release mode. Regardless of which way you build your application, - it must be signed before it can install on an emulator or device—with a debug key when building - in debug mode and with your own private key when building in release mode.
- -Whether you're building in debug mode or release mode, you need to use the Ant tool to compile - and build your project. This will create the .apk file that you can install on an emulator or device. - When you build in debug mode, the .apk file is automatically signed by the SDK tools with - a debug key, so it's instantly ready for installation onto an emulator or attached - development device. You cannot distribute an application that is signed with a debug key. - When you build in release mode, the .apk file is unsigned, so you - must manually sign it with your own private key, using Keytool and Jarsigner.
- -It's important that you read and understand Signing Your Applications, particularly once - you're ready to release your application and share it with end-users. That document describes the - procedure for generating a private key and then using it to sign your .apk file. If you're just - getting started, however, you can quickly run your applications on an emulator or your own - development device by building in debug mode.
- -If you don't have Ant, you can obtain it from the Apache Ant - home page. Install it and make sure it is in your executable PATH. Before calling Ant, you - need to declare the JAVA_HOME environment variable to specify the path to where the JDK is - installed.
- -Note: When installing JDK on Windows, the default is to install
- in the "Program Files" directory. This location will cause ant to fail, because of
- the space. To fix the problem, you can specify the JAVA_HOME variable like this:
-
set JAVA_HOME=c:\Progra~1\Java\<jdkdir>- -
The easiest solution, however, is to install JDK in a non-space directory, for example:
- -c:\java\jdk1.7- -
For immediate application testing and debugging, you can build your application in debug mode - and immediately install it on an emulator. In debug mode, the build tools automatically sign your - application with a debug key and optimize the package with {@code zipalign}.
- -To build in debug mode:
- --ant debug -- -
This creates your debug .apk file inside the project bin/ directory, named
- <your_project_name>-debug.apk. The file is already signed with
- the debug key and has been aligned with
- zipalign.
-
Each time you change a source file or resource, you must run Ant again in order to package up - the latest version of the application.
- -To install and run your application on an emulator, see the following section about Running on the Emulator.
- -When you're ready to release and distribute your application to end-users, you must build your - application in release mode. Once you have built in release mode, it's a good idea to perform - additional testing and debugging with the final .apk.
- -Before you start building your application in release mode, be aware that you must sign the - resulting application package with your private key, and should then align it using the {@code - zipalign} tool. There are two approaches to building in release mode: build an unsigned package - in release mode and then manually sign and align the package, or allow the build script to sign - and align the package for you.
- -If you build your application unsigned, then you will need to manually sign and align - the package.
- -To build an unsigned .apk in release mode:
- --ant release --
This creates your Android application .apk file inside the project bin/
- directory, named <your_project_name>-unsigned.apk.
Note: The .apk file is unsigned at this point and can't - be installed until signed with your private key.
- -Once you have created the unsigned .apk, your next step is to sign the .apk with your private - key and then align it with {@code zipalign}. To complete this procedure, read Signing Your Applications.
- -When your .apk has been signed and aligned, it's ready to be distributed to end-users.
- You should test the final build on different devices or AVDs to ensure that it
- runs properly on different platforms.
If you would like, you can configure the Android build script to automatically sign and align - your application package. To do so, you must provide the path to your keystore and the name of - your key alias in your project's {@code ant.properties} file. With this information provided, - the build script will prompt you for your keystore and alias password when you build in release - mode and produce your final application package, which will be ready for distribution.
- -Caution: Due to the way Ant handles input, the password that - you enter during the build process will be visible. If you are concerned about - your keystore and alias password being visible on screen, then you may prefer to perform the - application signing manually, via Jarsigner (or a similar tool). To instead perform the signing - procedure manually, build unsigned and then continue with - Signing Your Applications.
- -To specify your keystore and alias, open the project {@code ant.properties} file (found in - the root of the project directory) and add entries for {@code key.store} and {@code key.alias}. - For example:
--key.store=path/to/my.keystore -key.alias=mykeystore -- -
Save your changes. Now you can build a signed .apk in release mode:
- --ant release --
Caution: As described above, your password will be - visible on the screen.
-This creates your Android application .apk file inside the project bin/
- directory, named <your_project_name>-release.apk. This .apk file has
- been signed with the private key specified in {@code ant.properties} and aligned with {@code
- zipalign}. It's ready for installation and distribution.
Once you have signed your application with a private key, you can install and run it on an - emulator or device. You can - also try installing it onto a device from a web server. Simply upload the signed .apk to a web - site, then load the .apk URL in your Android web browser to download the application and begin - installation. (On your device, be sure you have enabled - Settings > Applications > Unknown sources.)
- -Before you can run your application on the Android Emulator, you must create an AVD.
- -To run your application:
- -From your SDK's platform-tools/ directory, execute the {@code android} tool
-with the avd options:
-android avd -- -
In the Virtual Devices view, select an AVD and click Start.
-From your SDK's tools/ directory, install the {@code .apk} on the
- emulator:
-adb install <path_to_your_bin>.apk -- -
Your .apk file (signed with either a release or debug key) is in your project {@code bin/} - directory after you build your application.
- -If there is more than one emulator running, you must specify the emulator upon which to
- install the application, by its serial number, with the -s option. For
- example:
-adb -s emulator-5554 install path/to/your/app.apk -- -
To see a list of available device serial numbers, execute {@code adb devices}.
-If you don't see your application on the emulator, try closing the emulator and launching the - virtual device again from the AVD Manager. Sometimes when you install an application for the - first time, it won't show up in the application launcher or be accessible by other applications. - This is because the package manager usually examines manifests completely only on emulator - startup.
- -Be certain to create multiple AVDs upon which to test your application. You should have one - AVD for each platform and screen type with which your application is compatible. For instance, if - your application compiles against the Android 4.0 (API Level 14) platform, you should create an - AVD for each platform equal to and greater than 4.0 and an AVD for each screen type you support, then test your - application on each one.
- -Tip: If you have only one emulator running, you can
- build your application and install it on the emulator in one simple step. Navigate to the root of
- your project directory and use Ant to compile the project with install mode: ant
- install. This will build your application, sign it with the debug key, and install it on
- the currently running emulator.
Before you can run your application on a device, you must perform some basic setup for your - device:
- -Note: On Android 4.2 and newer, Developer - options is hidden by default. To make it available, go - to Settings > About phone and tap Build number - seven times. Return to the previous screen to find Developer options.
-Read Setting up a Device for - Development for more information.
- -Once your device is set up and connected via USB, navigate to your SDK's platform-tools/
- directory and install the .apk on the device:
-adb -d install path/to/your/app.apk -- -
The {@code -d} flag specifies that you want to use the attached device (in case you also have - an emulator running).
- -For more information on the tools used above, please see the following documents:
- -As you begin developing Android applications, understand that all Android applications must be - digitally signed before the system will install them on an emulator or device. There are two ways - to do this: with a debug key (for immediate testing on an emulator or development - device) or with a private key (for application distribution).
- -The Android build tools help you get started by automatically signing your .apk files with a - debug key at build time. This means that you can compile your application and install it on the - emulator without having to generate your own private key. However, please note that if you intend - to publish your application, you must sign the application with your own private - key, rather than the debug key generated by the SDK tools.
- -The ADT plugin helps you get started quickly by signing your .apk files with a debug key, - prior to installing them on an emulator or development device. This means that you can quickly - run your application from Eclipse without having to generate your own private key. No specific - action on your part is needed, provided ADT has access to Keytool. However, please note that if - you intend to publish your application, you must sign the application with your - own private key, rather than the debug key generated by the SDK tools.
- -Please read Signing Your - Applications, which provides a thorough guide to application signing on Android and what it - means to you as an Android application developer. The document also includes a guide to exporting - and signing your application with the ADT's Export Wizard.
- -ant cleanall target before clean
-(ant all clean), other projects are also cleaned. For instance if you clean a
-test project, the tested project is also cleaned.ant debugant emma debugant releaseant instrument
- emma
- target)ant <build_target> installinstall by itself fails.ant installd.apk is not
- already built.ant installr.apk is not
- already built.ant installt.apk of the
- tested application. This fails if the .apk is not already built.ant installi.apk is not already
- built.ant test.apk files must be
- previously installed.ant debug installt test.apk files, and
- runs the tests.ant emma debug install test.apk files, and
- runs the tests with code coverage enabled.Eclipse and ADT provide an environment where most of the details of the build process are - hidden from you. By default, the build process constantly runs in the background as you make - changes to your project.
- -When Eclipse automatically builds your application, it enables debugging and signs the
- .apk with a debug key, by default. When you run the application,
- Eclipse invokes ADB and installs your application to a device or emulator, so you do not have to
- manually perform these tasks. Since most of the build process is taken care of by Eclipse, the
- following topics show you how to run an application, which will automatically build your
- application as well.
To distribute your application, however, you must build your application in release mode and
- sign the .apk file with your own private key.
This document shows you how to run your application on an emulator or a real device - from Eclipse—all of which is done using the debug version of your application. - For more information about how to sign your application with a private key for release, see Signing Your Applications
- -Before you can run your application on the Android Emulator, you must create an AVD.
- -To run (or debug) your application, select Run > Run (or - Run > Debug) from the Eclipse menu bar. The ADT plugin will - automatically create a default run configuration for the project. Eclipse will then perform the - following:
- -By default, Android run configurations use an "automatic target" mode for selecting a - device target. For information on how automatic target mode selects a deployment target, see - Automatic and manual target modes below.
-If you run the application with the Debug option, the application will start in the "Waiting For Debugger" mode. Once the debugger - is attached, Eclipse opens the Debug perspective and starts the application's main activity. Otherwise, if you run the - application with the normal Run option, Eclipse installs the application on the device and launches the main activity.
- -To set or change the run configuration used for your project, use the run configuration - manager. See the section below about Creating a Run Configuration for more information.
- -Be certain to create multiple AVDs upon which to test your application. You should have one - AVD for each platform and screen type with which your application is compatible. For instance, if - your application compiles against the Android 4.0 (API Level 14) platform, you should create an - AVD for each platform equal to and greater than 4.0 and an AVD for each screen type you support, then test your - application on each one.
- -Before you can run your application on a device, you must perform some basic setup for your - device:
- -android:debuggable attribute of the <application>
- element to true. As of ADT 8.0, this is done by default when you build in debug mode.Note: On Android 4.2 and newer, Developer - options is hidden by default. To make it available, go - to Settings > About phone and tap Build number - seven times. Return to the previous screen to find Developer options.
-Read Using Hardware Devices - for more information.
- -Once set up and your device is connected via USB, install your application on the device by - selecting Run > Run (or Run > - Debug) from the Eclipse menu bar.
- -The run configuration specifies the project to run, the Activity to start, the emulator or - connected device to use, and so on. When you first run a project as an Android - Application, ADT will automatically create a run configuration. The default run - configuration will launch the default project Activity and use automatic target mode for device - selection (with no preferred AVD). If the default settings don't suit your project, you can - customize the run configuration or even create a new one.
- -To create or modify a run configuration, refer to the Eclipse documentation on how to create Run configurations. - The following steps highlight the important things you need to do for an Android project:
- -In the Target tab, consider whether you'd like to use Manual or Automatic mode when - selecting an AVD to run your application. See the following section on Automatic and manual target modes).
- -You can specify any emulator options to the Additional Emulator Command Line Options
- field. For example, you could add -scale 96dpi to scale the AVD's screen to an
- accurate size, based on the dpi of your computer monitor. For a full list of emulator
- options, see the Android
- Emulator document.
By default, a run configuration uses the automatic target mode in order to - select an AVD. In this mode, ADT will select an AVD for the application in the following - manner:
- -However, if a "preferred AVD" is selected in the run configuration, then the application will - always be deployed to that AVD. If it's not already running, then a new emulator will be - launched.
- -If your run configuration uses manual mode, then the "device chooser" is - presented every time that your application is run, so that you can select which AVD to use.
diff --git a/docs/html/tools/debugging/debugging-projects.jd b/docs/html/tools/debugging/debugging-projects.jd deleted file mode 100644 index 2283f8be9f6dd..0000000000000 --- a/docs/html/tools/debugging/debugging-projects.jd +++ /dev/null @@ -1,67 +0,0 @@ -page.title=Debugging from Eclipse with ADT -parent.title=Debugging -parent.link=index.html -@jd:body - -If you are developing in Eclipse with the ADT plugin, you can use the built-in Java Debugger, - along with DDMS, to debug your applications. To access the debugger and - DDMS, Eclipse displays the debugger and DDMS features as perspectives, which are customized - Eclipse views that display certain tabs and windows depending on the perspective that you are in. - Eclipse also takes care of starting the ADB host daemon for you, so you do not have to run this - manually.
- -The Debug Perspective in Eclipse gives you access to the following tabs:
- -You can access the Debug Perspective by clicking Window > Open Perspective > - Debug. Refer to the appropriate documentation for the Eclipse debugger for more - information.
- -The DDMS Perspective in Eclipse lets you access all of the features - of DDMS from within the Eclipse IDE. The following sections of DDMS are available to you:
- -To access the DDMS perspective, go to Window > Open Perspective > - DDMS. If DDMS does not appear, go to Window > Open Perspective > Other - ... and select DDMS from the Open Perspective window that appears. For - more information on using DDMS, see Using the Dalvik Debug Monitor Server. -
\ No newline at end of file diff --git a/docs/html/tools/help/adt.jd b/docs/html/tools/help/adt.jd index 0fac62d332e7d..7d29d02ce5b43 100644 --- a/docs/html/tools/help/adt.jd +++ b/docs/html/tools/help/adt.jd @@ -2,540 +2,23 @@ page.title=Android Developer Tools page.tags=adt @jd:body -- Important: Support for the Android Developer Tools (ADT) in Eclipse is ending, + Important: Support for the Android Developer Tools (ADT) in Eclipse has ended, per our announcement. You should migrate your app development projects to Android Studio as soon as possible. For more information on transitioning to Android Studio, see - Migrating to Android Studio. + Migrating from Eclipse ADT.
-Android Developer Tools (ADT) is a plugin for Eclipse that provides a suite of - tools that are integrated with the Eclipse IDE. It offers you access to many features that help - you develop Android applications. ADT - provides GUI access to many of the command line SDK tools as well as a UI design tool for rapid - prototyping, designing, and building of your application's user interface.
+Formerly the official IDE solution for Android development, Android Developer Tools (ADT) + is a plugin for Eclipse that provides GUI-based access to many of the command-line SDK tools, + along with a UI design tool for rapid prototyping, designing, and building of your app's + user interface.
-If you still wish to use the ADT plugin for Eclipse, see -Installing Eclipse Plugin. -
- - -The Android - Asset Studio is a web-based tool that lets you generate icons from existing images, - clipart, or text. It also generates the icons with different DPIs for different screen sizes and - types.
- -Many of the tools that you can start or run from the command line are integrated into ADT. - They include:
- -android features such as creating or
- updating projects (application and library) are integrated throughout the Eclipse IDE. adb are integrated into ADT such as project installation (Eclipse run menu),
- file transfer, device enumeration, and logcat (DDMS). You must access the more advanced
- features of adb, such as shell commands, from the command line.In addition to Eclipse's standard editor features, ADT provides custom XML editors to help - you create and edit Android manifests, resources, menus, and layouts in a form-based or graphical - mode. Double-clicking on an XML file in Eclipse's package explorer opens the - appropriate XML editor. - -
View the segment on the XML editors for more - information.
-Note: You can edit Android-specific XML files (such as a layout -or manifest) in both a graphical mode and also an XML markup mode. You can switch between -these modes with the pair of tabs at the bottom of each custom XML editor.
- -In addition, some special file types that don't have custom editors, such as drawables, animations, - and color files offer editing enhancements such as XML tag completion.
- -ADT provides the following custom, form-based XML editors:
- -res/layout. For more information, see Graphical Layout
- Editor.AndroidManifest.xml file.<menu> declared (usually located in
- the res/menu folder).<resources> tag declared.In addition to the normal code editing features of Eclipse, ADT provides enhancements to the Android - development experience that allow you to quickly jump to declarations of various types of resources such - as strings or layout files. You can access these enhancements by holding down the control key and - clicking on the following items: - -
R.id.button1, jumps
- to the XML definition of the view.R.java file, such as public
- static final int Button01=0x7f050000", jumps to the corresponding XML definition.<activity android:name=".TestActivity">, jumps to the corresponding Java class. You can
- jump from an activity definition (or service definition) into the corresponding Java class.@string:foo), regardless of
-which XML file
- "foo" is defined in.@layout/bar, opens the file.@drawable/icon, launches
- Eclipse's default application for the given file type, which in this case is an
- image.@android namespace resources opens the resources found in
- the SDK install area.<foo.bar.MyView></foo.bar.MyView>,
- or <view class="foo.bar.MyView">) jump to the corresponding custom view classes.@android:string/ok or android.R.string.id in Java code
- opens the file that declares the strings. The XML tab opens when doing this, not
- the form-based editor.ADT provides many features to allow you to design and build your application's user interface. - Many of these features are in the graphical layout editor, which you can access by opening one of - your application's XML layout files in Eclipse. +
As with ADT, support for the Ant + tool for building from the command line has ended. + Gradle is now the supported method + of building Android apps.
- -The graphical layout editor is the main screen that you use to visually design and build your - UI. It is split up into the following parts:
- -The canvas also provides - context-sensitive actions in the layout actions bar, such as adjusting layout margins and -orientation. - The layout actions bar displays available actions depending on the selected UI element in the - canvas.
-
-
- Figure 1. Graphical layout editor
- -View the segment on the canvas and outline view and the - layout actions bar - for more information. -
-The canvas is the area where you can drag and drop UI widgets from the palette to design your - layout. The canvas offers a rendered preview of your layout depending on factors such as the - selected platform version, screen orientation, and currently selected theme that you specify in - the configuration chooser. You can also drag and drop - items into the outline view, which displays your layout in a hierarchical list. The outline view - exposes much of the same functionality as the canvas but offers another method of organization - that is beneficial for ordering and quickly selecting items. When you right-click a specific item - in the canvas or outline view, you can access a context-sensitive menu that lets you modify the - following attributes of the layout or view:
- -View the segment on the animation features for more - information.
-The canvas has additional features not available in the outline view:
- -
-
- Figure 2. Canvas portion of the layout editor showing - a rendered preview of an application
- -Figure 3. Outline view showing current layout's structure
- -View the segment on the palette for more information.
-The palette contains the UI widgets that you can drag and drop onto the canvas and add to your - layout. The pallete categorizes the widgets and shows rendered previews - for easier lookup. The main features of the palette include:
- -
-
- Figure 4. Palette showing available UI widgets
- -View the segment on the configuration chooser for more - information.
-The configuration chooser allows you to create and configure different configurations of - a layout for different situations, such as one for landscape and one for portrait mode. You can - set the following options for each configuration of a layout: -
-
-
- Figure 5. Configuration chooser
- -View the segment on refactoring features for a rundown -of the more important refactoring features.
- -In both the graphical and XML layout editor, there are many features that help you quickly - refactor your layouts. The following list describes the major refactoring support:
- -<Button> widget named
- "button1"), then the ID is changed to match the new widget type and all
- references are updated.include tag that points to the newly created layout file is inserted
- into the existing layout file. Right-click the view or layout and select Extract as
- Include....styles.xml file. You can select multiple views and this refactoring extracts all
- of the same styles into one style and assigns that style to all the views that use it.layout_
- attribute references to the new root, For example, suppose you have a {@link android.widget.RelativeLayout}.
- If other widgets have layout constraints pointing to your widget, wrapping the widget causes
- these constraints to point to the parent instead.From time to time, a new revision of the ADT Plugin becomes available, with -new features and bug fixes. Generally, when a new revision of ADT is available, -you should update to it as soon as convenient.
- -In some cases, a new revision of ADT will have a dependency on a specific -revision of the Android SDK Tools. If such dependencies exist, you will need to -update the SDK Tools package of the SDK after installing the new revision of -ADT. To update the SDK Tools package, use the Android SDK Manager, as -described in Adding SDK Packages.
- -To learn about new features of each ADT revision and also any dependencies on -the SDK Tools, see the listings in the Revisions -section. To determine the version currently installed, open the -Eclipse Installed Software window using Help -> Software Updates and refer to the version listed for -"Android Development Tools".
- -Follow the steps below to check whether an update is available and, if so, -to install it.
- -If there are no updates available, a dialog will say so and you're done.
If you encounter problems during the update, remove the existing ADT plugin from Eclipse, then -perform a fresh installation, using the instructions for Installing the ADT -Plugin.
diff --git a/docs/html/tools/projects/projects-eclipse.jd b/docs/html/tools/projects/projects-eclipse.jd deleted file mode 100644 index af8501572f648..0000000000000 --- a/docs/html/tools/projects/projects-eclipse.jd +++ /dev/null @@ -1,273 +0,0 @@ -page.title=Managing Projects from Eclipse with ADT -parent.title=Managing Projects -parent.link=index.html -@jd:body - -Eclipse and the ADT plugin provide GUIs and wizards to create all three types of projects - (Android project, Library project, and Test project): - -
The ADT plugin provides a New Project Wizard that you can use to quickly create a new - Android project (or a project from existing code). To create a new project:
- -minSdkVersion attribute in the
- <uses-sdk>
- element of your manifest file.Note: You can change the target SDK for your - project at any time: Right-click the project in the Package Explorer, select - Properties, select Android and then check the desired - Project Build Target.
-Tip: You can also start the New Project Wizard by clicking the
- New icon in the toolbar.
A library project is a standard Android project, so you can create a new one in the same way - as you would a new application project.
- -To create a new library project:
- -You can also convert an existing application project into a library. To do so, simply open the - Properties for the project and select the is Library checkbox, as shown in - the figure below.
- -
- Figure 1. Marking a project as an Android library.
- -To set the a project's properties to indicate that it is a library project:
- -Once you create a library project or mark an existing project as a library, you can reference - the library project in other Android application projects. For more information, see the - Referencing a library project section. - - -
A library project's manifest file must declare all of the shared components that it includes, - just as would a standard Android application. For more information, see the documentation for - AndroidManifest.xml.
- -For example, the TicTacToeLib example library
- project declares the activity GameActivity:
-<manifest> - ... - <application> - ... - <activity android:name="GameActivity" /> - ... - </application> -</manifest> -- -
If you are developing an application and want to include the shared code or resources from a - library project, you can do so easily by adding a reference to the library project in the - application project's Properties.
- -To add a reference to a library project, follow these steps:
- -As soon as the Properties dialog closes, Eclipse rebuilds the project, including the contents - of the library project.
- -Figure 2 shows the Properties dialog that lets you add library references and move - them up and down in priority.
-
- Figure 2. Adding a reference to a - library project in the properties of an application project.
- -If you are adding references to multiple libraries, note that you can set their relative - priority (and merge order) by selecting a library and using the Up and - Down controls. The tools merge the referenced libraries with your application - starting from lowest priority (bottom of the list) to highest (top of the list). If more than one - library defines the same resource ID, the tools select the resource from the library with higher - priority. The application itself has highest priority and its resources are always used in - preference to identical resource IDs defined in libraries.
- -In the manifest file of the application project, you must add declarations of all components
- that the application will use that are imported from a library project. For example, you must
- declare any <activity>, <service>,
- <receiver>, <provider>, and so on, as well as
- <permission>, <uses-library>, and similar elements.
Declarations should reference the library components by their fully-qualified package names, - where appropriate.
- -For example, the TicTacToeMain example
- application declares the library activity GameActivity like this:
-<manifest> - ... - <application> - ... - <activity android:name="com.example.android.tictactoe.library.GameActivity" /> - ... - </application> -</manifest> -- -
For more information about the manifest file, see the documentation for AndroidManifest.xml.
- - - - - - - diff --git a/docs/html/tools/publishing/app-signing-eclipse.jd b/docs/html/tools/publishing/app-signing-eclipse.jd deleted file mode 100644 index 738e488683196..0000000000000 --- a/docs/html/tools/publishing/app-signing-eclipse.jd +++ /dev/null @@ -1,64 +0,0 @@ -page.title=Signing Your Applications from Eclipse with ADT -@jd:body - -Android requires that all apps be digitally signed with a certificate before they can be -installed. Android uses this certificate to identify the author of an app, and the certificate -does not need to be signed by a certificate authority.
- -This document provides detailed instructions about how to sign your apps in release mode with the -ADT plugin for Eclipse. For information about how to obtain a certificate for signing your app, see -Signing Your Applications. -
- - -To sign your app for release with ADT, follow these steps:
- -On the next window, enter the location to create a keystore and a keystore password. If you -already have a keystore, select Use existing keystore, enter your keystore's -location and password, and go to step 6.
-
-Figure 6. Select a keystore in ADT.
-On the next window, provide the required information as shown in figure 5.
-
Your key should be valid for at least 25 years, so you can sign app updates with the same key -through the lifespan of your app.
-
-Figure 7. Create a private key in ADT.
-On the next window, select the location to export the signed APK.
-
-Figure 8. Export the signed APK in ADT.
-- This topic explains how create and run tests of Android applications in Eclipse with ADT. - Before you read this topic, you should read about how to create an Android application with the - basic processes for creating and running applications with ADT, as described in - Managing Projects from -Eclipse - and Building and Running -from Eclipse. - You may also want to read - Testing Fundamentals, - which provides an overview of the Android testing framework. -
-- ADT provides several features that help you set up and manage your testing environment - effectively: -
-<instrumentation> element in the test package's manifest file.
- - If you are not developing in Eclipse or you want to learn how to create and run tests from the - command line, see - Testing from Other IDEs. -
-
- To set up a test environment for your Android application, you must first create a separate
- project that holds the test code. The new project follows the directory structure
- used for any Android application. It includes the same types of content and files, such as
- source code, resources, a manifest file, and so forth. The test package you
- create is connected to the application under test by an
-
- <instrumentation> element in its manifest file.
-
- The New Android Test Project dialog makes it easy for you to generate a
- new test project that has the proper structure, including the
- <instrumentation> element in the manifest file. You can use the New
- Android Test Project dialog to generate the test project at any time. The dialog appears
- just after you create a new Android main application project, but you can also run it to
- create a test project for a project that you created previously.
-
- To create a test project in Eclipse with ADT: -
-- The name becomes part of the suggested project path, but you can change this in the - next step. -
-/usr/local/workspace and your project name is
- MyTestApp, then the wizard will suggest
- /usr/local/workspace/MyTestApp. To enter your own
- choice for a path, unselect Use default location, then enter or browse to the
- path where you want your project.
- - To learn more about choosing the location of test projects, please read - - Testing Fundamentals. -
-- Once you have created a test project, you populate it with a test package. This package does not - require an Activity, although you can define one if you wish. Although your test package can - combine Activity classes, test case classes, or ordinary classes, your main test case - should extend one of the Android test case classes or JUnit classes, because these provide the - best testing features. -
-- Test packages do not need to have an Android GUI. When you run the package in - Eclipse with ADT, its results appear in the JUnit view. Running tests and seeing the results is - described in more detail in the section Running Tests. -
- -- To create a test package, start with one of Android's test case classes defined in - {@link android.test android.test}. These extend the JUnit - {@link junit.framework.TestCase TestCase} class. The Android test classes for Activity objects - also provide instrumentation for testing an Activity. To learn more about test case - classes, please read the topic - Testing Fundamentals. -
-- Before you create your test package, you choose the Java package identifier you want to use - for your test case classes and the Android package name you want to use. To learn more - about this, please read - - Testing Fundamentals. -
-- To add a test case class to your project: -
-- You now have to ensure that the constructor is set up correctly. Create a constructor for your - class that has no arguments; this is required by JUnit. As the first statement in this - constructor, add a call to the base class' constructor. Each base test case class has its - own constructor signature. Refer to the class documentation in the documentation for - {@link android.test} for more information. -
-
- To control your test environment, you will want to override the setUp() and
- tearDown() methods:
-
setUp(): This method is invoked before any of the test methods in the class.
- Use it to set up the environment for the test (the test fixture. You can use
- setUp() to instantiate a new Intent with the action ACTION_MAIN.
- You can then use this intent to start the Activity under test.
- tearDown(): This method is invoked after all the test methods in the class. Use
- it to do garbage collection and to reset the test fixture.
-
- Another useful convention is to add the method testPreconditions() to your test
- class. Use this method to test that the application under test is initialized correctly. If this
- test fails, you know that the initial conditions were in error. When this happens, further
- test results are suspect, regardless of whether or not the tests succeeded.
-
- The Resources tab contains an - Activity Testing - tutorial with more information about creating test classes and methods. -
-- If you've created your tests in Eclipse, you can still run your tests and test - suites by using command-line tools included with the Android SDK. You may want - to do this, for example, if you have a large number of tests to run, if you - have a large test case, or if you want a fine level of control over which - tests are run at a particular time. -
-
- To run tests created in Eclipse with ADT with command-line tools, you must first
- install additional files into the test project using the android
- tool's "create test-project" option. To see how to do this, read
-
- Testing in Other IDEs.
-
- When you run a test package in Eclipse with ADT, the output appears in the Eclipse JUnit view.
- You can run the entire test package or one test case class. To do run tests, Eclipse runs the
- adb command for running a test package, and displays the output, so there is no
- difference between running tests inside Eclipse and running them from the command line.
-
- As with any other package, to run a test package in Eclipse with ADT you must either attach a - device to your computer or use the Android emulator. If you use the emulator, you must have an - Android Virtual Device (AVD) that uses the same target as the test package. -
-- To run a test in Eclipse, you have two choices:
-- Creating and running test configurations is described in the next section. -
-- To create and run a test suite using a run configuration: -
-- To run all the test classes, click Run all tests in the selected project or package, - then enter the project or package name in the text box. -
-Note: - Although you can run the test immediately by clicking Run, you should save the test - first and then run it by selecting it from the Eclipse standard toolbar. -
-
- The progress of your test appears in the Console view as a series of messages. Each message is
- preceded by a timestamp and the .apk filename to which it applies. For example,
- this message appears when you run a test to the emulator, and the emulator is not yet started:
-
- The examples shown in this section come from the - SpinnerTest - sample test package, which tests the - Spinner - sample application. This test package is also featured in the - Activity Testing - tutorial. -
-
- [yyyy-mm-dd hh:mm:ss - testfile] Waiting for HOME ('android.process.acore') to be launched...
-
-
- In the following description of these messages, devicename is the name of
- the device or emulator you are using to run the test, and port is the
- port number for the device. The name and port number are in the format used by the
- adb devices
- command. Also, testfile is the .apk filename of the test
- package you are running, and appfile is the filename of the application under test.
-
- HOME is up on device 'devicename-port'
-
- Uploading testfile onto device 'devicename-port'
-
-
- then the message Installing testfile.
-
- and finally the message Success!
-
- The following lines are an example of this message sequence: -
-
-[2010-07-01 12:44:40 - MyTest] HOME is up on device 'emulator-5554'
-[2010-07-01 12:44:40 - MyTest] Uploading MyTest.apk onto device 'emulator-5554'
-[2010-07-01 12:44:40 - MyTest] Installing MyTest.apk...
-[2010-07-01 12:44:49 - MyTest] Success!
-
-
- Project dependency found, installing: appfile
-
- then the message Uploading appfile onto device
- 'devicename-port'
-
- then the message Installing appfile
-
- and finally the message Success!
-
- The following lines are an example of this message sequence: -
-
-[2010-07-01 12:44:49 - MyTest] Project dependency found, installing: MyApp
-[2010-07-01 12:44:49 - MyApp] Uploading MyApp.apk onto device 'emulator-5554'
-[2010-07-01 12:44:49 - MyApp] Installing MyApp.apk...
-[2010-07-01 12:44:54 - MyApp] Success!
-
-Launching instrumentation instrumentation_class on device
- devicename-port
-
- instrumentation_class is the fully-qualified class name of the
- instrumentation test runner you have specified (usually
- {@link android.test.InstrumentationTestRunner}.
-
- Collecting test information
-
- followed by -
-
- Sending test information to Eclipse
-
Running tests, which indicates that your tests
- are running. At this point, you should start seeing the test results in the JUnit view.
- When the tests are finished, you see the console message Test run complete.
- This indicates that your tests are finished.
- - The following lines are an example of this message sequence: -
-
-[2010-01-01 12:45:02 - MyTest] Launching instrumentation android.test.InstrumentationTestRunner on device emulator-5554
-[2010-01-01 12:45:02 - MyTest] Collecting test information
-[2010-01-01 12:45:02 - MyTest] Sending test information to Eclipse
-[2010-01-01 12:45:02 - MyTest] Running tests...
-[2010-01-01 12:45:22 - MyTest] Test run complete
-
-- The test results appear in the JUnit view. This is divided into an upper summary pane, - and a lower stack trace pane. -
-- The upper pane contains test information. In the pane's header, you see the following - information: -
-- The body of the upper pane contains the details of the test run. For each test case class - that was run, you see a line with the class name. To look at the results for the individual - test methods in that class, you click the left arrow to expand the line. You now see a - line for each test method in the class, and to its right the time it took to run. - If you double-click the method name, Eclipse opens the test class source in an editor view - pane and moves the focus to the first line of the test method. -
-- The results of a successful test are shown in figure 1. -
- -
-
-- Figure 1. Messages for a successful test. -
-- The lower pane is for stack traces. If you highlight a failed test in the upper pane, the - lower pane contains a stack trace for the test. If a line corresponds to a point in your - test code, you can double-click it to display the code in an editor view pane, with the - line highlighted. For a successful test, the lower pane is empty. -
-The results of a failed test are shown in figure 2.
- -
-
-- Figure 2. Messages for a test failure. -
diff --git a/docs/html/tools/tools_toc.cs b/docs/html/tools/tools_toc.cs index d8275b578a013..12aecd98f5172 100644 --- a/docs/html/tools/tools_toc.cs +++ b/docs/html/tools/tools_toc.cs @@ -17,7 +17,7 @@