Android management api что это

Android Management API

The Android Management API is available as part of Android Enterprise, an initiative providing developers with tools to build solutions for organizations to manage their Android device fleets. The program is intended for enterprise mobility management providers (EMMs). To deploy a production solution that uses the Android Management API, EMMs need to follow the steps outlined in Release your solution.

You can use the Android Management API to support the work profile, fully managed device, and dedicated device solution sets.

See the Quickstart guide to try out the API.

How it works

The Android Management API supports the full enterprise mobility management lifecycle, from initial customer enrollment to setting up and managing devices.

As an EMM developer, you supply your customers with an on-premise or cloud-based EMM console. In your console, your customers generate device enrollment tokens and create management policies. They use the tokens to enroll devices and apply management policies to the devices they enrolled.

In the backend, your console uses the Android Management API to create enrollment tokens, policies, and other management resources. During enrollment, each device installs the API’s companion app, Android Device Policy. When policies are linked to a device in the API, Android Device Policy automatically enforces the policy settings on the device.

API resources

This section describes the primary resources used in the Android Management API.

Enterprises

An enterprises resource typically represents a single organization. You create an enterprise as part of an online setup flow that your customers use to bind their organization with your EMM solution. Policies, enrollment tokens, and devices belong to an enterprise.

Policies

The Android Management API follows a policy-driven model. A policies resource contains a group of device and app management settings that govern the behavior of a device. The range and flexibility of the settings supported in policies allow you to set up devices for a variety of different use cases.

See Create a policy for more information.

Enrollment tokens

You use enrollmentTokens to bind devices to an enterprise—a process called enrollment and provisioning. Enrollment tokens can optionally contain extra details (e.g. corporate WiFi credentials), a policyName linked to a policies resource, and a user account identifier.

After creating an enrollment token, you can pass the token to a device using one of several different provisioning methods. Devices install Android Device Policy as part of the provisioning process. If a policyName is specified in the enrollment token, then the policy will be applied immediately after provisioning is complete.

The Android Management API simplifies user management—you can enroll a device with or without specifying a user in the enrollment token.

• If you don’t specify a user, a new user will be created automatically.
• If you specify an existing user, the existing user will be associated with the device. You can associate a user with up to 10 devices.

See Provision a device for more information.

Devices

A devices resource is created when a device is successfully enrolled. The resource contains read-only details about a device, including its associated user, policy, and management mode.

Device management is carried out through policy, but you can use enterprises.devices.issueCommand to lock, reboot, or reset the password on a device. To wipe a device, call enterprises.devices.delete .

Get started

Test out the API—use the Quickstart guide to set up a device in minutes. Ensure that you understand the steps required to release your solution in a production environment before using the developer’s guide and API reference on this site to build your solution.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Quickstart

To get started with the Android Management API, we’ve created a Colab notebook that you can follow to enroll an enterprise, create a policy, and provision a device.

To use the quickstart guide, you need:

• An Android 6.0+ device.
• A Gmail account. This account cannot be associated with an existing enterprise.
• A Cloud Platform project that you own or can edit:
  1. Go to the Projects Page.
  2. Click CREATE PROJECT.
  3. Take note of the project ID.

Cleanup (optional)

To reset your device and unbind your Gmail account from the enterprise you created, follow the steps below.

1. Deprovision a device

Before you can deprovision a device, you need the device’s deviceId . To get a list of all your provisioned devices, call enterprises.devices.list and specify:

• parent : The enterprise name in the form of enterprises/ .

A successful response contains an array of devices resources. Because you only need the name field to deprovision a device, the example response below is shortened.

To deprovision and factory-reset a device, call enterprises.devices.delete and specify:

• name : The device ID in the form of enterprises//devices/ .

If successful, the request returns an empty response body.

2. Delete an enterprise

You can only associate your Gmail account with a single enterprise. To unbind your account from an enterprise, you need to delete the enterprise:

1. Visit play.google.com/work with the account used to create the enterprise.
2. Select Admin Settings.
3. In Organization information, select the three vertical dots.
4. Click Delete Organization.

You can now use your Gmail account to create another enterprise.

Start developing

• For more detailed information on how to develop an Android management solution, review the Introduction, Developer’s guide, API reference and Permissible Usage guidelines.
• Download the Android Management API client library for Java, .NET, Python, or Ruby (Alpha).

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Источник

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

Далеко не всегда устройства с операционной системой Android используются как персональный гаджет. Иногда они служат одной конкретной бизнес-цели, и необходимость в предустановленных свойствах девайса отпадает.

В этой статье рассказываем, как мы в Axmor используем несколько простых манипуляций с Android Management API, чтобы заблокировать ненужные функции без root-прав.

Каждый из нас хоть раз в жизни имел дело с корпоративными девайсами:

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

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

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

