Что такое android api

Android для начинающих: использование REST API

Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)

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

Это может звучать сложно, но с большим количеством сайтов, которые раскрывают свои ресурсы через REST API, на самом деле это довольно просто. (Смотрите руководство для начинающих по HTTP и REST для примера.)

В этом уроке я расскажу вам, как использовать классы и методы, доступные в Android SDK, для подключения к удаленным веб-серверам и взаимодействия с ними с использованием их REST API.

1. Включение доступа к Интернету

Поскольку android.permission.INTERNET не считается опасным разрешением, вам не нужно запрашивать его во время выполнения на устройствах с уровнем API 23 или выше.

2. Создание фоновых потоков

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

3. Создание HTTP-соединения

В следующем фрагменте кода показано, как настроить соединение с корневой конечной точкой API GitHub:

4. Добавление заголовков запросов

5. Чтение ответов

Если класс HttpURLConnection получает код ответа на перенаправление, например 301, он автоматически обрабатывает его и следует за перенаправлением. Поэтому, как правило, вам не нужно будет писать дополнительный код для проверки перенаправления.

6. Разбор JSON ответов

То как вы извлекаете определенную часть информации из документа JSON, зависит от его структуры. Например, документ JSON, возвращаемый корневой конечной точкой REST API GitHub, выглядит следующим образом:

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

7. Использование разных HTTP методов

В следующем фрагменте кода показано, как отправить на сервер простую пару «ключ-значение»:

8. Кэширование ответов

В следующем фрагменте кода устанавливается кеш размером 100 000 байт:

Заключение

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

Если вы считаете, что использование HttpURLConnection слишком сложное, вам следует обратить внимание на сторонние библиотеки, такие как например, Volley. Библиотеки, подобные этой, используют класс HttpURLConnection внутри, но предоставляют множество удобных методов, которые позволяют сделать ваш код более кратким и читаемым.

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

Источник

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

Почему это важно? Дело в том, что чем больше терминологический аппарат, тем сложнее человеку вне отрасли вникать в детали.

С технарями (исполнителями) — все понятно: они работают с технологиями и используют терминологию постоянно, ведь это существенно ускоряет коммуникации внутри команд. У бизнеса же (клиента) все эти «словечки» вызывают только дополнительные вопросы, такого вида: «Зачем это нужно? Почему это столько стоит? Можем ли мы обойтись без этого?»

Команда Stfalcon имеет большой опыт разработки мобильных приложений, и мы довольно часто сталкиваемся с вопросами, которые можно квалифицировать как «типичные». Один из таких «Зачем мобильному приложению API?»

Чтобы облегчить понимание этого вопроса, давайте в формате «просто о сложном» разберем, что же такое API (Application Programming Interface), какие функциональные задачи на него возложены, и почему мобильному приложению без него не обойтись.

Интерфейс

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

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

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

Второй вопрос, за счет чего происходит движение, ускорение, торможение и прочие функции. Не вникая в детали на это можно ответить так: «Автомобиль, как транспортное средство, состоит из множества связанных между собой компонентов и на более высоком уровне их всего три, это: кузов, шасси и двигатель. В свою очередь, каждый из этих компонентов, состоит из более узкоспециализированных устройств и механизмов, которые довольно тесно взаимодействуют между собой. В результате этого взаимодействия мы и получаем от автомобиля то, что необходимо».

Современный автомобиль довольно серьезное инженерное решение, при этом водителю не обязательно разбираться со всей этой сложностью, она просто скрыта от глаз. И как понимаете, скрыта она за интерфейсом 🙂

Да, вы правильно поняли: руль, педаль акселератора, коробка передач, климат-контроль и даже ваша любимая магнитола — все это часть интерфейса, который предоставлен водителю для управления всей сложностью.

Интерфейс встречается в нашей жизни довольно часто:

Учитывая вышеприведенные примеры, попробуем дать определение этому понятию.

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

