Android/APP&SDK2011/07/12 14:24
[Android Developer]
 

SDK Tools, Revision 12


Dependencies:
If you are developing in Eclipse with ADT, note that the SDK Tools r12 is designed for use with ADT 12.0.0 and later. If you haven't already, we highly recommend updating your ADT Plugin to 12.0.0.
If you are developing outside Eclipse, you must have Apache Ant 1.8 or later.
General notes:
The AVD manager and emulator can now use system images compiled for ARM v7 and x86 CPUs. 


ADT 12.0.0

Dependencies:
ADT 12.0.0 is designed for use with SDK Tools r12. If you haven't already installed SDK Tools r12 into your SDK, use the Android SDK and AVD Manager to do so.
Visual Layout Editor:
  • New RelativeLayout drop support with guideline suggestions for attachments and cycle prevention (more info).
  • Resize support in most layouts along with guideline snapping to the sizes dictated by wrap_content and match_parentPreviews of drawables and colors in the resource chooser dialogs (more info).
  • Previews of drawables and colors in the resource chooser dialogs (more info).
  • Improved error messages and links for rendering errors including detection of misspelled class names (more info).
Build system
  • A new option lets you disable the packaging step in the automatic builders. This improves performance when saving files by not performing a full build, which can take a long time for large projects. If the option is enabled, the APK is packaged when the application is deployed to a device or emulator or when the release APK is exported (more info).
Bug fixes
Many bug fixes are part of this release (more info). 


NDK, Revision 6

This release of the NDK includes support for the x86 ABI and other minor changes. For detailed information describing the changes in this release, read the CHANGES.HTML document included in the NDK package.

General notes:
  • Adds support for the x86 ABI, which allows you to generate machine code that runs on compatible x86-based Android devices. Major features for x86 include x86-specific toolchains, system headers, libraries and debugging support. For all of the details regarding x86 support, see docs/CPU-X86.html in the NDK package.

    By default, code is generated for ARM-based devices, but you can add x86 to your APP_ABI definition in your Application.mk file to build for x86 platforms. For example, the following line instructs ndk-build to build your code for three distinct ABIs:

    APP_ABI := armeabi armeabi-v7a x86


    Unless you rely on ARM-based assembly sources, you shouldn't need to touch your Android.mk files to build x86 machine code. 
  • You can build a standalone x86 toolchain using the --toolchain=x86-4.4.3 option when calling make-standalone-toolchain.sh. See docs/STANDALONE-TOOLCHAIN.html for more details.
  • The new ndk-stack tool lets you translate stack traces in logcat that are generated by native code. The tool translates instruction addresses into a readable format that contains things such as the function, source file, and line number corresponding to each stack frame. For more information and a usage example, see docs/NDK-STACK.html.
Other changes:
arm-eabi-4.4.0, which had been deprecated since NDK r5, has been removed from the NDK distribution. 
 
저작자 표시 비영리 동일 조건 변경 허락

'Android > APP&SDK' 카테고리의 다른 글

SDK Tools, r12 & ADT 12.0.0 & NDK r6  (0) 2011/07/12
ADT Plugin for Eclipse 11.0.0  (0) 2011/06/07
ADT 10.0.1  (0) 2011/03/17
SDK Tools r10 & ADT 10.0.0  (0) 2011/03/11
SDK Tools r9 & ADT 9.0.0 & NDK r5b  (0) 2011/01/27
SDK Tools, r8 & ADT 8.0.0 & NDK, r5 for Gingerbread  (0) 2010/12/07
Posted by mirwing
Android/APP&SDK2011/06/07 17:06
Dependencies:
ADT 11.0.0 is designed for use with SDK Tools r11. If you haven't already installed SDK Tools r11 into your SDK, use the Android SDK and AVD Manager to do so.
Visual Refactoring:
  • "Extract Style" feature pulls out style-related attributes from your layout and extracts them as a new style defined in styles.xml (more info).
  • "Wrap in Container" feature lets you select a group of views then surround them in a new layout (a new view group, such as a LinearLayout), and transfers namespace and layout parameters to the new parent (more info).
  • "Change Layout" feature changes layouts from one type to another, and can also flatten a layout hierarchy (more info).
  • "Change Widget Type" feature changes the type of the selected views to a new type. Also, a new selection context menu in the visual layout editor makes it easy to select siblings as well as views anywhere in the layout that have the same type (more info).
  • "Extract as Include" feature finds identical collections of views in other layouts and offers to combine them into a single layout that you can then include in each layout (more info).
  • Quick Assistant in Eclipse can be invoked from the XML editor (with Ctrl-1) to apply any of the above refactorings (and Extract String) to the current selection (more info).
