Build number android что это

Перевод «build number» на русский

Mobile firmware was released under the build number 21.1.A..163, and is already available for download over the air.

Мобильная прошивка вышла под номером сборки 21.1.A..163, и уже доступно для скачивания «по воздуху».

Currently this section contains only a description of the changes in Windows 10 build number 10586.104, which was released a few hours ago.

В настоящее время в этом разделе содержится лишь описание изменений в Windows 10 с номером сборки 10586.104, которая была выпущена несколько часов назад.

Despite the fact that they appear within a few days, the build number they match.
Несмотря на то, что они появляются с разницей в несколько дней, номер сборки у них совпадает.
The beta version of Android 6.0.1 for these devices also carried the same build number.
Бета-версия Android 6.0.1 для этих устройств включает в себя тот же номер сборки.

You can enable Developer Options on Android by going to the About section and tapping the build number five times consecutively.

Вы можете включить параметры разработчика на Android, перейдя в раздел «О программе» и последовательно нажимая номер сборки пять раз подряд.

Apple released an updated iOS version 12.1.2 with the new build number 16C104.
Сегодня Apple выпустила обновлённую версию iOS 12.1.2 с новым номером сборки 16C104.

The build number for the Windows operating system that is installed on the computer that the job ran on.

Номер сборки ОС Windows, установленной на компьютере, на котором запущено задание.

Because the updated macOS 10.14.6 doesn’t have a lot of changes, Apple didn’t change the build number.

Так как обновленная macOS 10.14.6 не несет в себе большого количества изменений, компания Apple не стала менять номер сборки.

The beta arrives as build number 12F5047f.
Последняя бета-версия проходит под номером сборки 12F5047f.

All available information will be reflected in the command window: the version of the operating system, the build number, version updates and more.

Все доступная информация будет отражена в окне командной строки: версия операционной системы «Windows», номер сборки, версия обновления и многое другое.

After upgrading, the build number of Windows 10 changes to 14393.2457.
После обновления номер сборки Windows 10 меняется на 14393.2273
The RTM’s build number jumped to 6000 to reflect Vista’s internal version number, NT 6.0.
Номер сборки RTM подскочил до 6000, чтобы отобразить внутренний номер версии Vista, NT 6.0.

The OS version section indicates the specific build number of the release (for example, «8.0.0000.0» or «8.0.10517.150»).

В разделе Версия ОС указан номер сборки выпуска (например, «8.0.0000.0» или «8.0.10517.150»).
The latest (and the last) iOS 8 beta has a build number 12A365.
Самая свежая (и последняя) «бета» iOS 8 имеет номер сборки 12A365.
Windows 8 RTM build coming in July, build number to be 8500
Windows 8 RTM будет выпущена во второй половине июля и получит номер сборки 8500

The Redmond-based firm clarified the new update, that brings the build number of the software to 17763.316, does not bring new features.

Фирма из Редмонда уточнила, что новое обновление, которое приносит номер сборки программного обеспечения до 17763.316, не приносит новых функций.

The new build number is 13B5119e.
Вторая «бета» iOS 9 имеет номер сборки 13B5119e.
The new update from Microsoft takes the April 2018 Update to build number 17134.590.
Новое обновление от Microsoft использует обновление за апрель 2018 года, номер сборки 17134,590.
Возможно неприемлемое содержание

Примеры предназначены только для помощи в переводе искомых слов и выражений в различных контекстах. Мы не выбираем и не утверждаем примеры, и они могут содержать неприемлемые слова или идеи. Пожалуйста, сообщайте нам о примерах, которые, на Ваш взгляд, необходимо исправить или удалить. Грубые или разговорные переводы обычно отмечены красным или оранжевым цветом.

Зарегистрируйтесь, чтобы увидеть больше примеров. Это просто и бесплатно
Ничего не найдено для этого значения.
Предложить пример
Больше примеров Предложить пример

Новое: Reverso для Windows

Переводите текст из любого приложения одним щелчком мыши .

Скачать бесплатно
Перевод голосом, функции оффлайн, синонимы, спряжение, обучающие игры

Результатов: 96 . Точных совпадений: 96 . Затраченное время: 144 мс

Помогаем миллионам людей и компаний общаться более эффективно на всех языках.

