leaderboard 1

Showing posts with label features. Show all posts
Showing posts with label features. Show all posts

Tuesday 29 September 2015

Android KitKat

Android KitKat

Welcome to Android 4.4 KitKat!
Android KitKat brings all of Android's most innovative, most beautiful, and most useful features to more devices everywhere.
This document provides a glimpse of what's new for developers.Android 4.4 on phone and tablet
Find out more about KitKat for consumers atwww.android.com.

Making Android for everyone

Android 4.4 is designed to run fast, smooth, and responsively on a much broader range of devices than ever before — including on millions of entry-level devices around the world that have as little as512MB RAM.
KitKat streamlines every major component to reduce memory use and introduces new APIs and tools to help you create innovative, responsive, memory-efficient applications.
OEMs building the next generation of Android devices can take advantage oftargeted recommendations and options to run Android 4.4 efficiently, even on low-memory devices. Dalvik JIT code cache tuning, kernel samepage merging (KSM), swap to zRAM, and other optimizations help manage memory. New configuration options let OEMs tune out-of-memory levels for processes, set graphics cache sizes, control memory reclaim, and more.
In Android itself, changes across the system improve memory management and reduce memory footprint. Core system processes are trimmed to use less heap, and they now more aggressively protect system memory from apps consuming large amounts of RAM. When multiple services start at once — such as when network connectivity changes — Android now launches the services serially, in small groups, to avoid peak memory demands.
For developers, Android 4.4 helps you deliver apps that are efficient and responsive on all devices. A new API, ActivityManager.isLowRamDevice(), lets you tune your app's behavior to match the device's memory configuration. You can modify or disable large-memory features as needed, depending on the use-cases you want to support on entry-level devices. Learn more about optimizing your apps for low-memory devices here.
New tools also give you powerful insight into your app's memory use. Theprocstats tool details memory use over time, with run times and memory footprint for foreground apps and background services. An on-device view is also available as a new developer option. The meminfo tool is enhanced to make it easier to spot memory trends and issues, and it reveals additional memory overhead that hasn't previously been visible.

New NFC capabilities through Host Card Emulation

Android 4.4 introduces new platform support for secure NFC-based transactions through Host Card Emulation (HCE), for payments, loyalty programs, card access, transit passes, and other custom services. With HCE, any app on an Android device can emulate an NFC smart card, letting users tap to initiate transactions with an app of their choice — no provisioned secure element (SE) in the device is needed. Apps can also use a new Reader Mode to act as readers for HCE cards and other NFC-based transactions.
Android HCE emulates ISO/IEC 7816 based smart cards that use the contactless ISO/IEC 14443-4 (ISO-DEP) protocol for transmission. These cards are used by many systems today, including the existing EMVCO NFC payment infrastructure. Android uses Application Identifiers (AIDs) as defined in ISO/IEC 7816-4 as the basis for routing transactions to the correct Android applications.
Apps declare the AIDs they support in their manifest files, along with a category identifier that indicates the type of support available (for example, "payments"). In cases where multiple apps support the same AID in the same category, Android displays a dialog that lets the user choose which app to use.
When the user taps to pay at a point-of-sale terminal, the system extracts the preferred AID and routes the transaction to the correct application. The app reads the transaction data and can use any local or network-based services to verify and then complete the transaction.
Android HCE requires an NFC controller to be present in the device. Support for HCE is already widely available on most NFC controllers, which offer dynamic support for both HCE and SE transactions. Android 4.4 devices that support NFC will include Tap & Pay for easy payments using HCE.

Printing framework

Android apps can now print any type of content over Wi-Fi or cloud-hosted services such as Google Cloud Print. In print-enabled apps, users can discover available printers, change paper sizes, choose specific pages to print, and print almost any kind of document, image, or file.
Android 4.4 introduces native platform support for printing, along with APIs for managing printing and adding new types of printer support. The platform provides a print manager that mediates between apps requesting printing and installed print services that handle print requests. The print manager provides shared services and a system UI for printing, giving users consistent control over printing from any app. The print manager also ensures the security of content as it's passed across processes, from an app to a print service.
You can add printing support to your apps or develop print services to support specific types of printers.
Printer manufacturers can use new APIs to develop their own print services — pluggable components that add vendor-specific logic and services for communicating with specific types of printers. They can build print services and distribute them through Google Play, making it easy for users to find and install them on their devices. Just as with other apps, you can update print services over-the-air at any time.
Client apps can use new APIs to add printing capabilities to their apps with minimal code changes. In most cases, you would add a print action to your Action Bar and a UI for choosing items to print. You would also implement APIs to create print jobs, query the print manager for status, and cancel jobs. This lets you print nearly any type of content, from local images and documents to network data or a view rendered to a canvas.
For broadest compatibility, Android uses PDF as its primary file format for printing. Before printing, your app needs to generate a properly paginated PDF version of your content. For convenience, the printing API provides native and WebView helper classes to let you create PDFs using standard Android drawing APIs. If your app knows how to draw the content, it can quickly create a PDF for printing.
Most devices running Android 4.4 will include Google Cloud Print pre-installed as a print service, as well as several Google apps that support printing, including Chrome, Drive, Gallery, and QuickOffice.

Storage access framework

A new storage access framework makes it simple for users to browse and open documents, images, and other files across all of their their preferred document storage providers. A standard, easy-to-use UI lets users browse files and access recents in a consistent way across apps and providers.
 
Box and others have integrated their services into the storage access framework, giving users easy access to their documents from apps across the system.
Cloud or local storage services can participate in this ecosystem by implementing a new document provider class that encapsulates their services. The provider class includes all of the APIs needed to register the provider with the system and manage browsing, reading, and writing documents in the provider. The document provider can give users access to any remote or local data that can be represented as files — from text, photos, and wallpapers to video, audio, and more.
If you build a document provider for a cloud or local service, you can deliver it to users as part of your existing Android app. After downloading and installing the app, users will have instant access to your service from any app that participates in the framework. This can help you gain exposure and user engagement, since users will find your services more easily.
If you develop a client app that manages files or documents, you can integrate with the storage access framework just by using new CREATE_DOCUMENT or OPEN_DOCUMENT intents to open or create files — the system automatically displays the standard UI for browsing documents, including all available document providers.
You can integrate your client app one time, for all providers, without any vendor-specific code. As users add or remove providers, they’ll continue to have access to their preferred services from your app, without changes or updates needed in your code.
The storage access framework is integrated with the existing GET_CONTENT intent, so users also have access to all of their previous content and data sources from the new system UI for browsing. Apps can continue using GET_CONTENT as a way to let users import data. The storage access framework and system UI for browsing make it easier for users to find and import their data from a wider range of sources.
Most devices running Android 4.4 will include Google Drive and local storage pre-integrated as document providers, and Google apps that work with files also use the new framework.