Visual Layout Editor:
  • This is the update to the layout editor you've been waiting for! It includes (almost) all the goodies demonstrated at Google I/O. Watch the video on YouTube.
  • The palette now supports different configurations for supported widgets. That is, a single view is presented in various different configurations that you can drag into your layout. For example, there is a Text Fields palette category where you can drag an EditText widget in as a password field, an e-mail field, a phone field, or other types of text boxes. Similarly, TextView widgets are preconfigured with large, normal and small theme sizes, and LinearLayout elements are preconfigured in horizontal and vertical configurations (more info).
  • The palette supports custom views. You can pick up any custom implementations of the View class you've created in your project or from included libraries and drag them into your layout (more info).
  • Fragments are available in the palette for placement in your layout. In the tool, you can choose which layout to show rendered for a given fragment tag. Go to declaration works for fragment classes (more info).
  • The layout editor automatically applies a "zoom to fit" for newly opened files as well as on device size and orientation changes to ensure that large layouts are always fully visible unless you manually zoom in.
  • You can drop in an <include> element from the palette, which will pop up a layout chooser. When you select the layout to include, it is added with an <include>. Similarly, dropping images or image buttons will pop up image resource choosers (more info).
  • The configuration chooser now applies the "Render Target" and "Locale" settings project wide, making it trivial to check the layouts for different languages or render targets without having to configure these individually for each layout.
  • The layout editor is smarter about picking a default theme to render a layout with, consulting factors like theme registrations in the manifest, the SDK version, and other factors.
  • The layout editor is smarter about picking a default configuration to render a layout with, defaulting to the currently visible configuration in the previous file. It also considers the SDK target to determine whether to default to a tablet or phone screen size.
  • Basic focus support. The first text field dropped in a layout is assigned focus, and there are Request Focus and Clear Focus context menu items on text fields to change the focus.
XML editors:
  • Code completion has been significantly improved. It now works with <style> elements, completes dimensional units, sorts resource paths in values based on the attribute name, and more. There are also many fixes to handle text replacement (more info).
  • AAPT errors are handled better. They are now underlined for the relevant range in the editor, and a new quickfix makes it trivial to create missing resources.
  • Code completion for drawable, animation and color XML files (more info).
DDMS:
  • "New Folder" action in the File Explorer.
  • The screenshot dialog will add timestamps to the filenames and preserve the orientation on snapshot refresh.
General notes:
  • TraceView supports zooming with the mouse-wheel in the timeline.
  • The New Android Project wizard now supports Eclipse working sets.

More information about tool changes are available on the Android Tools Project Site.

저작자 표시 비영리 동일 조건 변경 허락

'Android > APP&SDK' 카테고리의 다른 글

SDK Tools, r12 & ADT 12.0.0 & NDK r6  (0) 2011/07/12
ADT Plugin for Eclipse 11.0.0  (0) 2011/06/07
ADT 10.0.1  (0) 2011/03/17
SDK Tools r10 & ADT 10.0.0  (0) 2011/03/11
SDK Tools r9 & ADT 9.0.0 & NDK r5b  (0) 2011/01/27
SDK Tools, r8 & ADT 8.0.0 & NDK, r5 for Gingerbread  (0) 2010/12/07
Posted by mirwing
Android/APP&SDK2011/03/17 18:10

[Android Developer]
 

ADT Plugin for Eclipse


Dependencies:
ADT 10.0.1 is designed for use with SDK Tools r10. If you haven't already installed SDK Tools r10 into your SDK, use the Android SDK and AVD Manager to do so.
General notes:
  • Temporary work-around to resolve the rare cases in which the layout editor will not open.
  • Fix issue in which ADT 10.0.0 would install on Eclipse 3.4 and lower, even though ADT requires Eclipse 3.5 or higher (as of 10.0.0).
저작자 표시 비영리 동일 조건 변경 허락

'Android > APP&SDK' 카테고리의 다른 글

SDK Tools, r12 & ADT 12.0.0 & NDK r6  (0) 2011/07/12
ADT Plugin for Eclipse 11.0.0  (0) 2011/06/07
ADT 10.0.1  (0) 2011/03/17
SDK Tools r10 & ADT 10.0.0  (0) 2011/03/11
SDK Tools r9 & ADT 9.0.0 & NDK r5b  (0) 2011/01/27
SDK Tools, r8 & ADT 8.0.0 & NDK, r5 for Gingerbread  (0) 2010/12/07
Posted by mirwing
Android/APP&SDK2011/03/11 13:44

SDK Tools


Dependencies:
If you are developing in Eclipse with ADT, note that the SDK Tools r10 is designed for use with ADT 10.0.0 and later. After installing SDK Tools r10, we highly recommend updating your ADT Plugin to 10.0.0.
If you are developing outside Eclipse, you must have Apache Ant 1.8 or later.
General notes:
The tools now automatically generate Java Programming Language source files (in the gen directory) and bytecode (in the res/raw directory) from your native .rs files


ADT Plugin for Eclipse


Dependencies:
ADT 10.0.0 is designed for use with SDK Tools r10. If you haven't already installed SDK Tools r10 into your SDK, use the Android SDK and AVD Manager to do so.
General notes:
  • The tools now automatically generate Java Programming Language source files (in the gen/ directory) and bytecode (in the res/raw/ directory) from your .rs files.
  • A Binary XML editor has been added (details).
  • Traceview is now integrated into the Eclipse UI (details).
  • The "Go To Declaration" feature for XML and .java files quickly show all the matches in the project and allows you jump to specific items such as string translations or onClick handlers (details).
  • The Resource Chooser can create items such as dimensions, integers, ids, and booleans (details).
  • Improvements to the Visual Layout Editor:
    • A new Palette with categories and rendering previews (details).
    • A Layout Actions bar that provides quick access to common layout operations (details).
    • When the Android 3.0 rendering library is selected, layouts render more like they do on devices. This includes rendering of status and title bars to more accurately reflect the actual screen space available to applications (details).
    • Zoom improvements such as fit to view, persistent scale, and keyboard access. (details).
    • Further improvements to <merge> layouts, as well as layouts with gesture overlays (details).
    • Improved rendering error diagnostics.