«Build number» в андроид Java

Подскажите, как в андроид Java получить версию прошивки «Build number», которая отображается в «О телефоне». Нигде не могу найти.

Отслеживать
задан 30 апр 2019 в 6:57
11 1 1 бронзовый знак
30 апр 2019 в 7:06
Спасибо! Точный метод: Build.DISPLAY
30 апр 2019 в 7:47

0

Сортировка: Сброс на вариант по умолчанию

Знаете кого-то, кто может ответить? Поделитесь ссылкой на этот вопрос по почте, через Твиттер или Facebook.

• java
• android

Важное на Мете

Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.10.27.43697

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Очень быстро понимаем Android Build Flavors

Build Flavors — технология, позволяющая собирать несколько вариантов приложения с общей кодовой базой и общими ресурсами.

Причина появления статьи — запутанность и излишняя сложность для такой простой темы официальной документации. В короткий пост моего канала об Android-разработке оно не влезло, поэтому почти полноценная статья.

Зачем используют Flavors

Flavors — ваш выбор, если:

• вам нужно 2 версии приложения — с базовым и расширенным функционалом;
• вам нужно несколько версий приложения с разным оформлением или частично отличающимся функционалом.

Flavors — не лучший выбор, если вам нужно просто иметь несколько вариантов сборки приложения (с включенной и отключенной обфускацией, например). В этом случае смотрите в сторону Build Types (дефолтные: debug, release)

Общая концепция

Идея очень схожа с модным сейчас Kotlin Multiplatform — у вас есть общий код и ресурсы, лежащие в папке src/main, а также код и ресурсы, которые определены отдельно для каждой версии (каждого flavor).

Например

Например, у вас может быть два приложения про животных — про коней и про рыб. Функционал обоих — одна Activity, которая отображает картинку животного.

Вы создаете два Flavors — AnimalHorse и AnimalFish

В папке src/main/java будет лежать код самой Activity, которая выводит drawable с именем animal (R.drawable.animal). А в папках src/animalHorse/res/drawable и src/animalFish/res/drawable будут лежать картинки лошади и рыбы соответственно. При этом они должны иметь одинаковое имя = animal.

Когда вы собираете apk, в него кладутся ресурсы только для выбранного Flavor — остальные просто игнорируются.

Практика

Пошагово создадим и наполним два Flavors, например, animalHorse и animalFish.

Создаем Flavors

В файле build.gradle (уровня module) необходимо объявить flavorDimensions — группу, объединяющую наши flavors (обязательно):

android

Дальше добавляем в блок android блок productFlavors, объявляем наши flavors и обязательно прописываем, к какой группе они относятся.

android < . flavorDimensions "animals" productFlavors < animalHorse < dimension "animals" >animalFish < dimension "animals" >> . >

Пересобираем проект (Build -> Rebuild Project).

Заходим в раздел Build -> Select Build Variants. И видим, что появилось 4 варианта сборки:

• animalHorseDebug
• animalHorseRelease
• animalFishDebug
• animalFishRelease

То есть у нас всегда будет n = Build Types * Build Flavors вариантов сборки проекта.

Можно выбрать любой из них, после чего студия сделает rebuild, чтобы собрать проект только из тех файлов, которые относятся к выбранной версии.

Переопределяем applicationId

Во-первых, уточню, что applicationId != packageName (packageName = имя папок, в которых лежит проект. у всех flavors должен быть одинаковый packageName). Пост об этом в моем tg-канале c картинками: https://t.me/dolgo_polo_dev/45

Во-вторых, вы можете либо переопределить applicationId для каждого flavors полностью, либо можете добавить applicationIdSuffix для каждого flavor.

android < defaultConfig < applicationId "my.app" >. flavorDimensions "animals" productFlavors < animalHorse < dimension "animals" applicationId "my.app.horse" >animalFish < dimension "animals" applicationIdSuffix ".fish" >> . >

Во втором варианте applicationId = applicationId (из блока defaultConfig) + applicationIdSuffix

Создаем разделы с кодом

На данный момент (10.12.2021) Android Studia сам не умеет создавать папки по объявленным Flavors, поэтому создадим их вручную.

p.s. не обязательно создавать папки и файлы, которые не собираетесь переопределять