Если разбирать данное определение на примере автомобиля, то можно выделить две системы: человек и машина. Машина задает некие правила, соблюдая которые, человек может ей управлять.

API и RESTful API

Разобравшись с базовой составляющей термина, продолжим расшифровку остальных двух слов, а точнее Application Programming.

Само название намекает на принадлежность термина к программному обеспечению. Проводя аналогию с тем же автомобилем, можно прийти к выводу, что API — это опять-таки две системы и правила, просто в этом случае, в качестве систем выступают программные модули, веб-сервисы и т.д.

В принципе на этом можно было бы закончить с API, но было бы неправильным не упомянуть о RESTfull API. Дело в том, что API — описывает как бы явление. В свою же очередь RESTfull API (или просто REST API) — это один из подходов к реализации API.

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

Ответ на главный вопрос

Вооружившись знаниями, что такое интерфейс и даже немного коснувшись более узкоспециализированного понятии, как RESTfull API, нам будет гораздо проще ответить на главный вопрос «Зачем мобильному приложению API?».

Давайте начнем с «анатомии». Мобильное приложение состоит не только с визуальной части (UI — User Interface). При разработке нужно решить ряд других вопросов, например, где хранить данные — информацию о пользователях, сообщениях, заказах. Также, приложение должно выполнять определенные функции, скажем, принимать оплату, авторизовать пользователя, отправлять смс при регистрации или push-нотификацию при наступлении какого-то события.

Задач много, но какая же из них (а может все?) является причиной создания API? Ответ: никакая. Потому что все это можно реализовать и без API в рамках одного смартфона.

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

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

Кроме обмена данных, есть и другие проблемы: что делать в случае утери смартфона или сброса настроек к заводским; как быть с поддержкой сотни различных устройств.

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

Еще один кейс, когда без API не обойтись. Вы хотите предоставлять клиентам доступ к данным или функциям за плату.

Для примера можно взять смс-агрегаторы, основной задачей которых является отправка sms. В этой ситуации разработчику нет необходимости разбираться во всей сложности устройства мобильных сетей. Все, что необходимо — это интегрироваться с API смс-агрегатора и для отправки, просто вызвать нужный API-метод.

Учитывая вышеописанное, делаем ключевой вывод: чтобы выполнять свои функции мобильное приложение обращается к внешнему серверу, который централизует бизнес логику (еще называют Backend).

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

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

Надеюсь, эта статья позволит Вам окончательно разобраться в этом вопросе.

Источник

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

Содержание статьи

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

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

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

Linux для хакера

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

Есть также набор внутренних уровней доступа, введенных в 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-полномочий можно посмотреть в исходниках Android. Просто ищи по слову privileged. О том, как их использовать, — чуть позже.

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

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

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

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

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

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

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

Полномочия development в исходниках Android

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

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

WRITE_SECURE_SETTINGS

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

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

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

INSTALL_PACKAGES

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

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

Евгений Зобнин

Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.

Источник

Что такое android api

API Level это просто целое число, которое однозначно идентифицирует ревизию рабочего окружения программных библиотек (framework API revision), которая предоставляется версией платформы (операционной системой) Android.

Платформа Android предоставляет framework API, которое могут использовать приложения для взаимодействия с нижележащей системой Android. Framework API состоит из:

• Базового набора пакетов и классов.
• Набора элементов XML и атрибутов для декларирования в файле манифеста (manifest file).
• Набора элементов XML и атрибутов для декларирования и доступа к ресурсам.
• Набора намерений (Intents).
• Набора разрешений доступа к ресурсам устройства и системы, которые приложение может запросить, а также защита ограничения доступа, встроенная в систему.

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

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

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

В таблице ниже указаны поддерживаемые API Level для каждой платформы Android. Для информации по относительным количествам устройств, которые работают на каждой версии, см. страничку [2].

[Как используется API Level в Android]