Low-power sensors

Sensor batching

Android 4.4 introduces platform support for hardware sensor batching, a new optimization that can dramatically reduce power consumed by ongoing sensor activities.
With sensor batching, Android works with the device hardware to collect and deliver sensor events efficiently in batches, rather than individually as they are detected. This lets the device's application processor remain in a low-power idle state until batches are delivered. You can request batched events from any sensor using a standard event listener, and you can control the interval at which you receive batches. You can also request immediate delivery of events between batch cycles.
Sensor batching is ideal for low-power, long-running use-cases such as fitness, location tracking, monitoring, and more. It can makes your app more efficient and it lets you track sensor events continuously — even while the screen is off and the system is asleep.
Sensor batching is currently available on Nexus 5, and we're working with our chipset partners to bring it to more devices as soon as possible.
 
Moves and Runtastic Pedometer are using the hardware step-detector to offer long-running, low-power services.

Step Detector and Step Counter

Android 4.4 also adds platform support for two new composite sensors — step detector and step counter — that let your app track steps when the user is walking, running, or climbing stairs. These new sensors are implemented in hardware for low power consumption.
The step detector analyzes accelerometer input to recognize when the user has taken a step, then triggers an event with each step. The step counter tracks the total number of steps since the last device reboot and triggers an event with each change in the step count. Because the logic and sensor management is built into the platform and underlying hardware, you don't need to maintain your own detection algorithms in your app.
Step detector and counter sensors are available on Nexus 5, and we're working with our chipset partners to bring them to new devices as soon as possible.

SMS provider

If you develop a messaging app that uses SMS or MMS, you can now use a shared SMS provider and new APIs to manage your app's message storage and retrieval. The new SMS provider and APIs define a standardized interaction model for all apps that handle SMS or MMS messages.
Along with the new provider and APIs, Android 4.4 introduces new semantics for receiving messages and writing to the provider. When a message is received, the system routes it directly to the user's default messaging app using the newSMS_DELIVER intent. Other apps can still listen for incoming messages using the SMS_RECEIVED intent. Also, the system now allows only the default app to write message data to the provider, although other apps can read at any time. Apps that are not the user's default can still send messages — the system handles writing those messages to the provider on behalf of the app, so that users can see them in the default app.
The new provider and semantics help to improve the user's experience when multiple messaging apps are installed, and they help you to build new messaging features with fully-supported, forward-compatible APIs.

New ways to build beautiful apps

A new immersive mode lets apps use every pixel on the screen to show content and capture touch events.

Full-screen Immersive mode

Now your apps can use every pixel on the device screen to showcase your content and capture touch events. Android 4.4 adds a new full-screen immersive mode that lets you create full-bleed UIs reaching from edge to edge on phones and tablets, hiding all system UI such as the status bar and navigation bar. It's ideal for rich visual content such as photos, videos, maps, books, and games.
In the new mode, the system UI stays hidden, even while users are interacting with your app or game — you can capture touch events from anywhere across the screen, even areas that would otherwise be occupied by the system bars. This gives you a great way to create a larger, richer, more immersive UI in your app or game and also reduce visual distraction.
To make sure that users always have easy, consistent access to system UI from full-screen immersive mode, Android 4.4 supports a new gesture — in immersive mode, an edge swipe from the top or bottom of the screen now reveals the system UI.
To return to immersive mode, users can touch the screen outside of the bar bounds or wait for a short period for the bars to auto-hide. For a consistent user experience, the new gesture also works with previous methods of hiding the status bar.

Transitions framework for animating scenes

Most apps structure their flows around several key UI states that expose different actions. Many apps also use animation to help users understand their progress through those states and the actions available in each. To make it easier to createhigh-quality animations in your app, Android 4.4 introduces a new transitions framework.
The transitions framework lets you define scenes, typically view hierarchies, and transitions, which describe how to animate or transform the scenes when the user enters or exits them. You can use several predefined transition types to animate your scenes based on specific properties, such as layout bounds, or visibility. There's also an auto-transition type that automatically fades, moves, and resizes views during a scene change. In addition, you can define custom transitions that animate the properties that matter most to your app, and you can plug in your own animation styles if needed.
With the transitions framework you can also animate changes to your UI on the fly, without needing to define scenes. For example, you can make a series of changes to a view hierarchy and then have the TransitionManager automatically run a delayed transition on those changes.
Once you've set up transitions, it's straightforward to invoke them from your app. For example, you can call a single method to begin a transition, make various changes in your view hierarchy, and on the next frame animations will automatically begin that animate the changes you specified.
translucent system UI
Apps can use new window styles to request translucent system bars.
For custom control over the transitions that run between specific scenes in your application flow, you can use the TransitionManager. The TransitionManager lets you define the relationship between scenes and the transitions that run for specific scene changes.

Translucent system UI styling

To get the most impact out of your content, you can now use new window styles and themes to request translucent system UI, including both the status bar and navigation bar. To ensure the legibility of navigation bar buttons or status bar information, subtle gradients is shown behind the system bars. A typical use-case would be an app that needs to show through to a wallpaper.

Enhanced notification access

Notification listener services can now see more information about incoming notifications that were constructed using the notification builder APIs. Listener services can access a notification's actions as well as new extras fields — text, icon, picture, progress, chronometer, and many others — to extract cleaner information about the notification and present the information in a different way.

Chromium WebView

Android 4.4 includes a completely new implementation of WebView that's based onChromium. The new Chromium WebView gives you the latest in standards support, performance, and compatibility to build and display your web-based content.
Chromium WebView provides broad support for HTML5, CSS3, and JavaScript. It supports most of the HTML5 features available in Chrome for Android 30. It also brings an updated version of the JavaScript Engine (V8) that delivers dramatically improved JavaScript performance.
In addition, the new Chromium WebView supports remote debugging using Chrome DevTools. For example, you can use Chrome DevTools on your development machine to inspect, debug, and analyze your WebView content live on a mobile device.
The new Chromium WebView is included on all compatible devices running Android 4.4 and higher. You can take advantage of the new WebView right away, and with minimum modifications to existing apps and content. In most cases, your content will migrate to the new implementation seamlessly.