1. Откройте структуру проекта в режиме Project.
2. Создайте в папке app/src папки animalHorse и animalFish.
3. В созданных папках создайте папки java/my/app/com (если packageName != «my.app.com», то папки внутренние папки будут называться по-другому), res/layout, res/drawable. (необязательно)
4. В папках animalHorse и animalFish создайте файл AndroidManifest.xml (обязательно)

Готово. Теперь вы можете писать общий код в папке src/main и разный код в папках src/animalHorse и src/animalFish.

Например, вы можете в общем коде хранить Activity, которая выводит на весь экран Fragment с именем FragmentListAnimals. А сам фрагмент определить в обоих версиях приложения отдельно — создайте класс FragmentListAnimals и в папке src/animalHorse/java/my/app/com/fragments, и в папке src/animalFish/java/my/app/com/fragments.

Названия папок и файлов (классов) и их иерархия в папках src/main/java и src/animalHorse/java и src/animalFish/java должны совпадать.

Об AndroidManifest

Как писалось выше, AndroidManifest.xml должен быть создан во всех трех папках — src/main, src/animalFish, src/animalHorse. При этом манифесты в папках src/animalFish и src/animalHorse могут быть пустые (содержать только тег ).

Но если вам, например, нужно разрешение на доступ к камере только в одной версии приложения, то можете отредактировать манифест в нужной папке. При сборке приложения этот манифест будет смерджен с основным манифестом, лежащем в scr/main.

Правила соединения манифестов хорошо описаны тут.

Создание BuildConfig переменных

Вы можете создавать константы, которые меняются в зависимости от выбранной сборки. Для этого в gradle-файле создайте buildConfigField для обоих flavor:

android < defaultConfig < applicationId "my.app" >. flavorDimensions "animals" productFlavors < animalHorse < dimension "animals" applicationIdSuffix ".horse" buildConfigField "String", "URL", "\"https://animals.horse.ru\"" >animalFish < dimension "animals" applicationId "my.app.fish" buildConfigField "String", "URL", "\"https://animals.fish.ru\"" >> . >

Теперь в любом месте кода вы можете сослаться на эту константу:

 private fun initRetrofit()

Советы и возможные трудности

1. Скорее всего, начав работать с flavors, вы увидите, насколько ваш код недостаточно разбит на классы. И вам придется провести приличное код-ревью, которое позволит вам переопределять минимум кода для каждой из версий приложения.
2. Очевидный фокап, словленный мной — когда будете создавать папки для каждой версии, убедитесь, что создали вложенные папки, а не одну. Если пакет называется my.app.com, то должны быть папки my -> app -> com, а не одна с названием my.app.com.
3. Используйте Dagger/Hilt для внедрения зависимостей. Так будет намного легче упорядочивать разные реализации для разных версий.
4. Полный список build-параметров, которые можно переопределить для каждого flavor, можно найти в оф. документации (например, minSdkVersion, versionCode. )

А более короткие посты про мобильную разработку с картинками можно почитать туть.

• Разработка мобильных приложений
• Разработка под Android
• Тестирование мобильных приложений
• Дизайн мобильных приложений

Build number android что это

В статье приведен перевод статей [1, 2], посвященных управлению версиями приложения Android, и работе приложения на разных версиях операционной системы Android. Все непонятные термины и сокращения ищите в Словарике [3].

Управление версией приложения является критически важным аспектом для обновления приложения и для стратегии его поддержки в будущем. Это важно потому что:

• Пользователям нужна соответствующая информация о версии приложения, которая установлена на их устройствах, и о доступности обновлений версии приложения для существующей инсталляции.
• Другие приложения — включая другие приложения, которые Вы публикуете в как комплект приложений — нуждаются в опросе системы для версии Вашего приложения, чтобы определить совместимость и идентифицировать зависимости (от API и библиотек).
• Сервисы, через которые Вы публикуете приложение (или приложения) могут также нуждаться в опросе Вашего приложения на его версию, чтобы можно было отобразить эту версию для пользователей. Сервис публикации может также нуждаться в проверки версии приложения, чтобы определить совместимость и установить взаимосвязи для апгрейда или довнгрейда.

