Android USB permissions: Stop showing USB permission dialogs


We have noticed that Android's USB permissions are a headache for many people. There are many discussions about this topic on Stack Overflow, but the answers are not always correct or complete.

In the second of a two-part blog series, we will give answers on how to stop the Android OS from asking for USB user permissions once and for all.

We already gave you an introduction on ...

  • what a USB permission is,
  • when an application asks for permission,
  • and why the Android USB permission dialog is an important aspect in Androids device security strategy.

The first part of the blog series contains a tutorial on the implementations you need to make in your app to execute the USB permission dialog correctly. With the correct changes in place, the USB permission dialog will be properly stored in Android OS and will no longer be displayed in future. The app remembers, after asking once, that a specific USB device has the permission to be used by an application.

Missed the first blog? Catch up on Android USB permissions - Part 1!

Are you looking for specific information within this article? Use the table of contents on your right to jump forward.

Precautionary safety advice

A few words of caution before we dive deeper into the how-tos of stopping USB permission dialogs.

Application and USB security are critical aspects of maintaining secure Android devices. Unknown apps can pose significant risks, including the introduction of malware and unauthorized access to sensitive data via USB devices.

To protect against these risks, the USB permission dialog has its right to exist. However, there are some cases where recurring USB Android confirmation dialogs are not useful. For those cases we present solutions to change how Android USB permissions for your Android devices behave.

Please take security concerns into consideration before implementing any changes.

Tutorial: How to stop Android from asking for USB permission permanently for all connected USB devices

This approach helps you in case you are using your own custom Android ROM. It implements changes in compile time during the build process.

After implementation you will not get a USB permission dialog at all when a new or known USB device is connected. The permission is granted by default. All apps have the permission to access all USB devices whenever they are connected, or your device is rebooted.

Here’s what you need to do.

Option 1: Hardcode the USB flag value

Android consists of more than 1000+ projects. One of them is located in frameworks/base/ and defines the behavior-based actions for the ROM. One example for a behavior-based action is what’s happening after pressing the power button. Another example is whether a user should be asked for their permission for apps to access USB devices. This is the action we need to look into.

Open the file frameworks/base/core/res/res/values/config.xml in a text editor of your choice. The USB flag that causes the default permission dialog behavior is:

<bool name="config_disableUsbPermissionDialogs">false</bool>

It can be set to true like this:

<bool name="config_disableUsbPermissionDialogs">true</bool>

If true, devices running a ROM with disabled USB permission dialogs will not ask the user for permission but grant it automatically for all apps requesting USB device access.

Do not set this for devices with GMS. Doing so will cause you to fail CTS.

Thoughts on hardcoding the USB flag value

Hardcoding default files to customize a product at build time is not the optimal way of implementing changes in AOSP. Google is regularly changing the AOSP codebase resulting in conflicts during updates if values in files were manually modified before.

Please note that it is highly important to regularly patch devices and update them to newer versions of Android. Don't let your customization efforts get in the way of your security standards. This is not the place to compromise.

Option 2: Create an overlay

The better way to customize AOSP to your specific needs is to use resource overlays. They are applied on top of the defaults and are not affected by code changes pushed by Google. Therefore, updates are not resulting in conflicts and your customizations are safely transferred to newer versions of the AOSP.

Instead of changing the USB flag in the .xml files of AOSP you create a resource overlay file to customize the framework and included package resources.

Thoughts on using overlays

Overlays might be more complicated in implementing than hardcoding the actual default files. Please make sure you possess the knowledge needed to make adequate customizations to AOSP.

In case you do not know how to continue from here and have no experts inhouse to help you out, get in contact with our team! We are happy to help. Emteria is your partner for realizing custom Android ROMs without USB permission confirmation dialogs and much more. We provide a wide set of customization options fulfilling all your requirements.

You’ve made it

Whether you have hardcoded your customization or used overlays you will not get a USB permission dialog at all when a new or known USB device is connected to your custom Android device. Congrats you customized AOSP to fit your requirements!

Throwback to part 1

Teach your app to Remember granted USB permissions
Learn to implement USB permissions correctly in Android apps. Stop Android from asking for permission each time a USB device is reconnected.
Learn more in Android USB permissions - Part 1

Taking a glance back at the first episode of this article, the approach explained in this second part has some advantages the implementation in your application can not solve (and is not meant to).

If you've read the first part, you remember that you need the vendor-id and product-id of your USB peripherals to remember the permissions given and stop Android from asking each time USB devices with one of those IDs are reconnected, or the OS is rebooted. Relying on those IDs is unreliable since vendors change IDs and they are hard to identify in the first place.

So one advantage of the solution introduced in this second part is that you are not bound to unreliable and changing vendor-id and product-id combinations. But the main advantage of this approach is that the dialog does not have to be confirmed at all.

This is great when:

  • You run an app in kiosk mode on a single purpose device and there is no option to install additional apps.
  • You are personally in control of device maintenance and security (personal or business use case) and there are no other users posing a security risk.
  • Your hardware is designed to prevent users access with other USB devices.

However, if this is not the case, we do not recommend choosing this solution. If you provide your devices to a group of users who can install third-party applications and connect a wide range of USB devices, disabling Android USB permission requests poses a high security risk.

Wrap up and final thoughts on how to stop Android to ask for USB permissions

This article focused on a way to implement changes directly in the OS, rather than your application. If you followed our instructions Android will not ask for USB permissions for your USB device ever again.

Please keep in mind to only use apps and USB devices from trusted sources. In case you stumble across issues, or you are looking for a fast and professional solution to this challenge contact us.

Emteria offers custom Android ROMs without USB permission confirmation dialogs and other customizations. We also provide a wide set of enterprise features depending on your requirements. Your custom Android OS receives regular Over-the-Air software updates and security patches, and the emteria's device management solution empowers fleet managers to manage devices remotely.



Build unique Android products, boost device performance

See why emteria is the chosen Android™ customization & management platform for product builders — build Android products based on your requirements.

Book live demo
Group 3113

Table of contents

emteria Demo
See emteria in action