Какое api соответствует android 4.1 1. «Сердце робота»: Как использовать системный API Android в личных целях. Что такое уровень API

Android SDK включает в себя разнообразные библиотеки, документацию и инструменты, которые помогают разрабатывать мобильные приложения для платформы Android .

• API Android SDK - APIбиблиотеки Android, предоставляемые для разработки приложений.
• Документация SDK- включает обширную справочную информацию, детализирующую, что включено в каждый пакет и класс и как это использовать при разработке приложений.
• AVD (Android Virtual Device)- интерактивный эмулятор мобильного устройства Android. Используя эмулятор, можно запускать и тестировать приложения без использования реального Androidycтpoйcтвa.
• Development Tools - SDK включает несколько инструментальных средств для разработки, которые позволяют компилировать и отлаживать создаваемые приложения.
• Sample Code - Android SDK предоставляет типовые приложения, которые демонстрируют некоторые из возможностей Android, и простые программы, которые показывают, как использовать индивидуальные особенности API в вашем коде.

Версии SDK и Android API Level

Перед началом разработки приложений для Android полезно понять общий подход платформы к управлению изменением API. Также важно понять Android API Level (Идентификатор уровня API) и его роль в обеспечении совместимости вашего приложения с устройствами, на которых оно будет устанавливаться.

Уровень API - целочисленное значение, которое однозначно определяет версию API платформы Android. Платформа обеспечивает структуры API, которые приложения могут использовать для взаимодействия с системой Android. Каждая следующая версия платформы Android может включать обновления API.

Обновления API-структуры разработаны так, чтобы новый API оставался совместимым с более ранними версиями API. Таким образом, большинство изменений в API является совокупным и вводит новые функциональные возможности или исправляет предыдущие. Поскольку часть API постоянно обновляется, устаревшие API не рекомендуются к использованию, но не удаляются из соображений совместимости с имеющимися приложениями.

Уровень API, который использует приложение для Android, определяется целочисленным идентификатором, который указывается в файле конфигурации каждого Android-приложения.

Таблица определяет соответствие уровня API и версии платформы Android.

Соответствие версии платформы и уровня АРI

Инструменты для разработки и отладки приложений

Кроме эмулятора, SDK также включает множество других инструментальных средств для отладки и установки создаваемых приложений. Если вы разрабатываете приложения для Android с помощью IDE Eclipse, многие инструменты командной строки, входящие в состав SDK, уже используются при сборке и компиляции проекта. Однако кроме них SDK содержит еще ряд полезных инструментов для разработки и отладки приложений:

• android - важный инструмент разработки, запускаемый из командной строки, который позволяет создавать, удалять и конфигурировать виртуальные устройства, создавать и обновлять Androidпроекты (при работе вне среды Eclipse) и обновлять Android SDK новыми платформами, дополнениями и документацией;
• Dalvik Debug Monitor Service (DDMS) - интегрированный с Dalvik Virtual Machine, стандартной виртуальной машиной платформы Android, этот инструмент позволяет управлять процессам и на эмуляторе ил и устройстве, а также помогает в отладке приложений. Вы можете использовать этот сервис для завершения процессов, выбора определенного процесса для отладки, генерирования трассировочных данных, просмотра "кучи" или информации о пото ках, делать скриншоты эмулятора ил и устройства и многое другое;
• Hierarchy Viewer - визуальный инструмент, который позволяет отлаживать и оптимизировать пользовательский интерфейс разрабатываемого приложения. Он показывает визуальное дерево иерархии представлений, анализирует быстродействие перерисовки графических изображений на экране и может выполнять еще много других функций для анализа графического интерфейса приложений;
• Layoutopt - инструмент командной строки, который помогает оптимизировать схемы разметки и иерархии разметок в создаваемом приложении. Необходим для решения проблем при создании сложных графических интерфейсов, которые могут затрагивать производительность приложения;
• Draw 9-patc h - графический редактор, который позволяет легко создавать NinеРаtсhграфику для графического интерфейса разрабатываемых приложений;
• sqlite3 - инструмент для доступа к файлам данных SQLite, созданных и используемых приложениями для Android;
• Traceview - этот инструмент выдает графический анализ трассировочных логов, которые можно генерировать из приложений;
• mksdcard - инструмент для создания образа диска, который вы можете использовать в эмуляторе для симуляции наличия внешней карты памяти (например, карты SD).
• Наиболее важный из них- эмулятор мобильного устройства , однако в состав SDK входят и другие инструменты для отладки, упаковки и инсталляции ваших приложений на эмулятор.