저작자 표시 비영리 동일 조건 변경 허락

'Android > APP&SDK' 카테고리의 다른 글

ADT Plugin for Eclipse 11.0.0  (0) 2011/06/07
ADT 10.0.1  (0) 2011/03/17
SDK Tools r10 & ADT 10.0.0  (0) 2011/03/11
SDK Tools r9 & ADT 9.0.0 & NDK r5b  (0) 2011/01/27
SDK Tools, r8 & ADT 8.0.0 & NDK, r5 for Gingerbread  (0) 2010/12/07
SDK Tools r6 & ADT 0.9.7 & NDK r4 for Froyo  (1) 2010/05/27
Posted by mirwing
Android/APP&SDK2011/01/27 10:36

SDK Tools

Dependencies:

If you are developing in Eclipse with ADT, note that the SDK Tools r9 is designed for use with ADT 9.0.0 and later. After installing SDK Tools r9, we highly recommend updating your ADT Plugin to 9.0.0.

If you are developing outside Eclipse, you must have Apache Ant 1.8 or later.

Upgrading to SDK Tools r9:

If you are upgrading to SDK Tools r9 from SDK Tools r7 or earlier, the default installed location for the adb tool has changed from <SDK>/tools/adb to<SDK>/platform-tools/adb. This means that you should add the new location to your PATH and modify any custom build scripts to reference the new location. Copying the adb executable from the new location to the old is not recommended, since subsequent updates to the SDK Tools will delete the file.

General notes:
  • The default ProGuard configuration, proguard.cfg, now ignores the following classes:
  • Ant lib rules now allow you to override java.encodingjava.source, and java.target properties.
  • The default encoding for the javac Ant task is now UTF-8.
  • The LogCat view in DDMS now properly displays UTF-8 characters.
  • The SDK Manager is more reliable on Windows. For details on the improvements, see the Android Tools Project Site.
  • If you enabled snapshots for an AVD, they are automatically captured. The emulator also now restores to the state when it last closed almost instantly.
  • Fixed the missing JAR file error that prevented draw9patch from running.
  • Fixed the Windows launch scripts hierarchyviewer and ddms to support the new location of adb.
  • Known issues with emulator performance: Because the Android emulator must simulate the ARM instruction set architecture on your computer, emulator performance is slow. We're working hard to resolve the performance issues and it will improve in future releases.


ADT Plugin for Eclipse


Dependencies:
ADT 9.0.0 is designed for use with SDK Tools r9. If you haven't already installed SDK Tools r9 into your SDK, use the Android SDK and AVD Manager to do so.
General notes:
  • "Go To Declaration" hyperlink support: You can jump directly from code references (such as R.id.main) to the corresponding XML declaration, or from XML attributes (such as @string) to the corresponding resource definition, or from manifest XML registrations to activities and services.
  • Improvements were made to name refactoring.
  • AVDs now automatically save their state, so they can restart almost instantly. You can enable this feature when creating an AVD or by editing an AVD with the AVD Manager.
  • Improvements to the Visual Layout Editor:
    • Support for rendering targets: You can now choose an arbitrary Android platform to render the current page, regardless of the project's minimum platform. This makes it easy to verify the layout and appearance of your activity on different versions of the platform.
    • Improved support for empty and nested layouts: Dragging items over nested and invisible layouts automatically enlarges and highlights these layouts, so that they can receive drops.
    • XML formatting improvements: The editor generates cleaner XML and you can now enable XML auto-formatting in the Preferences menu.
    • Improved Outline labels: The Outline tab now displays additional information about each View. Textual Views display a snippet of the actual text. Views with a source (such as ImageView) displays the resource name. Included Views display the name of the View.
    • When you right click a View in the Layout Editor, the context menu now contains Edit ID... and Edit Text... items. The Properties... context menus now list all of the properties and provide a way to edit them (Details).
    • The layout editor now properly handles <include> and <merge> tags (Details).
    • "Extract as Include" refactoring: The Layout Editor has a new refactoring that allows you to select one or more views in a layout, and extract it into a separate layout (Details).
    • Improved diagnostics for class loading and rendering errors: Class loading and rendering error messages are more useful and provide better information about the root cause of the error.
    • Improved error handling to prevent drag and reordering operations from adding children into an AdapterView.
    • Outline reordering: Reordering your views in the Outline tab is much easier (Details).
    • Fix for keybinding bug where keyboard shortcuts did not work (Issues 13231 and 13134).
    • Fix for problems with Custom layout attribute menu (Issue 13134).
    • Automatic configuration for various view types: Certain views have properties configured by default. For example, the width of an EditText object is set to match_parent when added to a vertical LinearLayout or a default image is added to an ImageButton.
    • Previews during dragging: Dragging from the palette or dragging within the layout editor now shows live previews of the dragged item.
    • Navigation improvements: In the Layout Editor, double-clicking Views jumps to the corresponding XML element. In the Outline view, double-clicking opens the Properties view.
    • The editor has Honeycomb style animation preview support.
    • Improved rendering support for various Views (such as TabHosts and SlidingDrawers) in Honeycomb (Issues 3162 and 13092).
    • Included layouts can be rendered and edited in the context of the layouts that include them. From a layout using an <include> tag, double-clicking on the <include> element edits the referenced layout in the context of the current layout. Additionally, when editing a layout that is included by other layouts, you can quickly change between context layouts, by right clicking in the editor and choosing Show included in.... This feature is only available in Honeycomb.
  • This release fixes many other bugs, but the most important ones are listed below:
    • Fixed issue that prevented launching debug builds on productions devices when debuggable=true was not set in the Android manifest.
    • The LogCat view in DDMS properly handles UTF-8 characters.
    • The SDK Manager is more reliable on Windows (Details).
    • A JUnit initialization bug that prevented you from working with JUnit tests was fixed (Issue 12411).