New media capabilities

Screen recording

Now it's easy to create high-quality video of your app, directly from your Android device. Android 4.4 adds support for screen recording and provides a screen recording utility that lets you start and stop recording on a device that's connected to your Android SDK environment over USB. It's a great new way to create walkthroughs and tutorials for your app, testing materials, marketing videos, and more.
With the screen recording utility, you can capture video of your device screen contents and store the video as an MP4 file on the device. You can record at any device-supported resolution and bitrate you want, and the output retains the aspect ratio of the display. By default, the utility selects a resolution equal or close to the device's display resolution in the current orientation. When you are done recording, you can share the video directly from your device or pull the MP4 file to your host computer for post-production.
If your app plays video or other protected content that you don’t want to be captured by the screen recorder, you can useSurfaceView.setSecure() to mark the content as secure.
You can access screen recording through the adb tool included in the Android SDK, using the commandadb shell screenrecord. You can also launch it through the DDMS panel in Android Studio.

Resolution switching through adaptive playback

Android 4.4 brings formal support for adaptive playback into the Android media framework. Adaptive playback is an optional feature of video decoders for MPEG-DASH and other formats that enables seamless change in resolution during playback. The client can start to feed the decoder input video frames of a new resolution and the resolution of the output buffers change automatically, and without a significant gap.
Resolution switching in Android 4.4 lets media apps offer a significantly better streaming video experience. Apps can check for adaptive playback support at runtime using existing APIs and implement resolution-switching using new APIs introduced in Android 4.4.

Common Encryption for DASH

Android now supports the Common Encryption (CENC) for MPEG-DASH, providing a standard, multiplatform DRM scheme for managing protecting content. Apps can take advantage of CENC through Android's modular DRM framework and platform APIs for supporting DASH.

HTTP Live Streaming

Android 4.4 updates the platform's HTTP Live Streaming (HLS) support to a superset of version 7 of the HLS specification (version 4 of the protocol). See the IETF draft for details.

Audio Tunneling to DSP

For high-performance, lower-power audio playback, Android 4.4 adds platform support for audio tunneling to a digital signal processor (DSP) in the device chipset. With tunneling, audio decoding and output effects are off-loaded to the DSP, waking the application processor less often and using less battery.
Audio tunneling can dramatically improve battery life for use-cases such as listening to music over a headset with the screen off. For example, with audio tunneling, Nexus 5 offers a total off-network audio playback time of up to 60 hours, an increase of over 50% over non-tunneled audio.
Media applications can take advantage of audio tunneling on supported devices without needing to modify code. The system applies tunneling to optimize audio playback whenever it's available on the device.
Visualizer showing loudness enhancer audio effect
Visualization of how the LoudnessEnhancer effect can make speech content more audible.
Audio tunneling requires support in the device hardware. Currently audio tunneling is available on Nexus 5 and we're working with our chipset partners to make it available on more devices as soon as possible.

Audio monitoring

Apps can use new monitoring tools in the Visualizer effect to get updates on the peak and RMS levels of any currently playing audio on the device. For example, you could use this creatively in music visualizers or to implement playback metering in a media player.

Loudness enhancer

Media playback applications can increase the loudness of spoken content by using the new LoudnessEnhancer effect, which acts as compressor with time constants that are specifically tuned for speech.

Audio timestamps for improved AV sync

The audio framework can now report presentation timestamps from the audio output HAL to applications, for better audio-video synchronization. Audio timestamps let your app determine when a specific audio frame will be (or was) presented off-device to the user; you can use the timestamp information to more accurately synchronize audio with video frames.

Wi-Fi CERTIFIED Miracast™

Android 4.4 devices can now be certified to the Wi-Fi Alliance Wi-Fi Display Specification as Miracast compatible. To help with testing, a new Wireless Display developer option exposes advanced configuration controls and settings for Wireless Display certification. You can access the option at Settings > Developer options > Wireless display certification. Nexus 5 is a Miracast certified wireless display device.

RenderScript Compute

Renderscipt optimizations chart
Performance benchmarks for Android 4.4 relative to Android 4.3, run on the same devices (Nexus 7, Nexus 10).

Ongoing performance improvements

When your apps use RenderScript, they'll benefit fromongoing performance tuning in the RenderScript runtime itself, without the need for recompilation. The chart at right shows performance gains in Android 4.4 on two popular chipsets.

GPU acceleration

Any app using RenderScript on a supported device benefits from GPU acceleration, without code changes or recompiling. Since the Nexus 10 first debuted RenderScript GPU acceleration, various other hardware partners have added support.
Now with Android 4.4, GPU acceleration is available on the Nexus 5, as well as the Nexus 4, Nexus 7 (2013), and Nexus 10, and we're working with our partners to bring it to more devices as soon as possible.

RenderScript in the Android NDK

Now you can take advantage of RenderScript directly from your native code. A new C++ API in the Android Native Development Kit (NDK) lets you access the same RenderScript functionality available through the framework APIs, including script intrinsics, custom kernels, and more.
If you have large, performance-intensive tasks to handle in native code, you can perform those tasks using RenderScript and integrate them with your native code. RenderScript offers great performance across a wide range of devices, with automatic support for multi-core CPUs, GPUs, and other processors.
When you build an app that uses the RenderScript through the NDK, you can distribute it to any device running Android 2.2 or or higher, just like with the RenderScript support library available for framework APIs.

Graphics

GLES2.0 SurfaceFlinger

Android 4.4 upgrades its SurfaceFlinger from OpenGL ES 1.0 to OpenGL ES 2.0.

New Hardware Composer support for virtual displays

The latest version of Android Hardware Composer, HWComposer 1.3, supports hardware composition of one virtual display in addition to the primary, external (e.g. HDMI) display, and has improved OpenGL ES interoperability.

New Types of Connectivity

New Bluetooth profiles