Android Virtual Device

Android Virtual Device (Виртуальное устройство Android )- это эмулятор, который запускается на обычном компьютере. Эмулятор используется для проектирования, отладки и тестирования приложений в реальной среде выполнения.

Прежде чем вы сможете запускать Androidэмулятор устройства, необходимо создать Android Virtual Device (AVD) . AVD определяет системное изображение и параметры настройки устройства, используемые эмулятором.

Создавать эмулятор устройства можно двумя способами:

1. В командной строке утилитой android, доступной в каталоге, куда вы установили Android SDK, в папке tools.
2. Визуально с помощью Android SDK and AVD Manager в IDE Eclipse , выбрав пункт меню Window | Android SDK and AVD Manager. Появится окно Android SDK and AVD Manager, с помощью которого можно создавать и конфигурировать эмуляторы мобильного устройства, а также загружать обновления Android SDK.

Окно Android SDK and AVD Manager также появится, если в командной строке вызвать android.exe без параметров.

iAndroid SDK and AVD Manager

Окно Android SDK and AVD Manager

В правой части панели List of existing Android Virtual Devices нажмите кнопку New, при этом откроется окно Create new AVD.

В этом окне задайте нужную конфигурацию для создаваемого эмулятора устройства:

• Name - имя создаваемого устройства;
• Target - версия Android SDK, поддерживаемая устройством. Устройство имеет обратную совместимость со старыми версиями SDK, т. е. если выбрана версия Android 2.0, эмулятор будет поддерживать версии SDK 1.6, 1.5, 1.1;
• SD Card - устанавливает виртуальную карту SD;
• Skin -тип экрана устройства. Загружаемая платформа включает ряд скинов для эмулятора, которые можно использовать для моделирования работы приложения в устройствах с разными размерами и разрешением экрана. Набор скинов для эмулятора в зависимости от установленной версии SDK, указанной в поле Target, содержит различные типы и размеры экрана, например:
• HVGA (Halfsize VGA Video Graphics Array ), размер 320x480, средняя плотность, нормальный экран;
• WVGA800 (Wide Video Graphics Array ), размер 480x800, высокая плотность, нормальный экран;
• WVGA854 (Wide Video Graphics Array ), 480x854, высокая плотность, нормальный экран;
• QVGA (Quarter Video Graphics Array ), размер 240x320, низкая плотность, малый экран;
• WQVGA (Wide Quarter Video Graphics Array ), размер 240x400, низкая плотность, нормальный экран;

• Hardware - имитация оборудования, установленного на устройстве. При необходимости нажатием кнопки New можно вызвать окно для добавления дополнительного виртуального оборудования.

Окно для добавления дополнительного виртуального оборудования

После задания конфигурации и нажатия кнопки Create AVD менеджер создаст новое виртуальное устройство, название и версия API которого появятся в списке List of existing Android Virtual Devices .

Для более тонкой настройки лучше использовать инструмент командной строки andnoid.exe. Он имеет более широкие возможности, чем визуальный AVD Мапа9ег, и удобен для конфигурации сети, портов и виртуального оборудования эмулятора. К сожалению, изза ограниченного объема книги нет возможности рассмотреть подробнее этот инструмент.

В зависимости от поддерживаемой версии API внешний вид виртуального устройства будет отличаться.

Окно эмулятора оформлено в виде телефона с дополнительной клавиатурой. После загрузки системы появляется Home screen - рабочий стол Android. Для доступа к нему используется кнопка со значком домика. Эмулятор также имитирует сенсорный экран реального мобильного устройства- в эмуляторе на экран нажимают левой кнопкой мыши.

В эмуляторе два виртуальных рабочих стола, перемещение по которым осуществляется с помощью кнопок со стрелками на навигационной панели устройства или передвижением курсора при нажатой левой кнопке мыши (в реальном устройстве- перемещая палец по экрану). Кроме ярлыков программы на рабочем столе можно размещать виджеты.

Внешний вид AVD версии 1.5

Внешний вид AVD версии 2.0

Для тестирования внешнего вида создаваемого приложения при разных положениях экрана комбинацией клавиш + можно изменять расположение экрана с вертикального на горизонтальный и наоборот.