Android NDK


This release of the NDK does not include any new features compared to r5. The r5b release addresses the following problems in the r5 release:

  • The r5 binaries required glibc 2.11, but the r5b binaries are generated with a special toolchain that targets glibc 2.7 or higher instead. The Linux toolchain binaries now run on Ubuntu 8.04 or higher.
  • Fixes a compiler bug in the arm-linux-androideabi-4.4.3 toolchain. The previous binary generated invalid thumb instruction sequences when dealing with signed chars.
  • Adds missing documentation for the "gnustl_static" value for APP_STL, that allows you to link against a static library version of GNU libstdc++.
  • The following ndk-build issues are fixed:
    • A bug that created inconsistent dependency files when a compilation error occured on Windows. This prevented a proper build after the error was fixed in the source code.
    • A Cygwin-specific bug where using very short paths for the Android NDK installation or the project path led to the generation of invalid dependency files. This made incremental builds impossible.
    • A typo that prevented the cpufeatures library from working correctly with the new NDK toolchain.
    • Builds in Cygwin are faster by avoiding calls to cygpath -m from GNU Make for every source or object file, which caused problems with very large source trees. In case this doesn't work properly, define NDK_USE_CYGPATH=1 in your environment to use cygpath -m again.
    • The Cygwin installation now notifies the user of invalid installation paths that contain spaces. Previously, an invalid path would output an error that complained about an incorrect version of GNU Make, even if the right one was installed.
  • Fixed a typo that prevented the NDK_MODULE_PATH environment variable from working properly when it contained multiple directories separated with a colon.
  • The prebuilt-common.sh script contains fixes to check the compiler for 64-bit generated machine code, instead of relying on the host tag, which allows the 32-bit toolchain to rebuild properly on Snow Leopard. The toolchain rebuild scripts now also support using a 32-bit host toolchain.
  • A missing declaration for INET_ADDRSTRLEN was added to <netinet/in.h>.
  • Missing declarations for IN6_IS_ADDR_MC_NODELOCAL and IN6_IS_ADDR_MC_GLOBAL were added to <netinet/in6.h>.
  • 'asm' was replaced with '__asm__' in <asm/byteorder.h> to allow compilation with -std=c99.

저작자 표시 비영리 동일 조건 변경 허락
Posted by mirwing
Android/APP&SDK2010/12/07 11:12
SDK Tools, Revision 8

Dependencies:
If you are developing in Eclipse with ADT, note that SDK Tools r8 is designed for use with ADT 8.0.0 and later. After installing SDK Tools r8, we highly recommend updating your ADT Plugin to 8.0.0.
Also note that SDK Tools r8 requires a new SDK component called Platform-tools. The new Platform-tools component lets all SDK platforms (Android 2.1, Android 2.2, and so on) use the same (latest) version of build tools such as adb, aapt, aidl, and dx. To download the Platform- tools component, use the Android SDK Manager, as described in Adding SDK Components
Upgrading from SDK Tools r7:
If you are upgrading to SDK Tools r8 from an earlier version, note that the the default installed location for the adb tool has changed from <SDK>/tools/adb to <SDK>/platform-tools/adb. This means that you should add the new location to your PATH and modify any custom build scripts to reference the new location. Copying the adb executable from the new location to the old is not recommended, since subsequent updates to the SDK Tools will delete the file.
General notes:
  • All SDK platforms now support Library Projects.
  • Support for a true debug build. Developers no longer need to add the android:debuggable attribute to the <application> tag in the manifest — the build tools add the attribute automatically. In Eclipse/ADT, all incremental builds are assumed to be debug builds, so the tools insert android:debuggable="true". When exporting a signed release build, the tools do not add the attribute. In Ant, a ant debug command automatically inserts the android:debuggable="true" attribute, while ant release does not. If android:debuggable="true" is manually set, then ant release will actually do a debug build, rather than a release build.
  • Automatic ProGuard support in release builds. Developers generate a ProGuard configuration file using the android tool — the build tools then automatically run ProGuard against the project sources during the build. For more information, see the ProGuard documentation.
  • New overridable Ant javac properties: java.encoding, java.source, and java.target (default values are "ascii", "1.5", and "1.5", respectively).
  • New UI for the HierarchyViewer tool.

ADT Plugin for Eclipse 8.0.0

