20100326

1：out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/javalib.jar怎么解决？

2：Unable to get buffer of resource asset file。When building you might run into the Unable to get buffer of resource asset file error. The root cause of this is that the new android resource file resources.arsc is larger than the aapt tool allows. You can exchange the .arsc file inside android.jar with an older version or patch the aapt tool by editing frameworks/base/include/utils/Asset.h.
Change both lines UNCOMPRESS_DATA_MAX = 1 * 1024 * 1024 to something bigger. As the new resources file currently has a size of 2.3Mb you should change the lines (both lines mind you) to at least 3*1024*1024.

3：待解决的问题：验证QQ 和 Email 。提示没有 记录的通话记录。修改组名。

4：在其他编辑器中开发Android 应用。
Creating an Android Project

To create an Android project, you must use the android tool. When you create a new project with android, it will generate a project directory with some default application files, stub files, configuration files and a build file.
Creating a new Project

If you're starting a new project, use the android create project command to generate all the necessary files and folders.

To create a new Android project, open a command-line, navigate to the tools/ directory of your SDK and run:

android create project /
--target <target_ID> /
--name <your_project_name> /
--path /path/to/your/project /
--activity <your_activity_name> /
--package <your_package_namespace>

    * target is the "build target" for your application. It corresponds to an Android platform library (including any add-ons, such as Google APIs) that you would like to build your project against. To see a list of available targets and their corresponding IDs, execute: android list targets.
    * name is the name for your project. This is optional. If provided, this name will be used for your .apk filename when you build your application.
    * path is the location of your project directory. If the directory does not exist, it will be created for you.
    * activity is the name for your default Activity class. This class file will be created for you inside <path_to_your_project>/src/<your_package_namespace_path>/. This will also be used for your .apk filename unless you provide a the name.
    * package is the package namespace for your project, following the same rules as for packages in the Java programming language.

Here's an example:

android create project /
--target 1 /
--name MyAndroidApp /
--path ./MyAndroidAppProject /
--activity MyAndroidAppActivity /
--package com.example.myandroid

The tool generates the following files and directories:

    * AndroidManifest.xml - The application manifest file, synced to the specified Activity class for the project.
    * build.xml - Build file for Ant.
    * default.properties - Properties for the build system. Do not modify this file.
    * build.properties - Customizable properties for the build system. You can edit this file to override default build settings used by Ant and provide a pointer to your keystore and key alias so that the build tools can sign your application when built in release mode.
    * src/your/package/namespace/ActivityName.java - The Activity class you specified during project creation.
    * bin/ - Output directory for the build script.
    * gen/ - Holds Ant-generated files, such as R.java.
    * libs/ - Holds private libraries.
    * res/ - Holds project resources.
    * src/ - Holds source code.
    * tests/ - Holds a duplicate of all-of-the-above, for testing purposes.

Once you've created your project, you're ready to begin development. You can move your project folder wherever you want for development, but keep in mind that you must use the Android Debug Bridge (adb) — located in the SDK tools/ directory — to send your application to the emulator (discussed later). So you need access between your project solution and the tools/ folder.

Caution: You should refrain from moving the location of the SDK directory, because this will break the build scripts. (They will need to be manually updated to reflect the new SDK location before they will work again.)
Updating a project

If you're upgrading a project from an older version of the Android SDK or want to create a new project from existing code, use the android update project command to update the project to the new development environment. You can also use this command to revise the build target of an existing project (with the --target option) and the project name (with the --name option). The android tool will generate any files and folders (listed in the previous section) that are either missing or need to be updated, as needed for the Android project.

To update an existing Android project, open a command-line and navigate to the tools/ directory of your SDK. Now run:

android update project --name <project_name> --target <target_ID> --path path/to/your/project/

    * target is the "build target" for your application. It corresponds to an Android platform library (including any add-ons, such as Google APIs) that you would like to build your project against. To see a list of available targets and their corresponding IDs, execute: android list targets.
    * path is the location of your project directory.
    * name is the name for the project. This is optional—if you're not changing the project name, you don't need this.

Here's an example:

android update project --name MyApp --target 2 --path ./MyAppProject

Preparing to Sign Your Application

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.

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.
Building Your Application

There are two ways to build your application: one for testing/debugging your application — debug mode — and one for building your final package for release — release mode. As described in the previous section, your application must be signed before it can be installed on an emulator or device.

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 is installed onto the 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 (but only onto an emulator or attached development device). 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:/Prora~1/Java/. The easiest solution, however, is to install JDK in a non-space directory, for example: c:/java/jdk1.6.0_02.
Building in debug mode

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 zipalign. However, you can (and should) also test your application in release mode. Debug mode simply allows you to run your application without manually signing the application.