В нашей компании разрабатывается много enterprise-приложений, из-за чего мы часто сталкиваемся с необходимостью блокировки функций на dedicated devices. Например, в нашей практике было приложение для инженеров по безопасности на промышленных предприятиях. Эти специалисты ходят по заводу, следят за исправностью трубопроводов и должны куда-то заносить собранные данные:

Компания-заказчик закупила для этой цели несколько десятков смартфонов на Android и заказала нам приложение со следующими требованиями:

на экране всегда должно присутствовать выбранное приложение без возможности запуска других приложений. Соответственно, должны быть заблокированы кнопки “Назад”, “Домой” и “Последние приложения”;

выбранное приложение должно запускаться сразу же после перезагрузки;

заблокировать возможность изменять какие-либо настройки на устройстве;

заблокировать возможность взаимодействия со статус-баром, т.к. там возможно менять настройки;

заблокировать возможность открывать пуш-уведомления;

экран устройства не должен гаснуть.

Часть этого функционала можно реализовать довольно просто, однако на текущий момент устройство без root-прав не позволяет как-либо блокировать взаимодействие со статус-баром и пуш-уведомлениями. Также не удастся ничего сделать с кнопкой “Последние приложения”.

Тут на помощь приходит Android Management API и device policy controller (DPC), которые позволят выполнять настройку корпоративных устройств в кратчайшие сроки и по своему усмотрению блокировать любые функции.

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

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

Чтобы упростить жизнь разработчикам таких решений, Google в 2017 году выпустил свой DPC, который называется Android Device Policy и управляется с помощью Android Management API. Чтобы использовать Android Management API, нужно выполнить несколько шагов:

1. Создать сервисный аккаунт. Этот шаг является опциональным и нужен для вызова методов API из кода (с бэкенда или из web-консоли, которую также нужно писать самим), поскольку такие вызовы требуют аутентификации через OAuth.
2. Создать организацию (enterprise). Как следует из названия, это ресурс, который представляет собой организацию. Чтобы создать такой ресурс, нужен Gmail-аккаунт, не привязанный ни к какой организации. Enterprise состоит из политик (policies) и устройств (devices).
3. Создать политику (policy). Это тот самый набор правил и ограничений, который будет применен к устройству. Когда мы изменяем что-либо в policy, все устройства, к которым она применена, автоматически обновляют своё состояние в соответствии с изменениями без каких-либо дополнительных действий с нашей стороны.
4. Зарегистрировать устройство (device). Чтобы применить созданную политику к устройству, нужно создать EnrollmentToken, привязанный к выбранной policy. Затем устройство нужно сбросить к заводским настройкам, т.к. установить DPC в качестве Device owner’а можно только в момент первичной настройки системы. Это работает для устройств с ОС Android 6.0 и выше, подробности можно найти в официальной документации. Самый простой способ передать токен на устройство — сформировать QR-код на его основе. JSON для формирования QR-кода можно получить из поля qrCode у ресурса EnrollmentToken. Чтобы отсканировать QR-код, нужно тапнуть 6 раз в одном и том же месте на первом экране, появившемся после сброса заводских настроек (обычно на нём мы выбираем язык), после чего будет предложено подключиться к интернету и скачать сканер QR-кодов. Если же этот способ не сработал на выбранном устройстве, можно дойти до этапа ввода данных Google-аккаунта и ввести туда afw#setup.

Google предоставляет несколько опций, позволяющих пользоваться Android Management API. Самый простой способ выполнить все эти шаги — пройти интерактивный quickstart guide. Для обращения к API из кода можно использовать одну из библиотек на Java, .NET, Python, или Ruby.

Вернёмся теперь к списку требований для Dedicated device и рассмотрим, как их можно реализовать с помощью policy. Чтобы выбранное приложение всегда присутствовало на экране и запускалось автоматически после перезагрузки, оно должно заменить стандартное Home app. Для этого нужно добавить следующий блок в политику:

Также нужно разрешить приложению запускать lockTaskMode, который позволит нам скрыть кнопки “домой” и “последние приложения”, а также не позволит выйти из приложения с помощью системной кнопки “Назад”:

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

Чтобы скрыть статус бар, нужно добавить в policy

Ну а для того, чтобы экран всегда оставался включенным, нужно просто добавить флаг android:keepScreenOn=»true» в корневую ViewGroup Activity. Итоговый JSON политики будет выглядеть примерно так:

Различные примеры политик можно посмотреть тут. А все возможные параметры для политики — тут.