Android 4.4 support for two new Bluetooth profiles to let apps support a broader range of low-power and media interactions. Bluetooth HID over GATT (HOGP) gives apps a low-latency link with low-power peripheral devices such as mice, joysticks, and keyboards. Bluetooth MAP lets your apps exchange messages with a nearby device, for example an automotive terminal for handsfree use or another mobile device. As an extension to Bluetooth AVRCP 1.3, users can now set absolute volume on the system from their Bluetooth devices.
Platform support for HOGP, MAP, and AVRCP is built on the Bluedroid Bluetooth stack introduced by Google and Broadcom in Android 4.2. Support is available right away on Nexus devices and other Android-compatible devices that offer compatible Bluetooth capabilities.

IR Blasters

Android 4.4 introduces platform support for built-in IR blasters, along with a new API and system service that let you create apps to take advantage them.
Using the new API, you can build apps that let users remotely control nearby TVs, tuners, switches, and other electronic devices. The API lets your app check whether the phone or tablet has an infrared emitter, query it's carrier frequencies, and then send infrared signals.
Because the API is standard across Android devices running Android 4.4 or higher, your app can support the broadest possible range of vendors without writing custom integration code.

Wi-Fi TDLS support

Android 4.4 introduces a seamless way to stream media and other data faster between devices already on the same Wi-Fi network by supporting Wi-Fi Tunneled Direct Link Setup (TDLS).

Accessibility

System-wide settings for closed captioning

Android 4.4 now supports a better accessibility experience across apps by adding system-wide preferences for Closed Captioning. Users can go to Settings > Accessibility > Captions to set global captioning preferences, such as whether to show captions and what language, text size, and text style to use.
Apps that use video can now access the user's captioning settings and adjust presentation to meet the user's preferences. A new captioning manager API lets you check and monitor the user's captioning preferences. The captioning manager provides you with the user's preferred captioning state as well as preferred locale, scaling factor, and text style. The text style includes foreground and background colors, edge properties, and typeface.
Apps can now refer to the user's system-wide captions preferences. An example of the expected display style is shown right in the settings.
In addition, apps that use VideoViewcan use a new API to pass a captioning stream along with a video stream for rendering. The system automatically handles the display of the captions on video frames according to the user's systemwide settings. Currently, VideoView supports auto-display of captions in WebVTT format only.
All apps that show captions should make sure to check the user's systemwide captioning preferences and render captions as closely as possible to those preferences. For more insight into how specific combinations of settings should look, you can look at a preview of captions in different languages, sizes, and styles right in the Settings app.

Enhanced Accessibility APIs

Android 4.4 extends the accessibility APIs to support more precise structural and semantic description and observation of onscreen elements. With the new APIs, developers can improve the quality of accessible feedback by providing accessibility services with more information about on-screen elements.
In accessibility nodes, developers can now determine whether a node is a popup, get its input type, and more. You can also use new APIs to work with nodes that contain grid-like information, such as lists and tables. For example, you can now specify new supported actions, collection information, live region modes, and more.
New accessibility events let developers more closely follow the changes that are taking place in window content, and they can now listen for changes in the touch exploration mode on the device.

Support for international Users

Drawable mirroring for RTL locales

If your app is targeting users who use RTL scripts, you can use a new API to declare that a drawable should be auto-mirrored when the user's locale setting includes an RTL language.
Declaring a drawable as auto-mirrored helps you prevent duplication of assets in your app and reduces the the size of your APK. When you have drawables that are the reusable for both LTR and RTL presentations, you can declare the default versions as auto-mirrored and then omit those Drawables from your RTL resources.
The Force RTL layout option makes it easier to test your app's localization.
You can declare various types of drawables as auto-mirrored in your application code, such as bitmap, nine-patch, layer, state list, and other drawables. You can also declare a drawable as auto-mirrored in your resource files by using a new attribute.

Force RTL Layout

To make it easier to test and debug layout mirroring issues without switching to an RTL language, Android includes a new developer option to force RTL layout direction in all apps.
The Force RTL layout option switches the device to RTL layout for all locales and displays text in your current language. This can help you find layout issues across your app, without having to display the app in an RTL language. You can access the option in Settings > Developer options > Force RTL layout direction.

Security enhancements

SELinux (enforcing mode)

Android 4.4 updates its SELinux configuration from "permissive" to "enforcing." This means potential policy violations within a SELinux domain that has an enforcing policy will be blocked.

Improved cryptographic algorithms

Android has improved its security further by adding support for two more cryptographic algorithms. Elliptic Curve Digital Signature Algorithm (ECDSA) support has been added to the keystore provider improving security of digital signing, applicable to scenarios such as signing of an application or a data connection. The Scrypt key derivation function is implemented to protect the cryptographic keys used for full-disk encryption.

Other enhancements

On multiuser devices, VPNs are now applied per user. This can allow a user to route all network traffic through a VPN without affecting other users on the device. Also, Android now supports FORTIFY_SOURCE level 2, and all code is compiled with those protections. FORTIFY_SOURCE has been enhanced to work with clang.

Tools for analyzing memory use

Procstats

A new tool called procstats helps you analyze the memory resources your app uses, as well as the resources used by other apps and services running on the system.
Procstats keeps track of how apps are running over time, providing data about their execution durations and memory use to help determine how efficiently they are performing. This is most important for apps that start services that run in the background, since it lets you monitor how long they are running and how much RAM they are using while doing so. Procstats will also collect data for foreground applications about memory use over time to determine the overall memory profile of the app.
Procstats can help you identify background services started by your app. You can keep track of how long those services continue running and how much RAM they use while doing so. Procstats also lets you profile your app while it's in the foreground, using its memory use over time to determine its overall memory profile.
The new procstats tool lets you check the memory use of apps and services over time.
The enhanced meminfo tool lets you see details of memory use for an app.
You can access procstats from the adb tool included in the Android SDK, adb shell dumpsys procstats. Also, for on-device profiling, see the Process Stats developer option, below.

On-device memory status and profiling

Android 4.4 includes a new developer option to make it easier to analyze your app's memory profile while it's running on any device or emulator. It's especially useful to get a view of how your app uses memory and performs on devices with low RAM. You can access the option at Settings > Developer options > Process stats
 