Панель в верхней части экрана - это Status Bar. На ней расположены значки системных уведомлений: мощность сигнала станции мобильной связи, заряд аккумулятора и текущее время. Панель Status Bar также предназначена для отображения (в виде значков, появляющихся в левой части панели) пользовательских уведомлений о пропущенных звонках, непрочитанных текстовых и мультимедийных сообщениях, полученной почте и системных уведомлений от служб, работающих в фоновом режиме. Если в Status Bar выбрать значок уведомления и потянуть вниз появившийся маркер, открывается расширенная панель уведомления с более подробной информацией и кнопкой закрытия уведомления.

Маркер внизу экрана позволяет открыть окно запуска установленных в системе приложений- Application Launcher. Окно выдвигается при нажатии на маркер.

Эмулятор, тем не менее, не поддерживает некоторые функциональности, доступные на реальных устройствах:

• входящие и исходящие сообщения. Однако можно моделировать обращения по телефону через интерфейс эмулятора;

Панель запуска установленных приложений Application Launcher

• соединение через USB;
• видеокамера (однако есть имитатор работы видеокамеры);
• подключение наушников;
• определение статуса соединения;
• определение уровня заряда аккумуляторной батареи; D определение вставки или изъятия карты SD;
• соединение по Bluetooth.

Конечно, реальные телефоны несколько отличаются от эмулятора, но в целом AVD разработан очень качественно и близок по функциональности к реальному устройству.

СОДЕРЖИТСЯ В: ОПИСАНИЕ:

Позволяет указать совместимость приложения с одной или несколькими версиями платформы, с помощью уровней API. Несмотря на свое название, этот элемент используется для указания номера уровня API, а не номера версии SDK или версии платформы Android. Уровень API это одно целое число, он всегда связан с соответствующим номером платформы Android.

АТРИБУТЫ: android:minSdkVersion

Целое число, указывающее на минимальный уровень API, который требуется приложению для работы. Система предотвращает установку приложения, если уровень API на устройстве ниже, чем указанный в данном атрибуте. Необходимо всегда использовать данный атрибут.

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

Android:targetSdkVersion

Целое число, указывающее версию API, на которую нацелено приложение. Если атрибут не указан, используется значение, эквивалентное minSdkVersion .

Атрибуте сообщает системе, что вы протестировали приложение в указанной версии и система не должна разрешать работать приложению в режиме совместимости. С выходом новых версий, меняется поведение и внешний вид системы. Однако, если уровень API платформы выше версии, указанной в данном атрибуте, система разрешает использовать режим совместимости, чтобы приложение работало так, как вы ожидаете. Вы можете отключить такое поведение, указав в качестве targetSdkVersion версию платформы, на которой работает приложение. Например, установка значения 11 и больше позволит системе применить тему Xono, при запуске на Android 3.0 и выше, а также отключает режим совместимости экрана при запуске на больших экранах (потому что API 11 неявно поддерживает большие экраны).

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

Добавлено в API 4.

Android:maxSdkVersion

Целое число, указывающее максимальный уровень API, в котором приложение может работать.

В Android 1.5, 1.6 и 2.0.1 система проверяла значение атрибута при установке и проверке приложения после обновления системы. В любом случае, если значение атрибута ниже, чем уровень API системы, система не позволит установить приложение. В случае проверки приложения после обновления системы и несоответствии версий, приложение удаляется с устройства.

Чтобы показать как атрибут влияет на приложение после обновления системы, рассмотрим следующий пример:

Для приложения значение атрибута maxSdkVersion=5 . Пользователь устройства с Android 1.6 (API 4) скачал и установил приложение. Через несколько недель пользователь обновил версию Android до 2.0 (API 5). После обновления система вновь проверяет атрибут и оставляет приложение на устройстве. Приложение нормально работает. Однако, спустя некоторое время, устройство обновляется до версии Android 2.0.1 (API 6). После обновления, система не может подтвердить работу приложения, поскольку уровень API системы (6) выше, чем установленный в качестве максимального для приложения (5). Система удаляет приложение.

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

Добавлено в API 4.

Android после версии 2.0.1 больше не проверяет атрибут maxSdkVersion во время установки приложения или после обновления системы. Google Play будет использовать атрибут для фильтрации приложений, чтобы предотвратить установку на несоответствующие устройства.

ДОБАВЛЕНО: уровень API 1

Что такое уровень API?

Уровень API это целое число, которое идентифицирует уникальную ревизию API платформы Android.

Платформа Android предоставляет API, которое приложения могут использовать для взаимодействия с основной системой и включает в себя:

• набор пакетов и классов ядра.
• набор XML элементов и атрибутов для файла манифеста.
• набор XML элементов и атрибутов для объявления ресурсов.
• набор намерений.
• набор разрешений, которые требуют приложения, а также включены в системы.

Каждая последующая версия Android может включать обновление системных приложений.

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

Фреймворк, который использует платформа Android задается с помощью целого числа, который называется уровень API. Каждая версия Android поддерживает ровно один уровень API, хотя он включает также все более ранние версии (вплоть до API 1). Первый выпуск Android соответствует API 1.

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

Немного теории

Как мы все знаем, в Android есть такое понятие - полномочия приложений (permissions, разрешения). Полномочия прописываются в файл Manifest.xml каждого приложения и определяют то, к каким функциям API сможет получить доступ приложение. Хочешь работать с камерой - добавь в Manifest.xml строку . Нужен доступ к карте памяти - android.permission.READ_EXTERNAL_STORAGE . Все просто и логично, к тому же все доступные приложениям полномочия хорошо документированы .

Есть, однако, в этой стройной схеме одна очень важная деталь, которую сами создатели Android называют уровень доступа (protection level). Чтобы понять, что это такое, попробуй добавить в Manifest.xml любого своего приложения следующую строку:

По идее, данное полномочие должно открыть доступ к API, позволяющему переводить смартфон в режим полета, включать/выключать GPS и делать другие полезные вещи. Но IDE так не считает и поэтому сразу подчеркивает строку как ошибку с формулировкой «Permission is only granted to system apps». Это и есть предупреждение о нарушении того самого уровня доступа. IDE как бы говорит нам: да, ты можешь попробовать дать своему приложению полномочие WRITE_SECURE_SETTINGS , но Android все равно не разрешит тебе использовать закрепленный за ним API до тех пор, пока ты не сделаешь свое приложение системным. А что значит «системным» в данном случае? Это значит: подпишешь его тем же цифровым ключом, каким подписана сама прошивка (иди попробуй раздобыть такой ключ у какой-нибудь Samsung или LG!).

Официально в Android существует четыре уровня доступа:

• normal - «обычные» полномочия, дающие приложению доступ к безобидным функциям, которые не получится зловредно использовать (примеры: SET_ALARM, ACCESS_NETWORK_STATE, VIBRATE). Система даже не скажет тебе, что приложение вообще их использует;
• dangerous - «опасные» полномочия, юзер будет информирован о них при установке приложения либо увидит окошко с предупреждением в Android 6.0 (примеры: READ_SMS, SEND_SMS, CALL_PHONE, READ_CALL_LOG);
• signature - доступны только приложениям, подписанным ключом прошивки (примеры: GET_TASKS, MANAGE_USERS, WRITE_SETTINGS, MOUNT_UNMOUNT_FILESYSTEMS);
• privileged - доступны приложениям, располагающимся в каталоге /system/priv-app .

В большинстве случаев уровни доступа signature и privileged равноценны. Например, чтобы получить полномочие MANAGE_USERS, приложение должно быть либо подписано ключом прошивки, либо размещено в каталоге /system/priv-app . Но есть и исключения: например, полномочие MANAGE_DEVICE_ADMIN имеет уровень доступа signature, то есть единственный способ его получить - подписать приложение ключом прошивки.

Есть также набор внутренних уровней доступа, введенных в Android для решения определенных проблем: installer , development , preinstalled , appop , pre23 . По сути, это костыли, и на данном этапе ты можешь о них не думать, однако к уровню доступа development мы еще вернемся, и он нам очень сильно пригодится. А пока поговорим о том, как получить нужные нам уровни доступа и что они дают.

Уровень доступа privileged

Privileged не самый высокий уровень доступа и позволяет использовать далеко не весь API Android. Однако в большинстве случаев он оказывается вполне достаточным, так как позволяет устанавливать и удалять приложения и пользователей (INSTALL_PACKAGES, DELETE_PACKAGES, MANAGE_USERS), управлять статусной строкой (STATUS_BAR), управлять некоторыми настройками питания (WRITE_SECURE_SETTINGS), читать и изменять настройки Wi-Fi (READ_WIFI_CREDENTIAL, OVERRIDE_WIFI_CONFIG), отключать приложения и их компоненты (CHANGE_COMPONENT_ENABLED_STATE) и многое другое.