To build in debug mode:

   1. Open a command-line and navigate to the root of your project directory.
   2. Use Ant to compile your project 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 Your Application.
Building in release mode

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 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.
Build unsigned

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:

   1. Open a command-line and navigate to the root of your project directory.
   2. Use Ant to compile your project 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 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.
Build signed and aligned

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 build.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, buid unsigned and then continue with Signing Your Applications.

To specify your keystore and alias, open the project build.properties file (found in the root of the project directory) and add entries for key.store and 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:

   1. Open a command-line and navigate to the root of your project directory.
   2. Use Ant to compile your project in release mode:

      ant release

   3. When prompted, enter you keystore and alias passwords.

      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 build.properties and aligned with zipalign. It's ready for installation and distribution.
Once built and signed in release mode

Once you have signed your application with a private key, you can install it on an emulator or device as discussed in the following section about Running Your Application. 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.)
Running Your Application

Unless you'll be running your application on device hardware, you need to launch an emulator upon which you will install your application. An instance of the Android emulator runs a specific Android platform with specific device configuration settings. The platform and configuration is defined with an Android Virtual Device (AVD). So before you can launch your emulator, you must define an AVD.

If you'll be running your application on device hardware, please read about Developing On a Device instead.

   1. Create an AVD
         1. Open a command-line and navigate to your SDK package's tools/ directory.
         2. First, you need to select a "deployment target." To view available targets, execute:

            android list targets

            This will output a list of available Android targets, such as:

            id:1
                Name: Android 1.1
                Type: platform
                API level: 2
                Skins: HVGA (default), HVGA-L, HVGA-P, QVGA-L, QVGA-P
            id:2
                Name: Android 1.5
                Type: platform
                API level: 3
                Skins: HVGA (default), HVGA-L, HVGA-P, QVGA-L, QVGA-P

            Find the target that matches the Android platform upon which you'd like to run your application. Note the integer value of the id — you'll use this in the next step.
         3. Create a new AVD using your selected deployment target:

            android create avd --name <your_avd_name> --target <target_ID>

         4. Next, you'll be asked whether you'd like to create a custom hardware profile. If you respond "yes," you'll be presented with a series of prompts to define various aspects of the device hardware (leave ent而且是老爸向别人借的钱给我参加培训的，老爸说再穷也不能耽误我学业，老爸是个很开明的人。至于我上次丢了钱包也好像若无其事的样子，并不是我丢的起，而是当时我钱包了没什么钱。况且丢都丢了，总不能一直悲伤下去，生活还要继续，在丢了情况下我唯一可以做的就是让损失变得最小。也许他们觉得我的穿着有些另类，和一般搞软件的女孩不同，忘了告诉他们我是双子座，喜欢新鲜，不喜欢一层不变的生活，懂得幽默，有时也会很浪漫。你可能看到我身上穿了名牌，其实我穿的是冒牌货，假的。现在听了之后还会认为我是富二代吗？ries blank to use default values, which are shown in brackets). Otherwise, press return to use all default values ("no" is the default).
   2. Launch an emulator

      From your SDK's tools/ directory, launch an emulator using an existing AVD (created above):

      emulator -avd <your_avd_name>

      An instance of the emulator will now launch, running the target and configuration defined by your AVD.
   3. Install your application

      From your SDK's tools/ directory, install the .apk on the emulator:

      adb install /path/to/your/application.apk

      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 /my/project/path/myapp.apk

   4. Open your application

      In the emulator, open the list of available applications to find and open your application.

If you don't see your application on the emulator. Try restarting the emulator (with the same AVD). Sometimes when you install an Activity 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.

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. If there is more than one emulator currently running when using the install command, it will fail — it can't select between the multiple emulators.

For more information on the tools used above, please see the following documents:

    * android Tool
    * Android Emulator
    * Android Debug Bridge (ADB)

Attaching a Debugger to Your Application

This section describes how to display debug information on the screen (such as CPU usage), as well as how to hook up your IDE to debug running applications on the emulator.

Attaching a debugger is automated using the Eclipse plugin, but you can configure other IDEs to listen on a debugging port to receive debugging information:

   1. Start the Dalvik Debug Monitor Server (DDMS) tool, which acts as a port forwarding service between your IDE and the emulator.
   2. Set optional debugging configurations on your emulator, such as blocking application startup for an Activity until a debugger is attached. Note that many of these debugging options can be used without DDMS, such as displaying CPU usage or screen refresh rate on the emulator.
   3. Configure your IDE to attach to port 8700 for debugging. Read about Configuring Your IDE to Attach to the Debugging Port.