Process stats is a convenient way to check your app's memory use. You can see how your app compares to other apps and zoom in on specific data about your app or it's background services.
The Process Stats option shows you a variety of high-level metrics on your app's memory use, based on data collected using the new procstats service. On the main screen you can see a summary of system memory status. Green indicates relative amount of time spent with low RAM usage, yellow indicates moderate RAM usage, and red indicates high (critical) RAM usage
Below the summary is a list summarizing each app's memory load on the system. For each app, a blue bar indicates the relative computed memory load (runtime x avg_pss) of its process, and a percentage number indicates the relative amount of time spent in the background. You can filter the list to show only foreground, background, or cached processes, and you can include or exclude system processes. You can also change the duration of the data collected to 3, 6, 12, or 24 hours, and you can include or exclude uss memory.
To take a closer look at a specific app's memory usage in isolation, tap the app. For each app, you can now see a summary of the memory consumed and the percentage of the collection interval that the app has been running. You can also see the average and maximum usage over the collection period, and below the app's services and the percentage of time they've been running.
Analyzing your app using the data in Process Stats can reveal issues and suggest possible optimizations for your app. For example, if your app is running longer than it should or using too much memory over a period of time, there could be bugs in your code that you can resolve to improve your app's performance, especially when running on a device with low RAM.

Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in theCreative Commons 2.5 Attribution License.

Original Page Direct link:
http://developer.android.com/about/versions/kitkat.html
Posted by at No comments:
Labels: , , ,

Android 5.0 APIs

Android 5.0 APIs



API Level: 21
Android 5.0 (LOLLIPOP) offers new features for users and app developers. This document provides an introduction to the most notable new APIs.
If you have a published app, make sure to check out the Android 5.0 Behavior Changes that you should account for in your app. These behavior changes may affect your app on Android 5.0 devices, even if you are not using new APIs or targeting new functionality.
For a high-level look at the new platform features, instead see the Android Lollipop highlights.

Start developing

To start building apps for Android 5.0, you must first get the Android SDK. Then use the SDK Manager to download the Android 5.0 SDK Platform and System Images.

Update your target API level

To better optimize your app for devices running Android 5.0, set yourtargetSdkVersion to "21", install your app on an Android 5.0 system image, test it, then publish the updated app with this change.
You can use Android 5.0 APIs while also supporting older versions by adding conditions to your code that check for the system API level before executing APIs not supported by your minSdkVersion. To learn more about maintaining backward compatibility, read Supporting Different Platform Versions.
For more information about how API levels work, read What is API Level?

Important behavior changes

If you have previously published an app for Android, be aware that your app might be affected by changes in Android 5.0.
Please see Android 5.0 Changes for complete information.

User Interface

Material design support

Android 5.0 adds support for Android's new material design style. You can create apps with material design that are visually dynamic and have UI element transitions that feel natural to users. This support includes:
  • The material theme
  • View shadows
  • The RecyclerView widget
  • Drawable animation and styling effects
  • Material design animation and activity transition effects
  • Animators for view properties based on the state of the view
  • Customizable UI widgets and app bars with color palettes that you control
  • Animated and non-animated drawables based on XML vector graphics
To learn more about adding material design functionality to your app, see Material Design.

Concurrent documents and activities in the recents screen

In previous releases, the recents screen could only display only one task for each app that the user interacted with most recently. Now your app can open more tasks as needed for additional concurrent activities for documents. This feature facilitates multitasking by letting users quickly switch between individual activities and documents from the recents screen, with a consistent switching experience across all apps. Examples of such concurrent tasks might include open tabs in a web browser app, documents in a productivity app, concurrent matches in a game, or chats in a messaging app. Your app can manage its tasks through the ActivityManager.AppTask class.
To insert a logical break so that the system treats your activity as a new task, use FLAG_ACTIVITY_NEW_DOCUMENT when launching the activity with startActivity(). You can also get this behavior by setting the <activity> element'sdocumentLaunchMode attribute to "intoExisting" or "always" in your manifest.
To avoid cluttering the recents screen, you can set the maximum number of tasks from your app that can appear in that screen. To do this, set the <application> attribute android:maxRecents. The current maximum that can be specified is 50 tasks per user (25 for low RAM devices).
Tasks in the recents screen can be set to persist across reboots. To control the persistence behavior, use theandroid:persistableMode attribute. You can also change the visual properties of an activity in the recents screen, such as the activity’s color, label, and icon, by calling the setTaskDescription() method.

WebView updates

Android 5.0 updates the WebView implementation to Chromium M37, bringing security and stability enhancements, as well as bug fixes. The default user-agent string for a WebView running on Android 5.0 has been updated to incorporate 37.0.0.0 as the version number.
This release introduces the PermissionRequest class, which allows your app to grant the WebView permission to access protected resources like the camera and microphone, through web APIs such as getUserMedia(). Your app must have the appropriate Android permissions for these resources in order to grant the permissions to the WebView.
With the new onShowFileChooser() method, you can now use an input form field in the WebView, and launch a file chooser to select images and files from the Android device.
Additionally, this release brings support for the WebAudio, WebGL, and WebRTC open standards. To learn more about the new features included in this release, see WebView for Android.

Screen capturing and sharing

Android 5.0 lets you add screen capturing and screen sharing capabilities to your app with the newandroid.media.projection APIs. This functionality is useful, for example, if you want to enable screen sharing in a video conferencing app.
The new createVirtualDisplay() method allows your app to capture the contents of the main screen (the default display) into a Surface object, which your app can then send across the network. The API only allows capturing non-secure screen content, and not system audio. To begin screen capturing, your app must first request the user’s permission by launching a screen capture dialog using an Intent obtained through the createScreenCaptureIntent() method.
For an example of how to use the new APIs, see the MediaProjectionDemo class in the sample project.

Notifications

Lock screen notifications

Lock screens in Android 5.0 have the ability to present notifications. Users can choose via Settings whether to allow sensitive notification content to be shown over a secure lock screen.
Your app can control the level of detail visible when its notifications are displayed over the secure lock screen. To control the visibility level, call setVisibility() and specify one of these values:
  • VISIBILITY_PRIVATE: Shows basic information, such as the notification’s icon, but hides the notification’s full content.
  • VISIBILITY_PUBLIC: Shows the notification’s full content.
  • VISIBILITY_SECRET: Shows nothing, excluding even the notification’s icon.
When the visibility level is VISIBILITY_PRIVATE, you can also provide a redacted version of the notification content that hides personal details. For example, an SMS app might display a notification that shows "You have 3 new text messages" but hides the message content and senders. To provide this alternative notification, first create the replacement notification using Notification.Builder. When you create the private notification object, attach the replacement notification to it through the setPublicVersion() method.