Чтобы приложение получило уровень доступа privileged, оно должно быть установлено в каталог /system/priv-app , а это значит - поставляться предустановленным в составе прошивки. Однако, имея root, мы можем поместить свое приложение в данный каталог с помощью двух функций:

// Подсобная функция, которая просто выполняет shell-команду static public boolean runCommandWait(String cmd, boolean needsu) { try { String su = "sh"; if (needsu) { su = "su"; } Process process = Runtime.getRuntime().exec(new String{su, "-c", cmd}); int result = process.waitFor(); return (result == 0); } catch (IOException e) { throw new RuntimeException(e); } catch (InterruptedException e) { throw new RuntimeException(e); } } // Функция делает указанное приложение системным и отправляет смартфон в мягкую перезагрузку static public void makeAppSystem(String appName) { String systemPrivAppDir = "/system/priv-app/"; String systemAppDir = "/system/app/"; String appPath = "/data/app/" + appName; // Подключаем /system в режиме чтения-записи if (!runCommandWait("mount -o remount,rw /system", true)) { Log.e(TAG, "makeAppSystem: Can"t mount /system"); return; } int api = Build.VERSION.SDK_INT; String appDir = systemPrivAppDir; // Копируем приложение в /system/priv-app или /system/app в зависимости от версии Android if (api >= 21) { runCommandWait("cp -R " + appPath + "* " + appDir, true); runCommandWait("chown -R 0:0 " + appDir + appName + "*", true); runCommandWait("rm -Rf " + appPath + "*", true); } else { if (api < 20) { appDir = systemAppDir; } runCommandWait("cp " + appPath + "* " + appDir, true); runCommandWait("chown 0:0 " + appDir + appName + "*", true); runCommandWait("rm -f " + appPath + "*", true); } // Отправляем смартфон в мягкую перезагрузку Shell.runCommand("am restart", true); }

Функцию runCommandWait я описывать не буду, она просто выполняет shell-команду и ждет ее завершения (подробнее читай в моей статье про написание приложений с правами root). Функция makeAppSystem, в свою очередь, принимает полное имя приложения (это то самое com.example.app, которое ты указываешь при создании нового проекта в Android Studio) и переносит его в /system/priv-app или /system/app , в зависимости от используемой версии Android. Код может показаться тебе несколько странным, на самом деле он абсолютно корректен и учитывает два фактора:

• до Android 4.4 (API Level: 20) каталога /system/priv-app не существовало и все системные приложения размещались в /system/app ;
• начиная с Android 5.0 (API Level: 21) пакеты с приложениями не просто складируются в /data/app и /system/priv-app , а размещаются внутри своих обособленных подкаталогов.

Как использовать этот код? Очень просто: ты определяешь в Manifest.xml своего приложения все privileged-полномочия, которые ему нужны, не обращая внимания на ошибки IDE. Затем в самое начало кода приложения вставляешь вызов makeAppSystem с именем самого приложения в качестве аргумента, компилируешь и запускаешь. После запуска приложение перемещает само себя в /system/priv-app , перезагружает смартфон, и ему открываются все privileged API.

Список privileged-полномочий можно посмотреть в исходниках Android . Просто ищи по слову privileged. О том, как их использовать, - чуть позже.

Уровень доступа signature

Подпись ключом прошивки позволяет получить самый высокий уровень доступа к API - signature. Имеющее такой доступ приложение может делать практически все что угодно: манипулировать любыми настройками Android (WRITE_SETTINGS, WRITE_SECURE_SETTINGS), наделять приложения правами администратора (MANAGE_DEVICE_ADMINS), программно нажимать кнопки и вводить данные в любое окно (INJECT_EVENTS) и многое другое.

Получить такой уровень доступа на стоковой прошивке почти невозможно. Ни один производитель смартфонов не предоставит тебе ключ для подписи своих прошивок. Но если речь идет о кастомной прошивке, то все становится немного проще. Например, ночные сборки того же CyanogenMod (а я напомню, что пользователей у нее больше, чем юзеров всех версий Windows Phone, вместе взятых) подписываются тестовым ключом, а его особенность в том, что он есть в открытом доступе .

Но это еще не все, в CyanogenMod есть механизм безопасности, который, в отличие от чистого Android, позволяет получать уровень доступа signature не абсолютно всем приложениям, подписанным ключом прошивки, а только тем, что размещены в /system/priv-app . Поэтому, чтобы получить уровень доступа signature в CyanogenMod (не в Cyanogen OS, я подчеркиваю), необходимо:

