Android usb device permission

Android usb device permission

Handling USB connections in Android

Share this post

The conventional way to use an Android tablet or smartphone is as a USB peripheral that connects to a USB host (e.g. PC) and synchronizes its data and media files. However an Android device can also behave as a USB host since the API level 12 (Android 3.1). With this feature, you can for example connect and use a USB mouse, keyboard or memory stick with an Android phone. In order to physically attach the peripheral device, you need a special cable adapter called OTG (On The Go). The most common form factor includes a female Type-A USB connector at one end, where the peripheral device is connected to, and a male micro USB connector (at the other end) that plugs into the android device.

Android is quite flexible on what can be done with a connected USB device, but when writing an App we need to make sure that we configure it properly and that we abide by the security requirements implemented by the Android team.

In this post we will explain the different approaches for fulfilling the said security requirements, either hardcoded at the manifest file or defined dynamically inside the application code.

The first step is to ask for permission to access the USB port, which is done in our manifest file:

Now we have two options, to configure the USB connectivity statically in the manifest file or to do it dynamically in the code of our App.

USB configuration in the Manifest file (declarative)

This first mechanism is less flexible but it is a good choice if we know beforehand the type of devices that our App will connect to. The USB functionality is defined at the Activity level, and we need to register for USB intents:

In this example MainActivity registers to be informed when a USB device is connected ( USB_DEVICE_ATTACHED ) or disconneted ( USB_DEVICE_DETACHED ). Note that this is done at the Activity level. Other activities or services in our project can also register to these events.

If we want to restrict the type of devices that will trigger our Activity, we can include a device filter XML file indicated in the meta-data element. This file is stored in /res/xml folder and lists combinations of vendor id and/or product id as shown in our example file:

If we register an Activity like this, the event USB_DEVICE_ATTACHED will arrive as an intent, but the triggering method will depend on the state of the Activity:

• If the Activity has not been created yet, it will be created and the intent arrive through the onCreate() method:

• If the activity has already been created/instantiated, the event will arrive through the ‘onNewIntent()’ method:

To receive a USB_DEVICE_DETACHED event we need to register first a BroadcastReceiver, as explained in the following section.

USB configuration in the application code (imperative)

To achieve the equivalent functionality, now programmatically from our code, we need to create a BroadcastReceiver and then register it to receive the USB events.

In this case, the events will be received via the onReceive() method of BroadcastReceiver .

To stop receiving events, just unregister the receiver with:
unregisterReceiver(bReceiver);

The main advantage of this method is that we can control when we want to receive USB events. On the other hand, if our Activity or service is not started previously, plugging a USB device will not trigger it.

Security and user permission to connect to a USB device

In order to avoid security threats, Android mandates that the user must give explicit permission to an application willing to use a USB peripheral device. This user permission is granted at application level, that is, once obtained for an Activity, the rest of the Activities and services packaged in the application will also be granted the permission.

When a USB device is connected, Android looks for apps/Activities registered for the USB_DEVICE_ATTACHED event, either in the Manifest or pogrammatically. If XML filters have been defined, these are also applied.

Android then presents a dialog to the user with the list of all registered applications. The user is requested to select one of the Apps and decide if he wants to grant permission only once or always (i.e. default). Only the selected App will receive the USB_DEVICE_ATTACHED intent.

If the user selects default, Android will remember this option and from that moment on will trigger automatically the chosen application whenever that USB device (vendor id + product id) is connected in the future.

There is no way to avoid this user permission dialog behaviour. It must be executed at least once (if the user selects always/default).

Since our App does not know if the user has already granted permission, we need to check the user permission flag always, every time that we want to start a USB connection:

If we require user permission, we requestPermission() for the device with a PendingIntent. Android will pop up the user permission dialog and then will contact back our application with the PendingIntent. We need a BroadcastReceiver to receive this notification:

As happened in the previous user permission dialog, the user can grant access only once or forever («Use by default for this USB device”).

Once we have the user permission, we can start the communication with the peripheral USB device. For instance, in one of our projects we are using the USBSerial library created by Felipe Herranz to connect an Android device to Arduino.

Images

The images used in this post are solely owned by their respective rights holders:

We hope that you found this post useful. Do subscribe to our mailing list if you want to keep updated about new articles in our blog.