Notifications metadata

Android 5.0 uses metadata associated with your app notifications to sort the notifications more intelligently. To set the metadata, call the following methods in Notification.Builder when you construct the notification:
  • setCategory(): Tells the system how to handle your app notifications when the device is in priority mode (for example, if a notification represents an incoming call, instant message, or alarm).
  • setPriority(): Marks the notification as more or less important than normal notifications. Notifications with the priority field set to PRIORITY_MAX or PRIORITY_HIGH appear in a small floating window if the notification also has sound or vibration.
  • addPerson(): Enables you to add one or more people who are relevant to a notification. Your app can use this to signal to the system that it should group together notifications from the specified people, or rank notifications from these people as being more important.

Graphics

Support for OpenGL ES 3.1

Android 5.0 adds Java interfaces and native support for OpenGL ES 3.1. Key new functionality provided in OpenGL ES 3.1 includes:
  • Compute shaders
  • Separate shader objects
  • Indirect draw commands
  • Multisample and stencil textures
  • Shading language improvements
  • Extensions for advanced blend modes and debugging
  • Backward compatibility with OpenGL ES 2.0 and 3.0
The Java interface for OpenGL ES 3.1 on Android is provided with GLES31. When using OpenGL ES 3.1, be sure that you declare it in your manifest file with the <uses-feature> tag and the android:glEsVersion attribute. For example:
<manifest>
    <uses-feature android:glEsVersion="0x00030001" />
    ...</manifest>
For more information about using OpenGL ES, including how to check the device’s supported OpenGL ES version at runtime, see the OpenGL ES API guide.

Android Extension Pack