Dependencies:
ADT 8.0.0 is designed for use with SDK Tools r8. If you haven't already installed SDK Tools r8 into your SDK, use the Android SDK and AVD Manager to do so.

General notes:
  • New version number scheme that follows the SDK Tools revision number. The major version number for your ADT plugin should now always match the revision number of your SDK Tools. For example, ADT 8.x is for SDK Tools r8.
  • Support for true debug build. You no longer need to change the value of the debuggable attribute in the Android Manifest.
Incremental builds automatically insert debuggable="true", but if you perform "export signed/unsigned application package", ADT does not insert it. If you manually set debuggable="true" in the manifest file, then release builds will actually create a debug build (it does not remove it if you placed it there).
  • Automatic ProGuard support in release builds. For it to work, you need to have a proguard.config property in the default.properties file that points to a ProGuard config file.
  • Completely rewritten Visual Layout Editor. (This is still a work in progress.) Now includes:
Full drag and drop from palette to layout for all Layout classes.
Move widgets inside a Layout view, from one Layout view to another and from one layout file to another.
Contextual menu with enum/flag type properties.
New zoom controls.
  • New HierarchyViewer plug-in integrated in Eclipse.
  • Android launch configurations don't recompile the whole workspace on launch anymore.
  • android.jar source and javadoc location can now be configured.

Android NDK, Revision 5

This release of the NDK includes many new APIs, most of which are introduced to support the development of games and similar applications that make extensive use of native code. Using the APIs, developers have direct native access to events, audio, graphics and window management, assets, and storage. Developers can also implement the Android application lifecycle in native code with help from the new NativeActivity class. For detailed information describing the changes in this release, read the CHANGES.HTML document included in the downloaded NDK package.

General notes:

  • Adds support for native activities, which allows you to implement the Android application lifecycle in native code.
  • Adds native support for the following:
Input subsystem (such as the keyboard and touch screen)
Access to sensor data (accelerometer, compass, gyroscope, etc).
Event loop APIs to wait for things such as input and sensor events.
Window and surface subsystem
Audio APIs based on the OpenSL ES standard that support playback and recording as well as control over platform audio effects
Access to assets packaged in an .apk file.
  • Includes a new toolchain (based on GCC 4.4.3), which generates better code, and can also now be used as a standalone cross-compiler, for people who want to build their stuff with ./configure && make. See docs/STANDALONE-TOOLCHAIN.html for the details. The binaries for GCC 4.4.0 are still provided, but the 4.2.1 binaries were removed.
  • Adds support for prebuilt static and shared libraries (docs/PREBUILTS.html) and module exports and imports to make sharing and reuse of third-party modules much easier (docs/IMPORT-MODULE.html explains why).
  • Provides a default C++ STL implementation (based on STLport) as a helper module. It can be used either as a static or shared library (details and usage examples are in sources/android/stlport/README). Prebuilt binaries for STLport (static or shared) and GNU libstdc++ (static only) are also provided if you choose to compile against those libraries instead of the default C++ STL implementation. C++ Exceptions and RTTI are not supported in the default STL implementation. For more information, see docs/CPLUSPLUS-SUPPORT.HTML.
  • Includes improvements to the cpufeatures helper library that improves reporting of the CPU type (some devices previously reported ARMv7 CPU when the device really was an ARMv6). We recommend developers that use this library to rebuild their applications then upload to Market to benefit from the improvements.
  • Adds an EGL library that lets you create and manage OpenGL ES textures and services.
  • Adds new sample applications, native-plasma and native-activity, to demonstrate how to write a native activity.
  • Includes many bugfixes and other small improvements; see docs/CHANGES.html for a more detailed list of changes.
Posted by mirwing
Android/APP&SDK2010/05/27 10:23

SDK Tools, r6

Dependencies:

If you are developing in Eclipse with ADT, note that SDK Tools r6 is designed for use with ADT 0.9.7 and later. After installing SDK Tools r6, we highly recommend updating your ADT Plugin to 0.9.7.

Library projects:

The SDK Tools now support the use of library projects during development, a capability that lets you store shared Android application code and resources in a separate development project. You can then reference the library project from other Android projects and, at build time, the tools compile the shared code and resources as part of the dependent applications. More information about this feature is available in the Developing in Other IDEs document.

If you are developing in Eclipse, ADT 0.9.7 provides the equivalent library project support.



ADT Plugin for Eclipse 0.9.7

Library projects:

The ADT Plugin now supports the use of library projects during development, a capability that lets you store shared Android application code and resources in a separate development project. You can then reference the library project from other Android projects and, at build time, the tools compile the shared code and resources as part of the dependent applications. More information about this feature is available in the Developing in Eclipse with ADT document.

If you are not developing in Eclipse, SDK Tools r6 provides the equivalent library project support through the Ant build system.



Android NDK, r4