Источник

Работа с устройствами USB в Android

В недавней статье на Geektimes в комментариях возник вопрос о поддержке в ОС Android периферии, подключенной к шине USB. Действительно, большинство вендорского ПО, к примеру, для работы с принтерами и МФУ, поддерживает только подключение по сети. Однако это не означает, что в самой ОС Android нет такой возможности — это означает лишь то, что большинство устройств не имеют полноценного USB хоста, и далеко не все имеют поддержку OTG. По сети же могут работать абсолютно все без исключения.

Большинство устройств на Android при наличии порта OTG поддерживают на уровне системы (ядра Linux или стандартных компонентов Android) следующие классы устройств:

• Устройства ввода — клавиатуры, мыши, джойстики (HID)
• Накопители (Mass Storage)

Несколько реже:

• Сотовые модемы
• Сетевые адаптеры
• Вебкамеры

Хабы поддерживаются при наличии полноценных хост-портов, но не поддерживаются на портах OTG.

Подробнее список устройств, поддерживаемых на уровне ядра Linux, можно получить в sysfs:

$ ls /sys/bus/usb/drivers

Если же модуль в принципе доступен в исходниках ядра Linux, но не включен в Android — не стоит рассчитывать на то, что его получится собрать и расставить на все целевые системы.

Однако, начиная с Android 3.1 (API 12), в системе содержатся средства, достаточные для поддержки на уровне приложения любой USB периферии. Данные средства описаны в разделе USB Host руководства по Android API. Здесь же я хочу привести примеры реальной работы с некоторыми видами устройств.

Права доступа

Как и для прочих действий, Android требует, чтобы приложение получило разрешение на доступ к USB периферии. Существует 2 способа получить такое разрешение:

• Задекларировать список устройств в AndroidManifest
• Явно показать пользователю диалог “разрешить”

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

Итак, нам необходимо добавить в манифест следующее:

А в res/xml/device_filter.xml вписать следующее:

Отмечу, что хотя общепринято указывать VID:PID в 16-ричной системе счисления, здесь они должны быть указаны в десятичной. В документации заявляется, что возможно указание только класса, без VID и PID, но у меня это не стало работать.

Принтеры

На примере принтера я покажу, как непосредственно использовать API android.hardware.usb. На уровне передачи данных все принтеры поддерживают стандартый класс USB устройств:

Класс предельно простой. В рамках этого класса устройство должно поддерживать:

• Обязательный bulk out endpoind для отправки данных на принтер
• Опциональный bulk in endpoind для получения статуса принтера
• 3 управляющих запроса

Код, приведенный ниже, предоставляет функциональность, аналогичную устройству /dev/usb/lp в Linux. Далее нам нужен фильтр, преобразующий исходный документ в пакет данных, понятный конкретной модели принтера. Но это тема иной статьи. Как один из вариантов — можно собрать ghostscript с помощью NDK.

Для работы с устройством нам в первую очередь нужно:

1. Найти устройство. В примере для простоты я ищу первый попавшийся:

2. Получить endpoint’ы:

3. Непосредсвенно открыть устройство:

4. После этого мы можем читать и писать в устройство:

5. По завершении работы — закрыть устройство:

Преобразователи USB-Serial

В отличие от притеров, преобразователи USB-Serial гораздо менее стандартизированы. Существует несколько распространенных чипов, для которых существенно отличается установка параметров последовательного порта — битрейта, чётности и проч. К счастью, есть библиотека github.com/mik3y/usb-serial-for-android, поддерживающая практически все существующие чипы. Библиотека полностью скрывает USB API, сводя все необходимые действия к минимуму вызовов с минимумом параметров.

1. Найти и открыть устройство:

2. Установить параметры последовательного порта:

3. Читать и писать в порт:

4. По завершении работы — закрыть порт:

Резюме

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

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

Источник

Two methods for Android to obtain USB permission

preface:

Recently, several USB modules have been used in Android platform, so it is necessary to obtain USB permission

##There are two ways to obtain USB permission:

1、 Directly in AndroidManifest.xml The file is configured as follows:

It should be noted that:

Where device_ filter.xml The available USB devices are listed in. When the USB device is connected to the mobile phone, the app will automatically ask if it is allowed to obtain the permission of the USB device.