Система Android не использует информацию об версии приложения для принудительного ограничения на апгрейд, довнгрейд, или на ограничение совместимости приложений сторонних производителей. Вместо этого Вы (как разработчик) отвечаете за ограничения, связанные с версиями приложения, или за информирование об этом пользователей. Однако система Android обеспечивает совместимость приложения с системой в соответствии с атрибутом minSdkVersion, который указан в манифесте. Этот атрибут позволяет приложению указать минимальный уровень системного API, с которым совместимо приложение. Дополнительную информацию см. ниже android:minSdkVersion в разделе «Как указать требования приложения к уровню (версии) API Android».

[Установка версии приложения (Application Version)]

Чтобы задать информацию о версии для Вашего приложения, нужно установить атрибуты в файле манифеста приложения (AndroidManifest.xml, секция manifest). Доступно 2 атрибута, для которых обязательно нужно назначить значения:

• android:versionCode — целое число, которое представляет версию кода приложения относительно других версий. Значение целого числа установлено так, чтобы другие приложения могли программно вычислить его, например для проверки взаимосвязи апгрейда или довнгрейда. Вы можете установить значение в любое целое число, какое захотите, однако нужно помнить, что обновленное приложение должно иметь последовательно увеличенный номер версии. Система не принуждает к такому поведению, однако увеличение номера версии с новым релизом является нормой.

Обычно Вы должны сделать первый релиз приложения с versionCode установленным в 1, и затем монотонно увеличивать это значение с каждым новым релизом, независимо от статуса, который имеет релиз: major или minor. Это не означает, что значение атрибута android:versionCode должно быть строго подобно версии релиза, которую видит пользователь (см. далее атрибут android:versionName). Приложения и сервисы публикации приложений не должны отображать значение атрибута android:versionCode для пользователей.

• android:versionName — строковое значение, которое представляет версию релиза кода приложения, которая должна быть показана пользователям.

Значение является строкой, в которой Вы можете описать версию приложения как < major >.< minor >.< point >, или любым другим способом, выражая текстовым идентификатором абсолютную или относительную версию приложения.

Как и атрибут android:versionCode, система Android не использует android:versionName для внутреннего использования, кроме того как отобразить это значение для пользователей. Сервисы публикации приложений могут также прочитать значение android:versionName для того, чтобы отобразить её для пользователей.

Оба этих элемента нужно задать в секции < manifest >файла манифеста приложения. Пример:

  < manifestxmlns:android="http://schemas.android.com/apk/res/android" package="com.example.package.name" android:versionCode="2" android:versionName="1.1" >  < applicationandroid:icon="@drawable/icon" android:label="@string/app_name" > . < /application > < /manifest > 

Обратите внимание, что в этом примере android:versionCode показывает, что текущий файл .apk содержит второй релиз кода приложения, который соответствует минорной последующей версии релиза 1, как показано в строке android:versionName.

Рабочее окружение Android предоставляет API, позволяющее приложениям опросить систему для получения информации версии приложения. Чтобы получить информацию версии, приложения используют метод getPackageInfo(java.lang.String, int) объекта PackageManager.

[Как указать требования приложения к уровню (версии) API Android]

Если Ваше приложение требует определенную минимальную версию платформы Android, где приложение должно работать, или если приложение разработано для поддержки определенного диапазона версий платформ Android, то Вы можете указать эти требования к версиям в виде идентификаторов API Level в файле манифеста приложения. Если сделать так, то это обеспечит то, что Ваше приложение может быть установлено только на устройствах, на которых работает совместимая версия системы Android.

Чтобы указать требования к API Level, добавьте тег < uses-sdk > в файл манифеста приложения, и укажите в нем один или несколько этих атрибутов:

• android:minSdkVersion — минимальное значение версии платформы Android, на которой приложение будет работать. Значение версии указано в виде цифрового идентификатора API Level.
• android:targetSdkVersion — указывает число API Level, для которого приложение разработано. В некоторых случаях это позволит приложению использовать элементы манифеста и определять поведение по заданному уровню целевого API Level, вместо того, чтобы ограничиваться использованием только определенного минимального уровня API Level.
• android:maxSdkVersion — максимальное значение версии платформы Android, на котором приложение может работать. Внимательно прочтите документацию по секции < uses-sdk >(см. далее) перед использованием этого атрибута.