Есть ещё одна проблема, с которой мы столкнулись при разработке нашего решения. В одном из проектов Axmor заказчику требовался функционал выхода из заблокированного режима, чтобы можно было снова полноценно пользоваться устройством без сброса к заводским настройкам. Это можно сделать через создание двух разных политик — policy_locked и policy_unlocked, и инициируя их смену через backend с устройства. Но дело в том, что с устройства нельзя напрямую получить его внутренний id в Android Management API, а значит — нельзя выполнить никакие операции с ним. До Android 10 можно найти устройство в общем списке по его серийному номеру, который хранится в Device.hardwareInfo.serialNumber, сравнив его с серийным номером, полученным через Build.getSerial() или Build.SERIAL, однако начиная с Android 10, получение серийного номера запрещено для несистемных приложений.

По этой проблеме есть ответ на Stackoverflow от Google. Они советуют использовать managed configurations, фактически — это дополнительные параметры, которые можно передать на устройство, прописав их в policy. Конечно, в таком случае для каждого устройства нужна своя уникальная policy. Для того, чтобы избежать ручного ввода, можно использовать Pub/Sub нотификации, которые позволяют получить уведомление при регистрации нового устройства и сразу же записать в managed configurations его id. Не самый простой способ, но самый правильный. Прописать какой-нибудь уникальный id для устройства вручную при формировании QR-кода не получится, потому что managed configurations устроены таким образом, что записать туда что-либо возможно только после того, как устройство уже зарегистрировано.

Итак, у нас есть policy, способная заблокировать всё и вся на устройстве, кроме нашего избранного приложения. Дело сделано? Не совсем. Наше приложение ещё требуется как-то установить на устройство, а просто так выкладывать в Google Play не очень хочется — ведь мы явно делаем его не для широкой аудитории. Можно, конечно, отправить заказчику apk и попросить поставить приложение вручную, но делать это для каждого устройства довольно утомительно, плюс это нужно будет делать при каждом обновлении приложения.

Решение — использовать Managed Google Play и выложить наше приложение как private app. Для этого нужно сначала загрузить приложение в Google Play, затем зайти в Store Presence -> Pricing & Distribution -> User programs -> Managed Google Play, отметить Turn on advanced managed Google Play features -> Privately target this app to a list of organizations. Здесь нужно выбрать id enterprise, для которой мы регистрируем устройства. Теперь, если в policy для нашего приложения будет прописано поле installType как FORCE_INSTALLED, оно будет установлено автоматически при регистрации устройства.

Несмотря на некоторые недостатки, Android Management API в настоящий момент — самый простой и удобный способ для создания Dedicated device или устройства одного приложения в ОС Android. Большие возможности для кастомизации позволяют делегировать непосредственное выполнение кода для создания ограничений на устройстве готовому DPC, что способно существенно сократить время разработки. Нам на мобильных проектах в Axmor это API позволяет сократить время на выполнение “рутинной” работы по реализации ограничений и уделить больше внимания самому Single App.

Даже не слышал про такую опцию, спасибо за вводную.

Спасибо! Это было полезно.

Привет, я использую приложение Kiosk Mode app управления планшетами своих сотрудников и теперь хочу интегрировать в него свое новое приложение. Очень интересный материал.

Не проверял, чисто теория у меня такое ощущение, что PUB/SUB нотификации можно отправить из самого приложения, через https://developer.android.com/reference/androidx/enterprise/feedback/package-summary оттуда, добыть устройство, и поменять ему полиси на версию с не прикрепленным экраном. Без выделеных policy для каждого устройства. Вопрос в другом, а что делать если интернета в этот момент нет, и нужно как-раз эту проблему решить, открипив экран? Я это решил вызовом интента, для доступа к настройкам устройства, и VPN клиенту, из самого приложения.

Еще вариант полиси с опцией «kioskCustomLauncherEnabled»: true оно всё-же позволяет по желанию приложениям кодом, прикреплятся к экрану (не знаю может это баг). Только работает это странно, после загрузки устройства, через 30 секунд, экран приложения открепляется сам! И выпадает на рабочий стол(кастомный ланчер), так-же экран открепляется при смене локали устройства (а у меня кстати задача менять локаль устройства, из настроек на сервере. Кстати Management API менять локаль не позволяет, покрайней мере полиси я не нашел, а вот было бы круто). Хотя потом можно снова запустить приложение и оно прикрепит экран.

Еще вопрос, а что делать, если я после установки Single APP приложения, хочу зарегистрировать аккаунт, сразу для него. Хорошо есть Pub/Sub нотификации, в конце установки. Затем можно задать этот аккаунт в приложение, через managed configurations.
Но блин, вся прелесть полиси, в том что изменив один раз policy, мы получаем эффект на всех устройствах с этим полиси (например установить новое приложение на все устройства), и это ломается, т.к. идентификатор управляемой конфигурации или сама конфигурация, задаётся в Policy. А вот аккаунт желательно б иметь на каждом устройстве свой. ред.

Источник