device_ filter.xml The placement position is shown in the following figure:

device_ filter.xml The contents in the

USB devices are defined by vendor ID and product ID. here is a summary of Linux USB device manufacturer ID and product ID, which can be used as a reference for Android USB devices.

2、 Dynamic code acquisition

2.1 code (provided that the USB device to apply for USB permission has been located)

2.2 registered broadcast recipients

summary

The above are two ways for Android to obtain USB permission. I hope it will be helpful for you. If you have any questions, please leave me a message, and the editor will reply to you in time. Thank you very much for your support to the developeppaer website!
If you think this article is helpful to you, welcome to reprint, please indicate the source, thank you!

Источник

USB Host

In this document

Related Samples

When your Android-powered device is in USB host mode, it acts as the USB host, powers the bus, and enumerates connected USB devices. USB host mode is supported in Android 3.1 and higher.

API Overview

Before you begin, it is important to understand the classes that you need to work with. The following table describes the USB host APIs in the android.hardware.usb package.

Table 1. USB Host APIs

Class	Description
UsbManager	Allows you to enumerate and communicate with connected USB devices.
UsbDevice	Represents a connected USB device and contains methods to access its identifying information, interfaces, and endpoints.
UsbInterface	Represents an interface of a USB device, which defines a set of functionality for the device. A device can have one or more interfaces on which to communicate on.
UsbEndpoint	Represents an interface endpoint, which is a communication channel for this interface. An interface can have one or more endpoints, and usually has input and output endpoints for two-way communication with the device.
UsbDeviceConnection	Represents a connection to the device, which transfers data on endpoints. This class allows you to send data back and forth sychronously or asynchronously.
UsbRequest	Represents an asynchronous request to communicate with a device through a UsbDeviceConnection .
UsbConstants	Defines USB constants that correspond to definitions in linux/usb/ch9.h of the Linux kernel.

In most situations, you need to use all of these classes ( UsbRequest is only required if you are doing asynchronous communication) when communicating with a USB device. In general, you obtain a UsbManager to retrieve the desired UsbDevice . When you have the device, you need to find the appropriate UsbInterface and the UsbEndpoint of that interface to communicate on. Once you obtain the correct endpoint, open a UsbDeviceConnection to communicate with the USB device.

Android Manifest Requirements

The following list describes what you need to add to your application’s manifest file before working with the USB host APIs:

• Because not all Android-powered devices are guaranteed to support the USB host APIs, include a element that declares that your application uses the android.hardware.usb.host feature.
• Set the minimum SDK of the application to API Level 12 or higher. The USB host APIs are not present on earlier API levels.
• If you want your application to be notified of an attached USB device, specify an and element pair for the android.hardware.usb.action.USB_DEVICE_ATTACHED intent in your main activity. The element points to an external XML resource file that declares identifying information about the device that you want to detect.

In the XML resource file, declare elements for the USB devices that you want to filter. The following list describes the attributes of . In general, use vendor and product ID if you want to filter for a specific device and use class, subclass, and protocol if you want to filter for a group of USB devices, such as mass storage devices or digital cameras. You can specify none or all of these attributes. Specifying no attributes matches every USB device, so only do this if your application requires it:

• vendor-id
• product-id
• class
• subclass
• protocol (device or interface)

Save the resource file in the res/xml/ directory. The resource file name (without the .xml extension) must be the same as the one you specified in the element. The format for the XML resource file is in the example below.

Manifest and resource file examples

The following example shows a sample manifest and its corresponding resource file:

In this case, the following resource file should be saved in res/xml/device_filter.xml and specifies that any USB device with the specified attributes should be filtered:

Working with Devices

When users connect USB devices to an Android-powered device, the Android system can determine whether your application is interested in the connected device. If so, you can set up communication with the device if desired. To do this, your application has to:

1. Discover connected USB devices by using an intent filter to be notified when the user connects a USB device or by enumerating USB devices that are already connected.
2. Ask the user for permission to connect to the USB device, if not already obtained.
3. Communicate with the USB device by reading and writing data on the appropriate interface endpoints.

Discovering a device