General notes:
  • Provides a simplified build system through the new ndk-build build command.
  • Adds support for easy native debugging of generated machine code on production devices through the new ndk-gdb command.
  • Adds a new Android-specific ABI for ARM-based CPU architectures, armeabi-v7a. The new ABI extends the existing armeabi ABI to include these CPU instruction set extensions:
    • Thumb-2 instructions
    • VFP hardware FPU instructions (VFPv3-D16)
    • Optional support for ARM Advanced SIMD (NEON) GCC intrinsics and VFPv3-D32. Supported by devices such as Verizon Droid by Motorola, Google Nexus One, and others.
  • Adds a new cpufeatures static library (with sources) that lets your app detect the host device's CPU features at runtime. Specifically, applications can check for ARMv7-A support, as well as VFPv3-D32 and NEON support, then provide separate code paths as needed.
  • Adds a sample application, hello-neon, that illustrates how to use the cpufeatures library to check CPU features and then provide an optimized code path using NEON instrinsics, if supported by the CPU.
  • Lets you generate machine code for either or both of the instruction sets supported by the NDK. For example, you can build for both ARMv5 and ARMv7-A architectures at the same time and have everything stored to your application's final .apk.
  • To ensure that your applications are available to users only if their devices are capable of running them, Android Market now filters applications based on the instruction set information included in your application — no action is needed on your part to enable the filtering. Additionally, the Android system itself also checks your application at install time and allows the installation to continue only if the application provides a library that is compiled for the device's CPU architecture.
  • Adds support for Android 2.2, including a new stable API for accessing the pixel buffers of Bitmap objects from native code.

Posted by mirwing
Android/APP&SDK2010/03/09 07:13

[Android Developer]


Android NDK r3

The third release of the Android Native Development Kit (NDK) is now available for download from the Android developer site.

It can be used to target devices running Android 1.5 and higher. In addition to a few bug fixes and improvements, this release includes the following new features:

Toolchain improvement

The toolchain binaries have been refreshed for this release with GCC 4.4.0, which should generate slightly more compact and efficient machine code than the previous one (4.2.1).

Note that the GCC 4.4.0 C++ frontend is more pedantic, and may refuse to compile certain rare and invalid template declarations that were accepted by 4.2.1. To alleviate the problem, this NDK still provides the 4.2.1 binaries, which can optionally be used to build your machine code.

OpenGL ES 2.0 support

Applications targeting Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.

A new trivial sample, named "hello-gl2", demonstrates how to render a simple triangle using both shader types.

Name simplification

This NDK release is just called "r3", for "Revision 3", to indicate that it is not limited to a specific Android platform/API level. Some developers thought that the previous release's name (1.6_r1) was confusing and indicated that it could only be used to target Android 1.6, which was not true.

Enjoy!


SDK Tools r5

Dependencies:
  • If you are developing in Eclipse with ADT, note that SDK Tools r5 is designed for use with ADT 0.9.6 and later. After installing SDK Tools r5, we highly recommend updating your ADT Plugin to 0.9.6.
  • For Mac OS platforms, OS X 10.4.x (Tiger) is no longer officially supported.

SDK and AVD Manager:
  • Fixes SSL download for the standalone version of the SDK Updater.
  • Fixes issue with 64-bit JVM on Windows.
  • Adds support for platform samples components.
  • Improves support for dependency between components.
  • AVDs now sorted by API level.
  • The AVD creation dialog now enforces a minimum SD card size of 9MB.
  • Prevents deletion of running AVDs.
  • Settings are now automatically saved, no need to click "Apply".

Emulator:
  • Emulator now requires SD card to be 9MB or more.

Layoutopt:
  • Fixes layoutopt.bat to execute correctly on Windows.


ADT 0.9.6

Dependencies:
  • ADT 0.9.6 is designed for use with SDK Tools r5 and later. Before updating to ADT 0.9.6, we highly recommend that you use the Android SDK and AVD Manager to install SDK Tools r5 into your SDK.

General Notes:
  • Editing default.properties outside of Eclipse will now automatically update the project.
  • Loads the SDK content only when a project requires it. This will make Eclipse use less resources when the SDK contains many versions of Android.
  • Resolves potential deadlock between modal dialogs, when launching ADT the first time with the SDK Usage panel.
  • Fixes issues with the New Project Wizard when selecting samples.

AVD/SDK Manager:
  • Adds support for platform samples components.
  • Improves support for dependency between components.
  • AVDs now sorted by API level.
  • The AVD creation dialog now enforces a minimum SD card size of 9MB.
  • Prevents deletion of running AVDs.

DDMS:
  • DDMS plug-in now contains the Allocation Tracker view.
  • New action in the Logcat view: "Go to problem" lets you go directly from an exception trace output to the code.

Editors:
  • Explode mode in the Visual Layout Editor adds a margin to all layout objects so that it's easier to see embedded or empty layouts.
  • Outline mode in the Visual Layout Editor draws layout outline to make it easier to see layout objects.
  • Several fixes in the configuration selector of the Visual Layout Editor.

Application launching:
  • Applications launched from ADT now behave as if they were clicked from the Home screen.
  • Fixes issue where add-on with no optional library would not show up as valid targets for application launches.
  • Resolves possible crash when launching applications.


Posted by mirwing
Android/APP&SDK2010/02/21 15:16

Android의 개발 환경을 설정하기 전에 Android에서 지원하는 개발 환경에 대해서 알아 보겠습니다.


Android를 개발할 수 있는 OS는 3가지가 있습니다.

Linux, Mac, Windows


이 중 Windows는 Android의 Source 레벨 까지 내려가기 위해서는 많은 작업을 해야 합니다.