In addition to OpenGL ES 3.1, this release provides an extension pack with Java interfaces and native support for advanced graphics functionality. These extensions are treated as a single package by Android. (If theANDROID_extension_pack_es31a extension is present, your app can assume all extensions in the package are present and enable the shading language features with a single #extension statement.)
The extension pack supports:
  • Guaranteed fragment shader support for shader storage buffers, images, and atomics (Fragment shader support is optional in OpenGL ES 3.1.)
  • Tessellation and geometry shaders
  • ASTC (LDR) texture compression format
  • Per-sample interpolation and shading
  • Different blend modes for each color attachment in a frame buffer
The Java interface for the extension pack is provided with GLES31Ext. In your app manifest, you can declare that your app must be installed only on devices that support the extension pack. For example:
<manifest>
    <uses-feature android:name=“android.hardware.opengles.aep”
        android:required="true" />
    ...</manifest>

Media

Camera API for advanced camera capabilities

Android 5.0 introduces the new android.hardware.camera2 API to facilitate fine-grain photo capture and image processing. You can now programmatically access the camera devices available to the system with getCameraIdList()and connect to a specific device with openCamera(). To start capturing images, create a CameraCaptureSession and specify the Surface objects to send captured images. The CameraCaptureSession can be configured to take single shots or multiple images in a burst.
To be notified when new images are captured, implement the CameraCaptureSession.CaptureCallback listener and set it in your capture request. Now when the system completes the image capture request, yourCameraCaptureSession.CaptureCallback listener receives a call to onCaptureCompleted(), providing you with the image capture metadata in a CaptureResult.
The CameraCharacteristics class lets your app detect what camera features are available on a device. The object'sINFO_SUPPORTED_HARDWARE_LEVEL property represents the camera's level of functionality.
To see how to use the updated Camera API, refer to the Camera2Basic and Camera2Video implementation samples in this release.

Audio playback

This release includes the following changes to AudioTrack:
  • Your app can now supply audio data in floating-point format (ENCODING_PCM_FLOAT). This permits greater dynamic range, more consistent precision, and greater headroom. Floating-point arithmetic is especially useful during intermediate calculations. Playback endpoints use integer format for audio data, and with lower bit depth. (In Android 5.0, portions of the internal pipeline are not yet floating point.)
  • Your app can now supply audio data as a ByteBuffer, in the same format as provided by MediaCodec.
  • The WRITE_NON_BLOCKING option can simplify buffering and multithreading for some apps.

Media playback control

Use the new notification and media APIs to ensure that the system UI knows about your media playback and can extract and show album art. Controlling media playback across a UI and a service is now easier with the new MediaSession andMediaController classes.
The new MediaSession class replaces the deprecated RemoteControlClient class and provides a single set of callback methods for handling transport controls and media buttons. If your app provides media playback and runs on the AndroidTV or Wear platform, use the MediaSession class to handle your transport controls using the same callback methods.
You can now build your own media controller app with the new MediaController class. This class provides a thread-safe way to monitor and control media playback from your app's UI process. When creating a controller, specify aMediaSession.Token object so that your app can interact with the given MediaSession. By using theMediaController.TransportControls methods, you can send commands such as play(), stop(), skipToNext(), and setRating() to control media playback on that session. With the controller, you can also register aMediaController.Callback object to listen for metadata and state changes on the session.
In addition, you can create rich notifications that allow playback control tied to a media session with the newNotification.MediaStyle class.

Media browsing

Android 5.0 introduces the ability for apps to browse the media content library of another app, through the newandroid.media.browse API. To expose the media content in your app, extend the MediaBrowserService class. Your implementation of MediaBrowserService should provide access to a MediaSession.Token so that apps can play media content provided through your service.
To interact with a media browser service, use the MediaBrowser class. Specify the component name for a MediaSessionwhen you create an MediaBrowser instance. Using that browser instance, your app can then connect to the associated service and obtain a MediaSession.Token object to play content exposed through that service.

Storage

Directory selection

Android 5.0 extends the Storage Access Framework to let users select an entire directory subtree, giving apps read/write access to all contained documents without requiring user confirmation for each item.
To select a directory subtree, build and send an OPEN_DOCUMENT_TREE intent. The system displays allDocumentsProvider instances that support subtree selection, letting the user browse and select a directory. The returned URI represents access to the selected subtree. You can then use buildChildDocumentsUriUsingTree() andbuildDocumentUriUsingTree() along with query() to explore the subtree.
The new createDocument() method lets you create new documents or directories anywhere under the subtree. To manage existing documents, use renameDocument() and deleteDocument(). Check COLUMN_FLAGS to verify provider support for these calls before issuing them.
If you're implementing a DocumentsProvider and want to support subtree selection, implement isChildDocument() and include FLAG_SUPPORTS_IS_CHILD in your COLUMN_FLAGS.
Android 5.0 also introduces new package-specific directories on shared storage where your app can place media files for inclusion in MediaStore. The new getExternalMediaDirs() returns paths to these directories on all shared storage devices. Similarly to getExternalFilesDir(), no additional permissions are needed by your app to access the returned paths. The platform periodically scans for new media in these directories, but you can also use MediaScannerConnectionto explicitly scan for new content.

Wireless & Connectivity

Multiple network connections

Android 5.0 provides new multi-networking APIs that let your app dynamically scan for available networks with specific capabilities, and establish a connection to them. This functionality is useful when your app requires a specialized network, such as an SUPL, MMS, or carrier-billing network, or if you want to send data using a particular type of transport protocol.
To select and connect to a network dynamically from your app, follow these steps:
  1. Create a ConnectivityManager.
  2. Use the NetworkRequest.Builder class to create an NetworkRequest object and specify the network features and transport type your app is interested in.
  3. To scan for suitable networks, call requestNetwork() or registerNetworkCallback(), and pass in theNetworkRequest object and an implementation of ConnectivityManager.NetworkCallback. Use therequestNetwork() method if you want to actively switch to a suitable network once it’s detected; to receive only notifications for scanned networks without actively switching, use the registerNetworkCallback() method instead.
When the system detects a suitable network, it connects to the network and invokes the onAvailable() callback. You can use the Network object from the callback to get additional information about the network, or to direct traffic to use the selected network.

Bluetooth Low Energy

Android 4.3 introduced platform support for Bluetooth Low Energy (Bluetooth LE) in the central role. In Android 5.0, an Android device can now act as a Bluetooth LE peripheral device. Apps can use this capability to make their presence known to nearby devices. For instance, you can build apps that allow a device to function as a pedometer or health monitor and communicate its data with another Bluetooth LE device.
The new android.bluetooth.le APIs enable your apps to broadcast advertisements, scan for responses, and form connections with nearby Bluetooth LE devices. To use the new advertising and scanning features, add theBLUETOOTH_ADMIN permission in your manifest. When users update or download your app from the Play Store, they are asked to grant the following permission to your app: "Bluetooth connection information: Allows the app to control Bluetooth, including broadcasting to or getting information about nearby Bluetooth devices."
To begin Bluetooth LE advertising so that other devices can discover your app, call startAdvertising() and pass in an implementation of the AdvertiseCallback class. The callback object receives a report of the success or failure of the advertising operation.
Android 5.0 introduces the ScanFilter class so that your app can scan for only the specific types of devices it is interested in. To begin scanning for Bluetooth LE devices, call startScan() and pass in a list of filters. In the method call, you must also provide an implementation of ScanCallback to report when a Bluetooth LE advertisement is found.

NFC enhancements

Android 5.0 adds these enhancements to enable wider and more flexible use of NFC:
  • Android Beam is now available in the share menu.
  • Your app can invoke the Android Beam on the user’s device to share data by calling invokeBeam(). This avoids the need for the user to manually tap the device against another NFC-capable device to complete the data transfer.
  • You can use the new createTextRecord() method to create an NDEF record containing UTF-8 text data.
  • If you are developing a payment app, you now have the ability to register an NFC application ID (AID) dynamically by calling registerAidsForService(). You can also use setPreferredService() to set the preferred card emulation service that should be used when a specific activity is in the foreground.

Project Volta

In addition to new features, Android 5.0 emphasizes improvements in battery life. Use the new APIs and tool to understand and optimize your app’s power consumption.

Scheduling jobs

Android 5.0 provides a new JobScheduler API that lets you optimize battery life by defining jobs for the system to run asynchronously at a later time or under specified conditions (such as when the device is charging). Job scheduling is useful in such situations as:
  • The app has non-user-facing work that you can defer.
  • The app has work you'd prefer to do when the unit is plugged in.
  • The app has a task that requires network access or a Wi-Fi connection.
  • The app has a number of tasks that you want to run as a batch on a regular schedule.
A unit of work is encapsulated by a JobInfo object. This object specifies the scheduling criteria.
Use the JobInfo.Builder class to configure how the scheduled task should run. You can schedule the task to run under specific conditions, such as:
  • Start when the device is charging
  • Start when the device is connected to an unmetered network
  • Start when the device is idle
  • Finish before a certain deadline or with a minimum delay
For example, you can add code like this to run your task on an unmetered network:
JobInfo uploadTask = new JobInfo.Builder(mJobId,
                                         mServiceComponent /* JobService component */)
        .setRequiredNetworkCapabilities(JobInfo.NetworkType.UNMETERED)
        .build();
JobScheduler jobScheduler =
        (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheduler.schedule(uploadTask);
If the device has stable power (that is, it has been plugged in for more than 2 minutes and the battery is at a healthy level), the system will run any scheduled job that is ready to run, even if the job’s deadline has not expired.
To see an example of how to use the JobScheduler API, refer to the JobSchedulerSample implementation sample in this release.

Developer tools for battery usage

The new dumpsys batterystats command generates interesting statistical data about battery usage on a device, organized by unique user ID (UID). The statistics include:
  • History of battery related events
  • Global statistics for the device
  • Approximate power use per UID and system component
  • Per-app mobile ms per packet
  • System UID aggregated statistics
  • App UID aggregated statistics
Use the --help option to learn about the various options for tailoring the output. For example, to print battery usage statistics for a given app package since the device was last charged, run this command:
$ adb shell dumpsys batterystats --charged <package-name>
You can use the Battery Historian tool on the output of the dumpsys command to generate an HTML visualization of power-related events from the logs. This information makes it easier for you to understand and diagnose any battery related issues.

Android in the Workplace and in Education

Managed provisioning

Android 5.0 provides new functionality for running apps within an enterprise environment. A device administrator can initiate a managed provisioning process to add a copresent but separate managed profile to a device, if the user has an existing personal account. Apps that are associated with managed profiles appear alongside non-managed apps in the user’s Launcher, recents screen, and notifications.
To start the managed provisioning process, send ACTION_PROVISION_MANAGED_PROFILE in an Intent. If the call is successful, the system triggers the onProfileProvisioningComplete() callback. You can then callsetProfileEnabled() to enable this managed profile.
By default, only a small subset of apps are enabled in the managed profile. You can install additional apps in the managed profile by calling enableSystemApp().
If you are developing a Launcher app, you can use the new LauncherApps class to get a list of launchable activities for the current user and any associated managed profiles. Your Launcher can make the managed apps visually prominent by appending a work badge to the icon drawable. To retrieve the badged icon, call getUserBadgedIcon().
To see how to use the new functionality, refer to the BasicManagedProfile implementation sample in this release.

Device owner

Android 5.0 introduces the ability to deploy a device owner app. A device owner is a specialized type of device administrator that has the additional ability to create and remove secondary users and to configure global settings on the device. Your device owner app can use the methods in the DevicePolicyManager class to take fine-grain control of the configuration, security, and apps on managed devices. A device can have only one active device owner at a time.
To deploy and activate a device owner, you must perform an NFC data transfer from a programming app to the device while the device is in its unprovisioned state. This data transfer sends the same information as in the provisioning intent described in Managed provisioning.

Screen pinning

Android 5.0 introduces a new screen pinning API that lets you temporarily restrict users from leaving your task or being interrupted by notifications. This could be used, for example, if you are developing an education app to support high stakes assessment requirements on Android, or a single-purpose or kiosk application. Once your app activates screen pinning, users cannot see notifications, access other apps, or return to the home screen, until your app exits the mode.
There are two ways to activate screen pinning:
  • Manually: Users can enable screen pinning in Settings > Security > Screen Pinning, and select the tasks they want to pin by touching the green pin icon in the recents screen.
  • Programmatically: To activate screen pinning programmatically, call startLockTask() from your app. If the requesting app is not a device owner, the user is prompted for confirmation. A device owner app can call thesetLockTaskPackages() method to enable apps to be pinnable without the user confirmation step.
When task locking is active, the following behavior happens:
  • The status bar is blank, and user notifications and status information are hidden.
  • The Home and Recent Apps buttons are hidden.
  • Other apps cannot launch new activities.
  • The current app can start new activities, as long as doing so does not create new tasks.
  • When screen pinning is invoked by a device owner, the user remains locked to your app until the app callsstopLockTask().
  • If screen pinning is activity by another app that is not a device owner or by the user directly, the user can exit by holding both the Back and Recent buttons.

Printing Framework

Render PDF as bitmap

You can now render PDF document pages into bitmap images for printing by using the new PdfRenderer class. You must specify a ParcelFileDescriptor that is seekable (that is, the content can be randomly accessed) on which the system writes the the printable content. Your app can obtain a page for rendering with openPage(), then call render() to turn the opened PdfRenderer.Page into a bitmap. You can also set additional parameters if you only want to convert a portion of the document into a bitmap image (for example, to implement tiled rendering to zoom in on the document).
For an example of how to use the new APIs, see the PdfRendererBasic sample.

System

App usage statistics

You can now access app usage history on an Android device with the new android.app.usage API. This API provides more detailed usage information than the deprecated getRecentTasks() method. To use this API, you must first declare the "android.permission.PACKAGE_USAGE_STATS" permission in your manifest. The user must also enable access for this app through Settings > Security > Apps with usage access.
The system collects the usage data on a per-app basis, aggregating the data over daily, weekly, monthly, and yearly intervals. The maximum duration that the system keeps this data is as follows:
  • Daily data: 7 days
  • Weekly data: 4 weeks
  • Monthly data: 6 months
  • Yearly data: 2 years
For each app, the system records the following data:
  • The last time the app was used
  • The total length of time the app was in the foreground for that time interval (by day, week, month, or year)
  • Timestamp capturing when a component (identified by a package and activity name) moved to the foreground or background during a day
  • Timestamp capturing when a device configuration changed (such as when the device orientation changed because of rotation)

Testing & Accessibility

Testing and accessibility improvements

Android 5.0 adds the following support for testing and accessibility:
  • The new getWindowAnimationFrameStats() and getWindowContentFrameStats() methods capture frame statistics for window animations and content. These methods let you write instrumentation tests to evaluate whether an app is rendering frames at a sufficient refresh frequency to provide a smooth user experience.
  • The new executeShellCommand() method lets you execute shell commands from your instrumentation test. The command execution is similar to running adb shell from a host connected to the device, allowing you to use shell-based tools such as dumpsys, am, content, and pm.
  • Accessibility services and test tools that use the accessibility APIs (such as UiAutomator) can now retrieve detailed information about the properties of windows on the screen that sighted users can interact with. To retrieve a list ofAccessibilityWindowInfo objects, call the new getWindows() method.
  • The new AccessibilityNodeInfo.AccessibilityAction class lets you define standard or customized actions to perform on an AccessibilityNodeInfo. The new AccessibilityNodeInfo.AccessibilityAction class replaces the actions-related APIs previously found in AccessibilityNodeInfo.
  • Android 5.0 provides finer-grain control over text-to-speech synthesis in your app. The new Voice class allows your app to use voice profiles associated with specific locales, quality and latency rating, and text-to-speech engine-specific parameters.

IME

Easier switching between input languages

Beginning in Android 5.0, users can more easily switch between all input method editors (IME) supported by the platform. Performing the designated switching action (usually touching a Globe icon on the soft keyboard) cycles through all such IMEs. This change in behavior is implemented by the shouldOfferSwitchingToNextInputMethod() method.
In addition, the framework now checks whether the next IME includes a switching mechanism at all (and, thus, whether that IME supports switching to the IME after it). An IME with a switching mechanism will not cycle to an IME without one. This change in behavior is implemented by the switchToNextInputMethod() method.
To see an example of how to use the updated IME-switching APIs, refer to the updated soft-keyboard implementation sample in this release. To learn more about how to implement switching between IMEs, see Creating an Input Method.

Manifest Declarations

Declarable required features

The following values are now supported in the <uses-feature> element, so you can ensure that your app is installed only on devices that provide the features your app needs.

User permissions

The following permission is now supported in the <uses-permission> element to declare the permissions your app requires to access certain APIs.
  • BIND_DREAM_SERVICE: When targeting API level 21 and higher, this permission is required by a Daydream service, to ensure that only the system can bind to it.

Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in theCreative Commons 2.5 Attribution License.

Original Page Direct link:
http://developer.android.com/about/versions/android-5.0.html
Posted by at No comments:
Labels: , , , , ,
Subscribe to: Posts (Atom)