Идентификатор API Level играет ключевую роль в предоставлении информации пользователям и разработчикам.

• API Level позволяет платформе (операционной системе) Android описать максимальную ревизию framework API, которую платформа поддерживает.
• API Level позволяет приложениям описать требуемую для них ревизию framework API.
• API Level позволяет системе обрабатывать инсталляции приложений на устройстве пользователя и определять, какие их них являются несовместимыми с текущей версией системы.

Подробнее про использовании API Level в приложении и системе Android см. [3].

[Совместимость приложений с новыми версиями операционной системы Android]

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

Forward-совместимость важна, потому что множество устройств, работающих на Android, получают обновления системы на лету, по каналу Wi-Fi (over-the-air, OTA). Пользователь может установить Ваше приложение и успешно его использовать, и позднее получить OTA-обновление на новую версию платформы Android. Как только обновление установлено, Ваше приложение будет работать уже в новой версии рабочего окружения, на новом API (run-time version environment), и от этого нового API и возможностей системы будет зависеть работа Вашего приложения.

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

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

[Выбор версии платформы и API Level]

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

[Декларирование минимальной версии API Level]

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

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

[Тестирование на верхних уровнях API Level]

После того, как скомпилировали приложение, Вы должны убедиться, что протестировали его на платформе, указанной в атрибуте android:minSdkVersion приложения. Чтобы сделать это, создайте AVD, которая использует версию платформы, требуемую приложением. Дополнительно, чтобы убедиться в forward-совместимости, Вы должны запустить и протестировать приложение на всех платформах, которые используют более высокий уровень API Level, чем использует Ваше приложение.

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

[Использование Provisional API Level]

В некоторых случаях может быть доступен «Ранний просмотр (Early Look)» платформы Android SDK. Это означает разработку для платформы, которая пока официально не появилась на рынке. Чтобы начать разработку на платформе, API которой еще не получила финальную версию, то не указывается API Level платформы. Вместо этого Вы должны использовать предварительный (provisional) API Level в манифесте приложения, когда делаете сборку приложения на указанной платформе. Provisional API Level не является числом, это строка, соответствующая кодовому имени еще не выпущенной версии платформы. Provisional API Level будет указан в примечаниях к релизу для ранних релизов SDK (Early Look SDK release), и эта строка чувствительна к регистру символов.

Использование provisional API Level разработано для того, чтобы защитить разработчиков и пользователей устройств от нежелательной публикации или инсталляции приложений, основанных на Early Look framework API, потому что на финальном образе системы приложение может работать не так, как ожидалось.

Provisional API Level будет допустим только при использовании Early Look SDK, и его можно использовать для запуска приложений только в эмуляторе. Приложения, использующие provisional API Level, никогда не могут быть установлены на устройство Android. После финального релиза платформы Вы должны заменить любые экземпляры provisional API Level в Вашем файле манифеста приложения на действительный идентификатор API Level в виде целого числа.

[Фильтрация документации на основе API Level]

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

Чтобы использовать фильтрацию, поставьте галочку в чекбоксе для разрешения фильтрации, сразу ниже бокса поиска на странице. Затем установите контрол «Filter by API Level» в тот же API Level, который используется в Вашем приложении. Обратите внимание, что API, представленный в последующих версиях API Level нарисованы серым, и это содержимое будет замаскировано, потому что не будет доступно в Вашем приложении.

Фильтрация по API Level в документации не предоставляет просмотр, что нового представлено в каждом API Level. Фильтрация просто предоставляет метод для просмотра всего API, связанного с указанным API Level, когда исключаются элементы API, представленные в последующих API Levels.

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

Также имейте в виду, что документация по отдельным элементам API указывает API Level для каждого представленного элемента. API Level для пакетов и классов указывается как «Since » в правом верхнем углу содержимого каждой страницы документации. API Level для членов класса указан в соответствующем заголовочном файле.

Источник