При подготовке к установке приложения система проверяет эти атрибуты и сравнивает их с версией системы. Если значение android:minSdkVersion больше версии системы, то установка приложения будет прервана. Точно также система установить Ваше приложение только в том случае, если android:maxSdkVersion совместим с версией платформы.

Если Вы не укажете эти атрибуты в манифесте, то система предположит, что Ваше приложение совместимо со всеми версиями платформы, и также нет ограничения на максимальный API Level.

Чтобы указать минимальную требуемую версию платформы для Вашего приложения, добавьте секцию < uses-sdk >дочерней к секции < manifest >, и затем добавьте атрибут android:minSdkVersion и его значение.

[Подробнее о секции манифеста ]

Секция uses-sdk появилась начиная с API Level 1 (т. е. сразу, начиная с самых старых версий Android). Синтаксис секции следующий:

 < uses-sdkandroid:minSdkVersion="integer" android:targetSdkVersion="integer" android:maxSdkVersion="integer" / > 

Секция uses-sdk позволяет Вам выражать совместимость приложения Android с одной или большим количеством версий платформ (операционных систем) Android. Эта совместимость определяется посредством чисел API Level, которая указывается в атрибутах секции minSdkVersion, targetSdkVersion, maxSdkVersion. Версия платформы может (которая соответствует определенному числу API Level) может различаться на разных устройствах Android. Указанные API Level, представленные приложением в этой секции, сравниваются с API Level системы, на которой работает (или устанавливается) приложение, и на основе этого сравнения принимаются определенные решения по инсталляции программы или её работе.

Несмотря на имя секции uses-sdk, эта секция на самом деле используется для определения API Level, но не номер версии SDK платформы Android. API Level всегда задается одиночным целым числом. Вы не можете получить из связанной с ним текстовой версии Android, кроме как получить такое соответствие из таблицы API Level (см. [4]). К примеру, API level 16 относится к версиям Android 4.1, Android 4.1.1, Android 4.1.2. Теперь рассмотрим назначение атрибутов minSdkVersion, targetSdkVersion, maxSdkVersion.

android:minSdkVersion число, обозначающее минимальный API Level, который требуется для установки, запуска и работы приложения. Система Android не позволит пользователю установить приложение, если API Level системы меньше значения, указанного в этом атрибуте. Вы всегда должны указывать этот атрибут в секции uses-sdk файла AndroidManifest.xml.

Предостережение: если Вы не укажете этот атрибут, то система предположит его значение по умолчанию «1», что означает совместимость Вашего приложения со всеми без исключения версиями операционной системы Android. Если Ваше приложение несовместимо со всеми версиями (например, оно использует API, представленное впервые на API Level 3), и Вы не укажете правильно minSdkVersion, то при установке на систему с уровнем API Level меньше 3 приложение будет завершаться с ошибкой при попытке доступа к недоступному API. По этой причине обязательно объявляйте подходящий API Level в атрибуте minSdkVersion.

android:targetSdkVersion этот атрибут представлен начиная с API Level 4. Это целое число, обозначающее API Level, для которого приложение предназначено (target, что означает цель). Если этот атрибут не установлен, то его значение по умолчанию равно minSdkVersion.

Этот атрибут информирует систему, что Вы тестировали приложение с этим API Level, и система не должна позволять любое поведение совместимости (compatibility behaviors, т. е. эмуляцию вызовов API, обеспечивающих специальную дополнительную программную обработку некоторых вызовов API), чтобы поддержать прямую совместимость приложения с целевой версией системы. Приложение все еще может работать на более старых версиях (до версий, не меньших minSdkVersion).

Поскольку Android развивается с каждой новой версией, то некоторые поведения и даже внешний вид приложения может измениться. Однако, если API level платформы выше, чем версия, указанная в targetSdkVersion приложения, система может включить обработки совместимости (compatibility behaviors), чтобы обеспечить работоспособность Вашего приложения так, как Вы этого ожидали. Вы можете запретить такие обработки совместимости, если укажете targetSdkVersion равным API level платформы Android, на которой приложение работает. Например, установка этого значения в «11» или более высокое значение позволит системе установить новую тему оформления по умолчанию (Holo) для Вашего приложения при работе на Android 3.0 или более новой, и также запретит режим совместимости экрана, когда программа будет работать на больших экранах (потому что поддержка API level 11 неявно подразумевает поддержку больших экранов).