1. Добавить в Manifest.xml приложения необходимые полномочия.
2. Добавить в приложение вызов функции makeAppSystem(), описанной в предыдущем разделе.
3. Подписать релизную версию приложения ключом platform из репозитория CyanogenMod.

Уровень доступа development

В Android есть специальный уровень доступа development, отличие которого заключается в том, что приложения получают его не по факту размещения в /system/priv-app или использования цифровой подписи прошивки, а динамически. То есть система может дать такой уровень доступа любому приложению, а может и отозвать обратно. Но самое важное, что, имея права root, приложение может наделить себя таким уровнем доступа самостоятельно.

Чтобы это сделать, достаточно использовать примерно такой код:

RunCommandWait("pm grant " + appName + " android.permission.WRITE_SECURE_SETTINGS", true);

В данном случае приложение appName получит полномочие WRITE_SECURE_SETTINGS вне зависимости от того, где оно размещено и каким ключом подписано. Круто? Вне сомнения, однако WRITE_SECURE_SETTINGS - фактически единственное полезное полномочие с уровнем доступа development. Остальные четырнадцать - это полномочия для отладки и тестирования (чтение логов, дампы памяти и так далее).

Как использовать системный API?

Основная проблема, с которой ты столкнешься при работе с системным API, - это полное (за небольшими исключениями) отсутствие документации. Ни в официальных руководствах, ни в неофициальных ты не найдешь почти никаких упоминаний об этом. Информацию придется собирать по крупицам, прошаривая сотни страниц форумов и читая тысячи страниц исходников Android. Однако хоть и небольшую, но отправную точку в виде парочки полезных примеров мы тебе дадим.

WRITE_SECURE_SETTINGS

Полномочие WRITE_SECURE_SETTINGS появилось в Android 4.2 для защиты некоторых критически важных настроек Android. Среди таких настроек: включение/выключение режима полета, управление настройками местоположения и передачи данных. Оно защищено сразу тремя уровнями доступа: signature, privileged и development. То есть ты можешь использовать любой из перечисленных выше способов получения уровня доступа, чтобы наделить свое приложение полномочием WRITE_SECURE_SETTINGS.

Как использовать открывшиеся возможности? Например, так:

// Читаем текущее значение настройки boolean isEnabled = Settings.System.getInt(getContentResolver(), Settings.System.AIRPLANE_MODE_ON, 0) == 1; // Переключаем настройку Settings.System.putInt(getContentResolver(), Settings.System.AIRPLANE_MODE_ON, isEnabled ? 0: 1); // Отправляем интент для переключения Intent intent = new Intent(Intent.ACTION_AIRPLANE_MODE_CHANGED); intent.putExtra("state", !isEnabled); sendBroadcast(intent);

Это очень простой код, который тупо переключает смартфон в режим полета или наоборот в зависимости от текущего состояния. Все просто и лаконично.

INSTALL_PACKAGES

Как ясно из названия, полномочие INSTALL_PACKAGES позволяет «втихую» устанавливать в систему APK-пакеты. Использовать эту возможность могут либо подписанные ключом прошивки приложения (signature), либо установленные в /system/priv-app . При этом даже не обязательно использовать Java API, достаточно вызвать консолью команду pm (Package Manager) с нужными параметрами:

RunCommandWait("pm install " + apkPath, false);

После отработки команды пакет apkPath будет установлен в систему. Ты можешь возразить, что то же самое можно сделать и с правами root, и будешь прав: в данном случае достаточно изменить последний аргумент функции runCommandWait() на true. Однако стоит иметь в виду, что приложения с правами root, во-первых, приводят к появлению окна запроса соответствующих полномочий у юзера, а во-вторых, логируются тем же SuperSU. А так достаточно один раз прописать свою софтину в /system/priv-app , и она сможет устанавливать сколько угодно софта без всяких вопросов.

Вместо выводов

Вот и все. Доступ к закрытому API в Android не так уж и сложно получить. С другой стороны, с легитимным софтом использовать его в большинстве случаев не имеет смысла, проще получить права root и вызывать соответствующие консольные команды: settings для изменения настроек, pm для установки/удаления приложений, setprop для изменения низкоуровневых настроек и так далее. Однако если речь идет о не совсем обычном программном обеспечении...

More information about how API levels work is available in What is API Level?

App Components

Isolated services

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.

You can handle encrypted media data in the codecs by calling queueSecureInputBuffer() in conjunction with the MediaCrypto APIs, instead of the normal queueInputBuffer() .