Linux와 비슷하게 만들어 주는 cygwin이 존재하지만 저는 linux가 더 좋습니다.ㅋ


Linux와 Mac은 Android Source까지 다운로드를 할 수 있지만 역시 Linux의 경우가 좀더 호환이 잘 됩니다.


Android는 SDK와 NDK를 이용해 개발 할 수 있는데 NDK는 2010. 2월 21일 현재 아직 1.6r1버전 뿐입니다.



총 3가지의 환경설정을 포스팅 하겠는데 목록을 살펴보겠습니다.


1. Android SDK 설치
우선 가장 기본적은 SDK는 Java로 구성된 Android App을 개발할 수 있도록 해줍니다.


2. Android NDK 설치
JNI를 손 쉽게 해주는 NDK는 C/C++로 라이브러리를 만들어 Java에서 사용을 할 수 있도록 해주지만 1.6버전 뿐입니다.


3. Android Source 다운로드 & 컴파일
마지막으로 Android Source를 다운로드 받아 해당 소스를 컴파일하여 직접 system 이미지를 만들거나 Source에 포함되어 있는 컴파일러를 이용하여 라이브러리를 만들 수 있습니다.



위 3가지에 대한 각각의 내용은 링크로 연결 시키겠습니다. 

Posted by mirwing
Android/APP&SDK2010/02/17 23:05

Service API changes starting with Android 2.0

Watching developers use the Android platform the last year has shown a number of trouble areas in the Service API as well as growing issues in the ways services operate. As a result, Android 2.0 introduced a number of changes and improvements in this area for both developers and users.

The three main changes to be aware of are:
  • Service.setForeground() is now deprecated and in 2.0 does nothing.
  • There were many edge cases in the service lifecycle that made it very easy to accidentally leave a service running; new APIs in 2.0 make this much easier to deal with.
  • Android 2.0 also introduces a new UI for end users to monitor and manage the running services on their device.


Background on services

Before going into the details of 2.0, it may be useful to go over a quick summary of services. The Service API in Android is one of the key mechanisms for applications to do work in the background. Due to the way Android is designed, once an application is no longer visible to the user it is generally considered expendable and a candidate to be killed by the system if it ever needs memory elsewhere. The main way applications get around this is by starting a Service component, which explicitly tells the system that they are doing some valuable work and would prefer that the system not kill their process if it doesn't truly need to.