Your application can discover USB devices by either using an intent filter to be notified when the user connects a device or by enumerating USB devices that are already connected. Using an intent filter is useful if you want to be able to have your application automatically detect a desired device. Enumerating connected USB devices is useful if you want to get a list of all connected devices or if your application did not filter for an intent.

Using an intent filter

To have your application discover a particular USB device, you can specify an intent filter to filter for the android.hardware.usb.action.USB_DEVICE_ATTACHED intent. Along with this intent filter, you need to specify a resource file that specifies properties of the USB device, such as product and vendor ID. When users connect a device that matches your device filter, the system presents them with a dialog that asks if they want to start your application. If users accept, your application automatically has permission to access the device until the device is disconnected.

The following example shows how to declare the intent filter:

The following example shows how to declare the corresponding resource file that specifies the USB devices that you’re interested in:

In your activity, you can obtain the UsbDevice that represents the attached device from the intent like this:

Enumerating devices

If your application is interested in inspecting all of the USB devices currently connected while your application is running, it can enumerate devices on the bus. Use the getDeviceList() method to get a hash map of all the USB devices that are connected. The hash map is keyed by the USB device’s name if you want to obtain a device from the map.

If desired, you can also just obtain an iterator from the hash map and process each device one by one:

Obtaining permission to communicate with a device

Before communicating with the USB device, your application must have permission from your users.

Note: If your application uses an intent filter to discover USB devices as they’re connected, it automatically receives permission if the user allows your application to handle the intent. If not, you must request permission explicitly in your application before connecting to the device.

Explicitly asking for permission might be neccessary in some situations such as when your application enumerates USB devices that are already connected and then wants to communicate with one. You must check for permission to access a device before trying to communicate with it. If not, you will receive a runtime error if the user denied permission to access the device.

To explicitly obtain permission, first create a broadcast receiver. This receiver listens for the intent that gets broadcast when you call requestPermission() . The call to requestPermission() displays a dialog to the user asking for permission to connect to the device. The following sample code shows how to create the broadcast receiver:

To register the broadcast receiver, add this in your onCreate() method in your activity:

To display the dialog that asks users for permission to connect to the device, call the requestPermission() method:

When users reply to the dialog, your broadcast receiver receives the intent that contains the EXTRA_PERMISSION_GRANTED extra, which is a boolean representing the answer. Check this extra for a value of true before connecting to the device.

Communicating with a device

Communication with a USB device can be either synchronous or asynchronous. In either case, you should create a new thread on which to carry out all data transmissions, so you don’t block the UI thread. To properly set up communication with a device, you need to obtain the appropriate UsbInterface and UsbEndpoint of the device that you want to communicate on and send requests on this endpoint with a UsbDeviceConnection . In general, your code should:

• Check a UsbDevice object’s attributes, such as product ID, vendor ID, or device class to figure out whether or not you want to communicate with the device.
• When you are certain that you want to communicate with the device, find the appropriate UsbInterface that you want to use to communicate along with the appropriate UsbEndpoint of that interface. Interfaces can have one or more endpoints, and commonly will have an input and output endpoint for two-way communication.
• When you find the correct endpoint, open a UsbDeviceConnection on that endpoint.
• Supply the data that you want to transmit on the endpoint with the bulkTransfer() or controlTransfer() method. You should carry out this step in another thread to prevent blocking the main UI thread. For more information about using threads in Android, see Processes and Threads.

The following code snippet is a trivial way to do a synchronous data transfer. Your code should have more logic to correctly find the correct interface and endpoints to communicate on and also should do any transferring of data in a different thread than the main UI thread:

To send data asynchronously, use the UsbRequest class to initialize and queue an asynchronous request, then wait for the result with requestWait() .

For more information, see the AdbTest sample, which shows how to do asynchronous bulk transfers, and the MissileLauncher sample, which shows how to listen on an interrupt endpoint asynchronously.

Terminating communication with a device

When you are done communicating with a device or if the device was detached, close the UsbInterface and UsbDeviceConnection by calling releaseInterface() and close() . To listen for detached events, create a broadcast receiver like below:

Creating the broadcast receiver within the application, and not the manifest, allows your application to only handle detached events while it is running. This way, detached events are only sent to the application that is currently running and not broadcast to all applications.

Источник