Имеется много разновидностей обеспечения совместимости (compatibility behaviors), которые система может разрешить, базируясь на значении этого атрибута. Некоторые из этих обработок (поведений, behaviors) описаны в соответствующей документации версии платформы, см. Build.VERSION_CODES.

Чтобы обеспечить соответствие Вашего приложения каждому новому релизу Android, Вы должны увеличивать значение этого атрибута, чтобы оно соответствовало последнему API level, и затем необходимо полностью протестировать поведение приложения на этой новой версии платформы.

android:maxSdkVersion этот атрибут представлен начиная с API Level 4. Это целое число, обозначающее максимальный API Level, на котором приложение может работать.

На версиях Android 1.5, 1.6, 2.0 и 2.0.1 система проверяет значение этого атрибута, когда инсталлируется приложение, и когда приложение проверяется на совместимость после обновления системы. В любом случае, если атрибут приложения maxSdkVersion меньше API Level системы, то установка приложения будет запрещена. При проверке приложения на совместимость после обновления системы такой случай соответствует полному удалению приложения с устройства. Для иллюстрации того, как этот атрибут может повлиять на приложение после обновления системы, рассмотрим пример.

Приложение декларировало maxSdkVersion=»5″ в своем манифесте, и было опубликовано на Google Play. Пользователь устройства Android 1.6 (API Level 4) загрузил и установил это приложение. После нескольких недель пользователь принял сообщение от системы over-the-air с предложением обновить систему до уровня Android 2.0 (API Level 5). После установки этого обновления система проверила атрибут приложения maxSdkVersion, и разрешила дальнейшее использование этого приложения. Приложение после этого работало нормально. Однако через некоторое время устройство приняло другое обновление системы Android 2.0.1 (API Level 6). После обновления система не разрешает работу приложения, так как API Level системы (6) теперь выше, чем максимальный уровень, который может поддержать приложение (5). Система делает приложение невидимым для пользователя, и удаляет его из устройства.

Предупреждение: использование этого атрибута не рекомендуется. Во-первых, нет никакой потребности установить этот атрибут как средство блокирования развертывания Вашего приложения на новые версии платформы Android по мере их появления. Для Android декларируется полная обратная совместимость старых приложений для новых версий Android. Ваше приложение должно работать должным образом на всех новых версиях, если оно использует только стандартное API и следует лучшим правилам и практикам разработки. Во-вторых нужно помнить, что применение этого атрибута приведет к автоматическому удалению Вашего приложения с устройств пользователя, которые обновят свою систему на более высокий API Level, чем указано в атрибуте. Большинство устройств, на которых вероятно будет установлено Ваше приложение, получают периодические обновления системы на лету, по воздуху (over the air), так что Вы должны учитывать этот эффект перед тем, как установить этот атрибут для своего приложения.

Будущие версии Android (вне Android 2.0.1) больше не будут проверять maxSdkVersion и принудительно применять его значение при установке или проверке совместимости приложения. Однако Google Play продолжит использовать этот атрибут как фильтр при предоставлении приложений, доступных для закачки пользователям.

[Пример установки версии приложения при создании проекта в Eclipse]

В Eclipse при создании проекта запускается мастер, который на первом экране позволяет настроить параметры, касающиеся версии приложения.

Поле Minimum Required SDK определяет значение атрибута android:minSdkVersion будущего приложения. Здесь желательно указать версию достаточно популярной платформы, которая возможно уже несколько устарела.

Поле Target SDK задает атрибут android:targetSdkVersion. Укажите здесь версию системы, с которой Вы тестировали Ваше приложение. К примеру, Вы отлаживаете программу на версии Android 4.1.2, тогда в выпадающем списке Target SDK нужно выбрать API 16: Android 4.1 (Jelly Bean).

Поле Compile With задает версию SDK, на котором Ваше приложение будет скомпилировано. Задайте здесь максимальную (самую свежую) на текущий момент версию системы Android.

[Ссылки]

1. Versioning Your Applications site:developer.android.com .
2. uses-sdk site:developer.android.com .
3. Словарик Android.
4. Что такое API Level?