This is a very powerful facility but along with that power comes some responsibility: an actively running service is taking resources away from other things that can run (including inactive processes in the background that don't need to be initialized the next time the user visits them). It is thus important that developers take care when designing their services that they only run when truly needed and avoid any bugs where they may accidentally leave the service running for long durations.


Redesigning Service.setForeground()

During the final stabilization period of Android 1.6 we started to see more issues due to an increasing number of applications using the Service.setForeground() API when they shouldn't be. This is an API that we haven't advertised much because it should not be used by most applications and can be very hard on the system: it asks that the service's process be treated as in the foreground, essentially making it unkillable and thus more difficult for the system to recover from low memory situations.

At that point in 1.6 it was too late to make any significant changes to the behavior here, but in 2.0 we have done so: Service.setForeground() now does nothing. The API was always intended to be something a service would do in conjunction with putting up an ongoing notification for the user; by saying you are in the foreground, the user should be "aware" that the service is running in some way and know how to stop it. Thus in place of the old API Andriod 2.0 introduces two new APIs that require a notification go along with being in the foreground:

    public final void startForeground(int id, Notification notification);
    public final void stopForeground(boolean removeNotification);


This also not coincidentally makes it much easier to manage the notification state along with the service, since the system can now guarantee that there is always a notification while the service is in the foreground, and that the notification goes away whenever the service does.

Many developers will want to write a service that works on older platforms as well as 2.0 and later; this can be accomplished by using something like the following code to selectively call the new APIs when they are available.

    private static final Class[] mStartForegroundSignature = new Class[] {
        int.class, Notification.class};
    private static final Class[] mStopForegroundSignature = new Class[] {
        boolean.class};

    private NotificationManager mNM;
    private Method mStartForeground;
    private Method mStopForeground;
    private Object[] mStartForegroundArgs = new Object[2];
    private Object[] mStopForegroundArgs = new Object[1];

    @Override
    public void onCreate() {
        mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
        try {
            mStartForeground = getClass().getMethod("startForeground",
                    mStartForegroundSignature);
            mStopForeground = getClass().getMethod("stopForeground",
                    mStopForegroundSignature);
        } catch (NoSuchMethodException e) {
            // Running on an older platform.
            mStartForeground = mStopForeground = null;
        }
    }


    /**
     * This is a wrapper around the new startForeground method, using the older
     * APIs if it is not available.
     */
    
void startForegroundCompat(int id, Notification notification) {
        // If we have the new startForeground API, then use it.
        if (mStartForeground != null) {
            mStartForegroundArgs[0] = Integer.valueOf(id);
            mStartForegroundArgs[1] = notification;
            try {
                mStartForeground.invoke(this, mStartForegroundArgs);
            } catch (InvocationTargetException e) {
                // Should not happen.
                Log.w("MyApp", "Unable to invoke startForeground", e);
            } catch (IllegalAccessException e) {
                // Should not happen.
                Log.w("MyApp", "Unable to invoke startForeground", e);
            }
            return;
        }

        // Fall back on the old API.
        setForeground(true);
        mNM.notify(id, notification);
    }


    /**
     * This is a wrapper around the new stopForeground method, using the older
     * APIs if it is not available.
     */
    
void stopForegroundCompat(int id) {
        // If we have the new stopForeground API, then use it.
        if (mStopForeground != null) {
            mStopForegroundArgs[0] = Boolean.TRUE;
            try {
                mStopForeground.invoke(this, mStopForegroundArgs);
            } catch (InvocationTargetException e) {
                // Should not happen.
                Log.w("MyApp", "Unable to invoke stopForeground", e);
            } catch (IllegalAccessException e) {
                // Should not happen.
                Log.w("MyApp", "Unable to invoke stopForeground", e);
            }
            return;
        }

        // Fall back on the old API.  Note to cancel BEFORE changing the
        // foreground state, since we could be killed at that point.
        mNM.cancel(id);
        setForeground(false);
    }


Service lifecycle changes

Another situation we were increasingly seeing in 1.6 was that, even ignoring the services that inappropriately make themselves foreground, we had a growing number of devices with a large number of services running in the background all fighting each other over the available memory.

Part of this problem is services that are running more than they should or there simply being too much stuff trying to be done on the device. However, we also found many issues in the interaction between services and the platform that made it easy for an application to leave a service running even when it is trying to do the right thing. Consider this typical scenario:

  1. An application calls startService().
  2. That service gets onCreate(), onStart(), and then spawns a background thread to do some work.
  3. The system is tight on memory, so has to kill the currently running service.
  4. Later when memory is free, the service is restarted, and gets onCreate() called but not onStart() because there has not been another call to startService() with a new Intent command to send it.
Now the service will sit there created, not realizing it used to be doing some work, and so not knowing it should stop itself at some point.

To address this, in Android 2.0 Service.onStart() as been deprecated (though still exists and operates as it used to in previous versions of the platform). It is replaced with a new
Service.onStartCommand() callback that allows the service to better control how the system should manage it. The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:

  • START_STICKY is basically the same as the previous behavior, where the service is left "started" and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.
  • START_NOT_STICKY says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.
  • START_REDELIVER_INTENT is like START_NOT_STICKY, except if the service's process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can't complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.
For compatibility with existing applications, the default return code for applications that are targeting an earlier version of the platform is a special START_STICKY_COMPATIBILITY code that provides the old behavior of not calling onStart() with a null intent. Once you start targeting API version 5 or later, the default mode is START_STICKY and you must be prepared to deal with onStart() or onStartCommand() being called with a null Intent.

You can also easily write a Service that uses both the old and new APIs, depending on the platform. All you need to do is compile against the 2.0 SDK with this code:

    // This is the old onStart method that will be called on the pre-2.0
    // platform.  On 2.0 or later we override onStartCommand() so this
    // method will not be called.
    @Override
    public void onStart(Intent intent, int startId) {
        handleStart(intent, startId);
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        handleStart(intent, startId);
        return START_NOT_STICKY;
    }

    void handleStart(Intent intent, int startId) {
        // do work
    }


New "running services" user interface

Our final issue to address is the case where there are simply too many service running in the amount of memory available on a device. This may be due to bugs or design flaws in installed applications, or the user simply trying to do too much. Historically users have had no visibility into what is going on at this level in the system, but it has become important to expose this, at least for lower-end devices, as the use of services has had an increasing impact on the user experience.

To help address this, Android 2.0 introduces a new "Running Services" activity available from the Application system settings. When brought up, it looks something like this:
Running Services

The main content is a list of all running services that may be of interest to the user, organized by the processes they run in. In the example here, we see three services:

  • GTalkService is part of the standard Google application suit; it is running in Google's "gapps" process, which currently consumes 6.8MB. It has been started for 3 hours 55 minutes, which on this device is the time from when it was first booted.
  • ActivityService is part of the Phonebook app, and its process consumes 4MB. This also has been running since boot.
  • SoftKeyboard is a third party input method. It has been running since I switched to it, about 4 minutes ago.
The user can tap on any of these services to control it; for normal services that are running because they were explicitly started, this will present a dialog allowing the user to explicitly stop it:
Stop Service
Some other services, like the input method, are running for other reasons. For these, tapping on the service will go to the corresponding UI to manage it (in this case the system's input settings).

Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:

  • Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
  • Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)
For most users, this new user interface should be a much more effective way to manage the background applications on their device than the existing "task killer" applications. In the vast majority of cases the reason for a slow running device is too many services trying to run. This prevents the system from being able to run any background processes (which speed up app switching), and ultimately can result in thrashing through the services when not even they can all be kept running. The Running Services UI is intended to provide very specific information about the services that are running, to help make a good decision about what should be stopped. It also does not use the API to force stop an application, which can unintentionally break applications in numerous ways.

For developers, this is an important tool to ensure your services are well behaved. As you develop your app, be sure to keep an eye on Running Services to ensure that you are not accidentally leaving your services running when they shouldn't be. You should also now keep in mind that users may freely stop any of your services as they wish, without your control, and account for that.

Android's Services are a very powerful tool, but one of the main and subtle ways that application developers can harm the overall experience a user has with their phone.

Posted by mirwing