- Уровень Android API, обратная и прямая совместимость
- Уровень API
- От исходного кода к APK-файлу
- DEX файлы и Android Runtime
- compileSdkVersion
- minSdkVersion
- targetSdkVersion
- Android 4.1 APIs
- In this document show more show less
- See also
- Declare your app API Level
- App Components
- Isolated services
- Memory management
- Content providers
- Live Wallpapers
- App stack navigation
- Multimedia
- Media codecs
- Record audio on cue
- Timed text tracks
- Audio effects
- Gapless playback
- Camera
- Auto focus movement
- Camera sounds
- Connectivity
- Android Beam
- Network service discovery
- Wi-Fi P2P service discovery
- Network usage
- Accessibility
- Accessibility service APIs
- Customizable app navigation
- More accessible widgets
- Copy and Paste
- Copy and paste with intents
- Renderscript
- Animation
- Activity launch animations
- Time animator
- User Interface
- Notifications
- Controls for system UI
- Remote views
- Font families
- Input Framework
- Multiple input devices
- Vibrate for input controllers
- Permissions
- Device Features
Уровень Android API, обратная и прямая совместимость
Добрый вечер, друзья. Мы подготовили полезный перевод для будущих студентов курса «Android-разработчик. Продвинутый курс». С радостью делимся с вами данным материалом.
Если вы читаете эту статью, значит вас могут интересовать такие вещи, как:
- Что означает уровень API?
- Как использовать compileSdkVersion , minSdkVersion или targetSdkVersion ?
- Как можно гарантировать, что приложение будет работать правильно на устройствах с разными версиями ОС?
Все эти понятия связаны друг с другом, и я постараюсь объяснить их вам в этой статье простым, но эффективным способом.
Для этого необходимо понимать разницу между SDK и API и знать что такое уровень API в экосистеме Android.
Это правда, что в Android между SDK и API существует отношение 1:1, и часто эти два термина используются как синонимы, но важно понимать, что это не одно и то же.
Правильнее говорить, что для каждой версии Android есть SDK и эквивалентный API, а также уровень этого API.
Расшифровывается как Software Development Kit (комплект для разработки программного обеспечения). Обратите внимание на слово «kit» (комплект)… он как раз представляет из себя набор различных инструментов, библиотек, документации, примеров, помогающих разработчикам создавать, отлаживать и запускать приложения для Android. API предоставляется вместе с SDK.
Если открыть SDK Manager в Android Studio, можно будет яснее увидеть, из чего состоит Android SDK.
На первой вкладке SDK Platform перечислены SDK каждой версии Android.
Как показано на рисунке ниже, Android 9.0 SDK (также известный как Pie) содержит:
- Android SDK Platform 28 (это API фреймворка).
- Исходный код для Android 28 (это реализация API, как вы видите, она не является обязательной… запомните это).
- и еще куча других вещей… например, различные системные образы для эмулятора Android.
Обзор SDK в Android Studio SDK Manager.
На второй вкладке SDK Tools показаны другие инструменты, которые также являются частью SDK, но не зависят от версии платформы. Это означает, что они могут быть выпущены или обновлены отдельно.
Расшифровывается как Application Programming Interface (программный интерфейс приложения). Это просто интерфейс, уровень абстракции, который обеспечивает связь между двумя разными «частями» программного обеспечения. Он работает как договор между поставщиком (например, библиотекой) и потребителем (например, приложением).
Это набор формальных определений, таких как классы, методы, функции, модули, константы, которые могут использоваться другими разработчиками для написания своего кода. При этом API не включает в себя реализацию.
Уровень API
Уровень API — это целочисленное значение, однозначно идентифицирующее версию API фреймворка, предлагаемую платформой Android.
Обычно обновления API фреймворка платформы разрабатываются таким образом, чтобы новая версия API оставалась совместимой с более ранними версиями, поэтому большинство изменений в новом API являются аддитивными, а старые части API становятся устаревшими, но не удаляются.
И теперь кто-то может задаться вопросом…
если API Android не предоставляет реализацию, а SDK Manager предлагает необязательный загружаемый исходный код API в составе SDK, то где находится соответствующая реализация?
Ответ прост. На устройстве.
Давайте разберемся с этим…
От исходного кода к APK-файлу
Как правило, проект под Android состоит из кода, написанного разработчиками с использованием Android API (модуль приложения), а также некоторых других библиотек/зависимостей (.jar-файлов, AAR, модулей и т.д.) и ресурсов.
Процесс компиляции преобразует код, написанный на Java или Kotlin, включая зависимости (одна из причин уменьшить ваш код!), в байт-код DEX, а затем сжимает все в файл APK вместе с ресурсами. На данном этапе реализация API не включена в итоговый APK!
Процесс сборки — Android Developers
DEX файлы и Android Runtime
Архитектура Android — Android Developers
Android Runtime — это место, где делается вся грязная работа и где выполняются DEX-файлы. Оно состоит из двух основных компонентов:
- Виртуальная машина, чтобы воспользоваться преимуществами переносимости кода и независимости от платформы. Начиная с Android 5.0 (Lollipop), старая среда выполнения, Dalvik Virtual Machine, была полностью заменена новой средой Android RunTime (ART). Dalvik использовал JIT-компилятор, тогда как ART использует AOT (Ahead of time) компиляцию плюс JIT для профилирования кода во время выполнения.
- Базовые библиотеки — это стандартные библиотеки Java и Android. Проще говоря, именно здесь находится реализация API.
Версия API, доступная на этом уровне, соответствует версии платформы Android, на которой запущено приложение.
Например, если на фактическом устройстве установлен Android 9 (Pie), доступны все API до 28 уровня.
Если вам понятны ключевые моменты работы Android Runtime и какова роль API, то должно быть достаточно просто понять обратную и прямую совместимость, а так же использование compileSdkVersion , minSdkVersion и targetSdkVersion .
compileSdkVersion
Это значение используется только для указания Gradle, с какой версией SDK компилировать ваше приложение. Это позволяет разработчикам получить доступ ко всем API, доступным до уровня API, установленного для compileSdkVersion .
Настоятельно рекомендуется выполнить компиляцию с последней версией SDK:
- высокий уровень API позволяет разработчикам использовать преимущества последнего API и возможностей, предоставляемых новыми платформами.
- чтобы использовать последнюю версию SupportLibrary , compileSdkVersion должен соответствовать версии SupportLibrary .
Например, чтобы использовать SupportLibrary-28.x.x , compileSdkVersion также должен быть равен 28.
- для перехода на AndroidX или его использования, compileSdkVersion должен быть установлен как минимум равным 28.
- чтобы быть готовым удовлетворить требования целевого уровня API от Google Play. В Google объявили, что для более быстрого распространения новых версий Android на рынке Google каждый год будет устанавливать минимальный целевой уровень API для новых приложений и обновлений. Больше информации вы можете найти здесь и здесь.
Приложения Android совместимы с новыми версиями платформы Android, поскольку изменения в API обычно являются аддитивными, а старое API может стать устаревшим, но не удаленным.
Это означает, что прямая совместимость в основном гарантируется платформой, и при запуске приложения на устройстве с более высоким уровнем API, чем тот, который указан в compileSdkVersion , не возникает никаких проблем во время выполнения, приложение будет работать так же, как и ожидалось, на более новых версиях платформы.
Приложение + compileSdkVersion = 26 и метод API xyz() , представленный в API 26 уровня, могут работать на устройстве с Android 8 Oreo (API 26 уровня).
Это же приложение может работать на устройстве с Android 9 Pie (API 28 уровня), поскольку метод API xyz() все еще доступен на API 28 уровня.
minSdkVersion
Это значение обозначает минимальный уровень API, на котором приложение может работать. Это минимальное требование. Если не указан, значением по умолчанию является 1.
Разработчики обязаны установить корректное значение и обеспечить правильную работу приложения до этого уровня API. Это называется обратной совместимостью.
Во время разработки Lint также предупредит разработчиков при попытке использовать любой API ниже указанного в minSdkVersion . Очень важно не игнорировать предупреждения и исправить их!
Чтобы обеспечить обратную совместимость, разработчики могут во время выполнения проверять версию платформы и использовать новый API в более новых версиях платформы и старый API в более старых версиях или, в зависимости от случая, использовать некоторые статические библиотеки, которые обеспечивают обратную совместимость.
Также важно упомянуть, что Google Play Store использует это значение, чтобы определить, можно ли установить приложение на определенное устройство, сопоставив версию платформы устройства с minSdkVersion приложения.
Разработчики должны быть очень осторожны при выборе этого значения, поскольку обратная совместимость не гарантируется платформой.
Выбор «правильного» значения для проекта также является бизнес-решением, поскольку оно влияет на то, насколько большой будет аудитория приложения. Посмотрите на распределение платформ.
Приложение + compileSdkVersion = 26 + minSdkVersion = 22 и метод API xyz() , представленный в API 26 уровня, могут работать на устройстве с Android 8 Oreo (API 26 уровня).
Это же приложение можно установить и запустить на более старом устройстве с Android 5.1 Lollipop (API 22 уровня), где метода API xyz() не существует. Если разработчики не обеспечили обратную совместимость ни с помощью проверок времени выполнения, ни с помощью каких-либо библиотек, то приложение будет аварийно завершать работу, как только оно попытается получить доступ к методу API xyz() .
targetSdkVersion
Это значение указывает уровень API, на котором приложение было разработано.
Не путайте его с compileSdkVersion . Последний используется только во время компиляции и делает новые API доступными для разработчиков. Первый, напротив, является частью APK (также как и minSdkVersion ) и изменяет поведение среды выполнения. Это способ, которым разработчики могут контролировать прямую совместимость.
Иногда могут быть некоторые изменения API в базовой системе, которые могут повлиять на поведение приложения при работе в новой среде выполнения.
Целевой уровень приложения включает поведение среды выполнения, которое зависит от конкретной версии платформы. Если приложение не готово к поддержке этих изменений поведения среды выполнения, оно, вероятно, завершится сбоем.
Простым примером является Runtime Permission, которое было представлено в Android 6 Marshmallow (API 23 уровня).
Приложение может быть скомпилировано с использованием API 23 уровня, но иметь целевым API 22 уровня, если оно еще не готово поддержать новую модель разрешений времени выполнения.
Таким образом, приложение может по-прежнему быть совместимым без включения нового поведения среды выполнения.
В любом случае, как уже упоминалось, Google требует, чтобы приложения удовлетворяли новым требованиям целевого уровня API, поэтому всегда следует иметь высокий приоритет для обновления этого значения.
Теперь соединяя все это вместе, мы видим четкое отношение
minSdkVersion ≤ targetSdkVersion ≤ compileSdkVersion
Имейте в виду, что настоятельно рекомендуется выполнить компиляцию в соответствии с последним уровнем API и стараться использовать targetSdkVersion == compileSdkVersion.
Источник
Android 4.1 APIs
In this document show more show less
See also
Android 4.1 ( JELLY_BEAN ) is a progression of the platform that offers improved performance and enhanced user experience. It adds new features for users and app developers. This document provides an introduction to the most notable and useful new APIs for app developers.
Declare your app API Level
To better optimize your app for devices running Android 4.1, you should set your targetSdkVersion to «16» , install it on an Android 4.1 system image, test it, then publish an update with this change.
You can use APIs in Android 4.1 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 Creating Backward-Compatible UIs.
More information about how API levels work is available in What is API Level?
As an app developer, Android 4.1 is available to you from the SDK Manager as a system image you can run in the Android emulator and an SDK platform against which you can build your app. You should download the system image and platform as soon as possible to build and test your app on Android 4.1.
App Components
Isolated services
By specifying android:isolatedProcess=»true» in the tag, your Service will run under its own isolated user ID process that has no permissions of its own.
Memory management
New ComponentCallbacks2 constants such as TRIM_MEMORY_RUNNING_LOW and TRIM_MEMORY_RUNNING_CRITICAL provide foreground processes more information about memory state before the system calls onLowMemory() .
New getMyMemoryState(ActivityManager.RunningAppProcessInfo) method allows you to retrieve the general memory state.
Content providers
A new method, acquireUnstableContentProviderClient() , allows you to access a ContentProviderClient that may be «unstable» such that your app will not crash if the content provider does. It’s useful when you are interacting with content providers in a separate app.
Live Wallpapers
New intent protocol to directly launch the live wallpaper preview activity so you can help users easily select your live wallpaper without forcing them to leave your app and navigate through the Home wallpaper picker.
To launch the live wallpaper picker, call startActivity() with an Intent using ACTION_CHANGE_LIVE_WALLPAPER and an extra that specifies your live wallpaper ComponentName as a string in EXTRA_LIVE_WALLPAPER_COMPONENT .
App stack navigation
Android 4.1 makes it much easier to implement the proper design patterns for Up navigation. All you need to do is add the android:parentActivityName to each element in your manifest file. The system uses this information to open the appropriate activity when the user presses the Up button in the action bar (while also finishing the current activity). So if you declare the android:parentActivityName for each activity, you don’t need the onOptionsItemSelected() method to handle click events on the action bar’s app icon—the system now handles that event and resumes or creates the appropriate activity.
This is particularly powerful for scenarios in which the user enters one of your app’s activities through a «deep dive» intent such as from a notification or an intent from different app (as described in the design guide for Navigating Between Apps). When the user enters your activity this way, your app may not naturally have a back stack of activities that can be resumed as the user navigates up. However, when you supply the android:parentActivityName attribute for your activities, the system recognizes whether or not your app already contains a back stack of parent activities and, if not, constructs a synthetic back stack that contains all parent activities.
Note: When the user enters a deep activity in your app and it creates a new task for your app, the system actually inserts the stack of parent activities into the task. As such, pressing the Back button also navigates back through the stack of parent activities.
When the system creates a synthetic back stack for your app, it builds a basic Intent to create a new instance of each parent activity. So there’s no saved state for the parent activities the way you’d expect had the user naturally navigated through each activity. If any of the parent activities normally show a UI that’s dependent on the user’s context, that context information will be missing and you should deliver it when the user navigates back through the stack. For example, if the user is viewing an album in a music app, navigating up might bring them to an activity that lists all albums in a chosen music genre. In this case, if the stack must be created, it’s necessary that you inform the parent activity what genre the current album belongs to so that the parent can display the proper list as if the user actually came from that activity. To deliver such information to a synthetic parent activity, you must override the onPrepareNavigateUpTaskStack() method. This provides you with a TaskStackBuilder object that the system created in order to synthesize the parent activities. The TaskStackBuilder contains Intent objects that the system uses to create each parent activity. In your implementation of onPrepareNavigateUpTaskStack() , you can modify the appropriate Intent to add extra data that the parent activity can use to determine the appropriate context and display the appropriate UI.
When the system creates the TaskStackBuilder , it adds the Intent objects that are used to create the parent activities in their logical order beginning from the top of the activity tree. So, the last Intent added to the internal array is the direct parent of the current activity. If you want to modify the Intent for the activity’s parent, first determine the length of the array with getIntentCount() and pass that value to editIntentAt() .
If your app structure is more complex, there are several other APIs available that allow you to handle the behavior of Up navigation and fully customize the synthetic back stack. Some of the APIs that give you additional control include:
onNavigateUp() Override this to perform a custom action when the user presses the Up button. navigateUpTo(Intent) Call this to finish the current activity and go to the activity indicated by the supplied Intent . If the activity exists in the back stack, but is not the closest parent, then all other activities between the current activity and the activity specified with the intent are finished as well. getParentActivityIntent() Call this to get the Intent that will start the logical parent for the current activity. shouldUpRecreateTask(Intent) Call this to query whether a synthetic back stack must be created in order to navigate up. Returns true if a synthetic stack must be created, false if the appropropriate stack already exists. finishAffinity() Call this to finish the current activity and all parent activities with the same task affinity that are chained to the current activity. If you override the default behaviors such as onNavigateUp() , you should call this method when you create a synthetic back stack upon Up navigation. onCreateNavigateUpTaskStack Override this if you need to fully control how the synthetic task stack is created. If you want to simply add some extra data to the intents for your back stack, you should instead override onPrepareNavigateUpTaskStack()
However, most apps don’t need to use these APIs or implement onPrepareNavigateUpTaskStack() , but can can achieve the correct behavior simply by adding android:parentActivityName to each element.
Multimedia
Media codecs
The MediaCodec class provides access to low-level media codecs for encoding and decoding your media. You can instantiate a MediaCodec by calling createEncoderByType() to encode media or call createDecoderByType() to decode media. Each of these methods take a MIME type for the type of media you want to encode or decode, such as «video/3gpp» or «audio/vorbis» .
With an instance of MediaCodec created, you can then call configure() to specify properties such as the media format or whether or not the content is encrypted.
Whether you’re encoding or decoding your media, the rest of the process is the same after you create the MediaCodec . First call getInputBuffers() to get an array of input ByteBuffer objects and getOutputBuffers() to get an array of output ByteBuffer objects.
When you’re ready to encode or decode, call dequeueInputBuffer() to get the index position of the ByteBuffer (from the array of input buffers) that you should use to to feed in your source media. After you fill the ByteBuffer with your source media, release ownership of the buffer by calling queueInputBuffer() .
Likewise for the output buffer, call dequeueOutputBuffer() to get the index position of the ByteBuffer where you’ll receive the results. After you read the output from the ByteBuffer , release ownership by calling releaseOutputBuffer() .
You can handle encrypted media data in the codecs by calling queueSecureInputBuffer() in conjunction with the MediaCrypto APIs, instead of the normal queueInputBuffer() .
For more information about how to use codecs, see the MediaCodec documentation.
MediaRouter class allows you to route media channels and streams from the current device to external speakers and other devices. You can acquire an instance of MediaRouter by calling )»>getSystemService( MEDIA_ROUTER_SERVICE) .
Record audio on cue
New method startRecording() allows you to begin audio recording based on a cue defined by a MediaSyncEvent . The MediaSyncEvent specifies an audio session (such as one defined by MediaPlayer ), which when complete, triggers the audio recorder to begin recording. For example, you can use this functionality to play an audio tone that indicates the beginning of a recording session and recording automatically begins so you don’t have to manually synchronize the tone and the beginning of recording.
Timed text tracks
The MediaPlayer now handles both in-band and out-of-band text tracks. In-band text tracks come as a text track within an MP4 or 3GPP media source. Out-of-band text tracks can be added as an external text source via addTimedTextSource() method. After all external text track sources are added, getTrackInfo() should be called to get the refreshed list of all available tracks in a data source.
To set the track to use with the MediaPlayer , you must call selectTrack() , using the index position for the track you want to use.
To be notified when the text track is ready to play, implement the MediaPlayer.OnTimedTextListener interface and pass it to setOnTimedTextListener() .
Audio effects
The AudioEffect class now supports additional audio pre-processing types when capturing audio:
- Acoustic Echo Canceler (AEC) with AcousticEchoCanceler removes the contribution of the signal received from the remote party from the captured audio signal.
- Automatic Gain Control (AGC) with AutomaticGainControl automatically normalizes the output of the captured signal.
- Noise Suppressor (NS) with NoiseSuppressor removes background noise from the captured signal.
You can apply these pre-processor effects on audio captured with an AudioRecord using one of the AudioEffect subclasses.
Note: It’s not guaranteed that all devices support these effects, so you should always first check availability by calling isAvailable() on the corresponding audio effect class.
Gapless playback
You can now perform gapless playback between two separate MediaPlayer objects. At any time before your first MediaPlayer finishes, call setNextMediaPlayer() and Android attempts to start the second player the moment that the first one stops.
Media router. The new APIs MediaRouter, MediaRouteActionProvider, and MediaRouteButton provide standard mechanisms and UI for choosing where to play media.
Camera
Auto focus movement
The new interface Camera.AutoFocusMoveCallback allows you to listen for changes to the auto focus movement. You can register your interface with setAutoFocusMoveCallback() . Then when the camera is in a continuous autofocus mode ( FOCUS_MODE_CONTINUOUS_VIDEO or FOCUS_MODE_CONTINUOUS_PICTURE ), you’ll receive a call to onAutoFocusMoving() , which tells you whether auto focus has started moving or has stopped moving.
Camera sounds
The MediaActionSound class provides a simple set of APIs to produce standard sounds made by the camera or other media actions. You should use these APIs to play the appropriate sound when building a custom still or video camera.
To play a sound, simply instantiate a MediaActionSound object, call load() to pre-load the desired sound, then at the appropriate time, call play() .
Connectivity
Android Beam
Android Beam™ now supports large payload transfers over Bluetooth. When you define the data to transfer with either the new setBeamPushUris() method or the new callback interface NfcAdapter.CreateBeamUrisCallback , Android hands off the data transfer to Bluetooth or another alternate transport to achieve faster transfer speeds. This is especially useful for large payloads such as image and audio files and requires no visible pairing between the devices. No additional work is required by your app to take advantage of transfers over Bluetooth.
The setBeamPushUris() method takes an array of Uri objects that specify the data you want to transfer from your app. Alternatively, you can implement the NfcAdapter.CreateBeamUrisCallback interface, which you can specify for your activity by calling setBeamPushUrisCallback() .
When using the callback interface, the system calls the interface’s createBeamUris() method when the user executes a share with Android Beam so that you can define the URIs to share at share-time. This is useful if the URIs to share might vary depending on the user context within the activity, whereas calling setBeamPushUris() is useful when the URIs to share are unchanging and you can safely define them ahead of time.
Network service discovery
Android 4.1 adds support for multicast DNS-based service discovery, which allows you to find and connect to services offered by peer devices over Wi-Fi, such as mobile devices, printers, cameras, media players, and others that are registered on the local network.
The new package android.net.nsd contains the new APIs that allow you to broadcast your services on the local network, discover local devices on the network, and connect to devices.
To register your service, you must first create an NsdServiceInfo object and define the various properties of your service with methods such as setServiceName() , setServiceType() , and setPort() .
To discover services on the network, implement NsdManager.DiscoveryListener and pass it to discoverServices() .
When your NsdManager.DiscoveryListener receives callbacks about services found, you need to resolve the service by calling resolveService() , passing it an implementation of NsdManager.ResolveListener that receives an NsdServiceInfo object that contains information about the discovered service, allowing you to initiate the connection.
Wi-Fi P2P service discovery
The Wi-Fi P2P APIs are enhanced in Android 4.1 to support pre-association service discovery in the WifiP2pManager . This allows you to discover and filter nearby devices by services using Wi-Fi P2P before connecting to one, while Network Service Discovery allows you to discover a service on an existing connected network (such as a local Wi-Fi network).
To broadcast your app as a service over Wi-Fi so that other devices can discover your app and connect to it, call addLocalService() with a WifiP2pServiceInfo object that describes your app services.
To initiate discover of nearby devices over Wi-Fi, you need to first decide whether you’ll communicate using Bonjour or Upnp. To use Bonjour, first set up some callback listeners with setDnsSdResponseListeners() , which takes both a WifiP2pManager.DnsSdServiceResponseListener and WifiP2pManager.DnsSdTxtRecordListener . To use Upnp, call setUpnpServiceResponseListener() , which takes a WifiP2pManager.UpnpServiceResponseListener .
Before you can start discovering services on local devices, you also need to call addServiceRequest() . When the WifiP2pManager.ActionListener you pass to this method receives a successful callback, you can then begin discovering services on local devices by calling discoverServices() .
When local services are discovered, you’ll receive a callback to either the WifiP2pManager.DnsSdServiceResponseListener or WifiP2pManager.UpnpServiceResponseListener , depending on whether you registered to use Bonjour or Upnp. The callback received in either case contains a WifiP2pDevice object representing the peer device.
Network usage
The new method isActiveNetworkMetered() allows you to check whether the device is currently connected to a metered network. By checking this state before performing intensive network transactions, you can help manage the data usage that may cost your users money and make informed decisions about whether to perform the transactions now or later (such as when the device becomes connected to Wi-Fi).
Accessibility
Accessibility service APIs
The reach of accessibility service APIs has been significantly increased in Android 4.1. It now allows you to build services that monitor and respond to more input events, such as complex gestures using onGesture() and other input events through additions to the AccessibilityEvent , AccessibilityNodeInfo and AccessibilityRecord classes.
Accessibility services can also perform actions on behalf of the user, including clicking, scrolling and stepping through text using performAction and setMovementGranularities . The performGlobalAction() method also allows services to perform actions such as Back, Home, and open Recent Apps and Notifications.
Customizable app navigation
When building an Android app, you can now customize navigation schemes by finding focusable elements and input widgets using findFocus() and focusSearch() , and set focus using setAccessibilityFocused() .
More accessible widgets
The new android.view.accessibility.AccessibilityNodeProvider class allows you to surface complex custom views to accessibility services so they can present the information in a more accessible way. The android.view.accessibility.AccessibilityNodeProvider allows a user widget with advanced content, such as a calendar grid, to present a logical semantic structure for accessibility services that is completely separate from the widget’s layout structure. This semantic structure allows accessibility services to present a more useful interaction model for users who are visually impaired.
Copy and Paste
Copy and paste with intents
You can now associate a ClipData object with an Intent using the setClipData() method. This is especially useful when using an intent to transfer multiple content: URIs to another application, such as when sharing multiple documents. The content: URIs supplied this way will also respect the intent’s flags to offer read or write access, allowing you to grant access to multiple URIs in an the intent. When starting an ACTION_SEND or ACTION_SEND_MULTIPLE intent, the URIs supplied in the intent are now automatically propagated to the ClipData so that the receiver can have access granted to them.
Support for HTML and string styles
The ClipData class now supports styled text (either as HTML or Android styled strings). You can add HTML styled text to the ClipData with newHtmlText() .
Renderscript
Renderscript computation functionality has been enhanced with the following features:
- Support for multiple kernels within one script.
- Support for reading from allocation with filtered samplers from compute in a new script API rsSample .
- Support for different levels of FP precision in #pragma .
- Support for querying additional information from RS objects from a compute script.
- Numerous performance improvements.
New pragmas are also available to define the floating point precision required by your compute Renderscripts. This lets you enable NEON like operations such as fast vector math operations on the CPU path that wouldn’t otherwise be possible with full IEEE 754-2008 standard.
Note: The experimental Renderscript graphics engine is now deprecated.
Animation
Activity launch animations
You can now launch an Activity using zoom animations or your own custom animations. To specify the animation you want, use the ActivityOptions APIs to build a Bundle that you can then pass to any of the methods that start an activity, such as startActivity() .
The ActivityOptions class includes a different method for each type of animation you may want to show as your activity opens:
makeScaleUpAnimation() Creates an animation that scales up the activity window from a specified starting position on the screen and a specified starting size. For example, the home screen in Android 4.1 uses this when opening an app. makeThumbnailScaleUpAnimation() Creates an animation that scales up the activity window starting from a specified position and a provided thumbnail image. For example, the Recent Apps window in Android 4.1 uses this when returning to an app. makeCustomAnimation() Creates an animation defined by your own resources: one that defines the animation for the activity opening and another for the activity being stopped.
Time animator
The new TimeAnimator provides a simple callback mechanism with the TimeAnimator.TimeListener that notifies you upon every frame of the animation. There is no duration, interpolation, or object value-setting with this Animator. The listener’s callback receives information for each frame including total elapsed time and the elapsed time since the previous animation frame.
User Interface
Notifications
In Android 4.1, you can create notifications with larger content regions, big image previews, multiple action buttons, and configurable priority.
Notification styles
The new method setStyle() allows you to specify one of three new styles for your notification that each offer a larger content region. To specify the style for your large content region, pass setStyle() one of the following objects:
Notification.BigPictureStyle For notifications that includes a large image attachment. Notification.BigTextStyle For notifications that includes a lot of text, such as a single email. Notification.InboxStyle For notifications that include a list of strings, such as snippets from multiple emails.
Notification actions
There’s now support for up to two action buttons that appear at the bottom of the notification message, whether your notification uses the normal or larger style.
To add an action button, call addAction() . This method takes three arguments: a drawable resource for an icon, text for the button, and a PendingIntent that defines the action to perfrom.
Priorities
You can now hint to the system how important your notification is to affect the order of your notification in the list by setting the priority with setPriority() . You can pass this one of five different priority levels defined by PRIORITY_* constants in the Notification class. The default is PRIORITY_DEFAULT , and there’s two levels higher and two levels lower.
High priority notifications are things that users generally want to respond to quickly, such as a new instant message, text message, or impending event reminder. Low priority notifications are things like expired calendar events or app promotions.
Controls for system UI
Android 4.0 (Ice Cream Sandwich) added new flags to control the visibility of the system UI elements, such as to dim the appearance of the system bar or make it disappear completely on handsets. Android 4.1 adds a few more flags that allow you to further control the appearance of system UI elements and your activity layout in relation to them by calling setSystemUiVisibility() and passing the following flags:
SYSTEM_UI_FLAG_FULLSCREEN Hides non-critical system UI (such as the status bar). If your activity uses the action bar in overlay mode (by enabling android:windowActionBarOverlay ), then this flag also hides the action bar and does so with a coordinated animation when both hiding and showing the two. SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN Sets your activity layout to use the same screen area that’s available when you’ve enabled SYSTEM_UI_FLAG_FULLSCREEN even if the system UI elements are still visible. Although parts of your layout will be overlayed by the system UI, this is useful if your app often hides and shows the system UI with SYSTEM_UI_FLAG_FULLSCREEN , because it avoids your layout from adjusting to the new layout bounds each time the system UI hides or appears. SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION Sets your activity layout to use the same screen area that’s available when you’ve enabled SYSTEM_UI_FLAG_HIDE_NAVIGATION (added in Android 4.0) even if the system UI elements are still visible. Although parts of your layout will be overlayed by the navigation bar, this is useful if your app often hides and shows the navigation bar with SYSTEM_UI_FLAG_HIDE_NAVIGATION , because it avoids your layout from adjusting to the new layout bounds each time the navigation bar hides or appears. SYSTEM_UI_FLAG_LAYOUT_STABLE You might want to add this flag if you’re using SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN and/or SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION to ensure that when you call fitSystemWindows() on a view that the bounds defined remain consistent with regard to the available screen space. That is, with this flag set, fitSystemWindows() will behave as if the visibility of system UI elements is unchanged even after you hide all system UI.
For more discussion about the other related system UI flags, read about those added in Android 4.0.
Remote views
GridLayout and ViewStub are now remotable views so you can use them in layouts for your app widgets and notification custom layouts.
Font families
Android 4.1 adds several more variants of the Roboto font style for a total of 10 variants, and they’re all usable by apps. Your apps now have access to the full set of both light and condensed variants.
The complete set of Roboto font variants available is:
- Regular
- Italic
- Bold
- Bold-italic
- Light
- Light-italic
- Condensed regular
- Condensed italic
- Condensed bold
- Condensed bold-italic
You can apply any one of these with the new fontFamily attribute in combination with the textStyle attribute.
Supported values for fontFamily are:
- «sans-serif» for regular Roboto
- «sans-serif-light» for Roboto Light
- «sans-serif-condensed» for Roboto Condensed
You can then apply bold and/or italic with textStyle values «bold» and «italic» . You can apply both like so: android:textStyle=»bold|italic» .
You can also use Typeface.create() . For example, Typeface.create(«sans-serif-light», Typeface.NORMAL) .
Input Framework
Multiple input devices
The new InputManager class allows you to query the set of input devices current connected and register to be notified when a new device is added, changed, or removed. This is particularly useful if you’re building a game that supports multiple players and you want to detect how many controllers are connected and when there are changes to the number of controllers.
You can query all input devices connected by calling getInputDeviceIds() . This returns an array of integers, each of which is an ID for a different input device. You can then call getInputDevice() to acquire an InputDevice for a specified input device ID.
If you want to be informed when new input devices are connected, changed, or disconnected, implement the InputManager.InputDeviceListener interface and register it with registerInputDeviceListener() .
Vibrate for input controllers
If connected input devices have their own vibrate capabilities, you can now control the vibration of those devices using the existing Vibrator APIs simply by calling getVibrator() on the InputDevice .
Permissions
The following are new permissions:
READ_EXTERNAL_STORAGE Provides protected read access to external storage. In Android 4.1 by default all applications still have read access. This will be changed in a future release to require that applications explicitly request read access using this permission. If your application already requests write access, it will automatically get read access as well. There is a new developer option to turn on read access restriction, for developers to test their applications against how Android will behave in the future. android.Manifest.permission.READ_USER_DICTIONARY Allows an application to read the user dictionary. This should only be required by an IME, or a dictionary editor like the Settings app. READ_CALL_LOG Allows an application to read the system’s call log that contains information about incoming and outgoing calls. WRITE_CALL_LOG Allows an application to modify the system’s call log stored on your phone android.Manifest.permission.WRITE_USER_DICTIONARY Allows an application to write to the user’s word dictionary.
Device Features
Android 4.1 includes a new feature declaration for devices that are dedicated to displaying the user interface on a television screen: FEATURE_TELEVISION . To declare that your app requires a television interface, declare this feature in your manifest file with the element:
This feature defines «television» to be a typical living room television experience: displayed on a big screen, where the user is sitting far away and the dominant form of input is be something like a d-pad, and generally not through touch or a mouse/pointer-device.
Источник