funwithlinux blog

Should You Run Android Studio with Sudo on Linux? Fixing Permission Issues & Best Practices

If you’re an Android developer using Linux, you’ve likely encountered the dreaded "Permission denied" error while working with Android Studio. Whether it’s installing the Android SDK, updating plugins, or launching the emulator, permission issues can grind your workflow to a halt. The knee-jerk reaction for many is to prefix the command with sudo (e.g., sudo ./studio.sh), assuming root privileges will "fix" the problem. But is this safe?

In this blog, we’ll dive deep into why running Android Studio with sudo is risky, common permission issues that lead to this temptation, and how to resolve them properly without compromising your system’s security. We’ll also cover best practices to avoid permission headaches altogether. By the end, you’ll know exactly how to keep Android Studio running smoothly on Linux—without reaching for sudo.

2026-01

Table of Contents#

  1. Understanding the "Sudo" Temptation: Why Do Permission Issues Happen?
  2. The Hidden Dangers: Risks of Running Android Studio with Sudo
  3. Common Permission Issues in Android Studio (and Their Real Fixes)
  4. Best Practices to Avoid Permission Issues Altogether
  5. When (If Ever) Should You Use Sudo?
  6. Conclusion
  7. References

1. Understanding the "Sudo" Temptation: Why Do Permission Issues Happen?#

Linux is a multi-user operating system with strict file ownership and permission controls. When you install software or modify system files, you often need root privileges (via sudo). However, Android Studio is designed to run as a regular user, not root.

Permission issues typically arise for one of these reasons:

  • Incorrect Installation Path: If you installed Android Studio in a system-wide directory (e.g., /opt, /usr/local) or the Android SDK in a root-owned folder, your user account may lack write access to these locations.
  • Accidental Root Usage: Previously running Android Studio or its tools (e.g., sdkmanager, avdmanager) with sudo created files/directories owned by root instead of your user.
  • Corrupted User Directories: Android Studio stores configuration, caches, and project data in user-specific directories (e.g., ~/.config, ~/.local, ~/.android). If these directories have incorrect ownership or permissions, errors occur.

When faced with errors like "Cannot write to SDK directory" or "Failed to install plugin," it’s tempting to run sudo ./studio.sh to bypass restrictions. But this "quick fix" often creates more problems than it solves.

2. The Hidden Dangers: Risks of Running Android Studio with Sudo#

Running Android Studio as root (sudo) may temporarily resolve a permission error, but it introduces significant risks:

Security Vulnerabilities#

Android Studio interacts with the internet (to download SDKs, plugins, and updates), executes third-party code (via plugins, Gradle scripts, or dependencies), and communicates with connected Android devices. Running it as root:

  • Exposes your entire system to potential malware or vulnerabilities in plugins/updates (e.g., a malicious plugin could delete system files if run as root).
  • Grants unrestricted access to sensitive system resources (e.g., network interfaces, hardware) to Android Studio and its subprocesses.

File Ownership Nightmares#

Any files created or modified by Android Studio while running as root (e.g., SDK packages, AVD images, Gradle caches, or project files) will be owned by root, not your user. Later, when you run Android Studio normally (without sudo), you’ll encounter new permission errors because your user can’t read/write root-owned files. For example:

  • You can’t update the SDK because the sdk directory is now owned by root.
  • The Android Emulator fails to launch because AVD files in ~/.android/avd are root-owned.

Dependency and Environment Conflicts#

Root uses a different environment (e.g., PATH, environment variables, and system libraries) than your user. This can cause:

  • Gradle to use the wrong JDK version or dependencies.
  • Emulator or adb (Android Debug Bridge) to fail due to mismatched library paths.

Emulator and Device Risks#

The Android Emulator and adb (used to debug physical devices) rely on user-space configurations. Running them as root:

  • May corrupt AVD images or prevent the emulator from launching (due to root-owned temporary files).
  • Risks bricking or compromising connected Android devices (e.g., adb root can modify system partitions on rooted devices).

If you’re developing commercial software, running critical tools as root could violate security policies or expose your organization to liability if a breach occurs.

Bottom line: sudo is not a solution—it’s a band-aid that masks underlying permission issues and creates new ones.

3. Common Permission Issues in Android Studio (and Their Real Fixes)#

Instead of using sudo, let’s fix the root cause of permission errors. Below are step-by-step solutions for the most common issues.

Issue 1: SDK Installation/Update Failures#

Error Examples:

  • "Failed to update SDK: Permission denied"
  • "Cannot write to /opt/android-sdk/build-tools"

Why It Happens:
The Android SDK is stored in a directory your user can’t write to (e.g., /opt/android-sdk).

Fix:
Choose one of these options:

Option A: Move the SDK to a User-Writable Location#

The safest long-term fix is to store the SDK in your user directory (e.g., ~/Android/Sdk), which your user already owns.

  1. Open Android Studio.
  2. Go to File > Project Structure > SDK Location (or Configure > SDK Manager on the welcome screen).
  3. Click "Edit" next to "Android SDK Location."
  4. Select a new path like ~/Android/Sdk (create the directory if needed).
  5. Click "OK" and let Android Studio migrate or reinstall the SDK to this location.

Option B: Take Ownership of the Existing SDK Directory#

If you want to keep the SDK in a system directory (e.g., /opt/android-sdk), change its ownership to your user:

# Replace /path/to/sdk with your actual SDK path (e.g., /opt/android-sdk)
sudo chown -R $USER:$USER /path/to/sdk
  • -R ensures recursive ownership change (applies to all subdirectories/files).
  • $USER:$USER sets the owner and group to your current user.

Issue 2: Plugin/Update Errors#

Error Examples:

  • "Failed to install plugin: Permission denied in ~/.local/share/Google/AndroidStudio"
  • "Cannot update Android Studio: Read-only file system"

Why It Happens:
Android Studio’s configuration (~/.config/Google/AndroidStudio<version>), cache (~/.cache/Google/AndroidStudio<version>), or plugin directories (~/.local/share/Google/AndroidStudio<version>) are owned by root (from a previous sudo run).

Fix:
Restore ownership of these user directories to your account:

# Replace <version> with your Android Studio version (e.g., 2023.1.1)
sudo chown -R $USER:$USER ~/.config/Google/AndroidStudio<version>
sudo chown -R $USER:$USER ~/.cache/Google/AndroidStudio<version>
sudo chown -R $USER:$USER ~/.local/share/Google/AndroidStudio<version>

To find your Android Studio version, check Help > About in Android Studio.

Issue 3: Emulator (AVD) Launch or Creation Failures#

Error Examples:

  • "AVD Manager: Cannot create AVD directory"
  • "Emulator: PANIC: Cannot find AVD system path. Please define ANDROID_SDK_ROOT"

Why It Happens:
The Android Virtual Device (AVD) system stores images and configurations in ~/.android/avd. If this directory (or ~/.android itself) is owned by root, the emulator can’t read/write to it.

Fix:
Take ownership of the ~/.android directory:

sudo chown -R $USER:$USER ~/.android

Issue 4: Gradle Cache or Build Failures#

Error Examples:

  • "Gradle: Could not create parent directory for lock file"
  • "Cannot write to ~/.gradle/caches"

Why It Happens:
Gradle caches dependencies and build data in ~/.gradle. If this directory is root-owned, Gradle (run by Android Studio) can’t write to it.

Fix:
Restore ownership of the Gradle directory:

sudo chown -R $USER:$USER ~/.gradle

Issue 5: ADB "Permission Denied" Errors#

Error Examples:

  • "adb: error: failed to get feature set: no permissions (user in plugdev group; are your udev rules wrong?)"
  • "adb server version (41) doesn’t match this client (39); killing..."

Why It Happens:
This is often due to two issues:

  1. udev Rules for Android Devices: Linux requires udev rules to recognize connected Android devices.
  2. Root-Owned ADB Files: Previously running adb with sudo created root-owned files in /tmp (e.g., /tmp/adb.<random>).

Fix:

For Device Recognition (udev Rules):#

Follow Google’s ADB setup guide to configure udev rules. For most Linux distros:

# Create a udev rule file (requires sudo)
sudo nano /etc/udev/rules.d/51-android.rules

Add this line (replace <username> with your Linux username):

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev", OWNER="<username>"

(Find your device’s idVendor with lsusb.)

Reload udev rules and restart adb:

sudo udevadm control --reload-rules
sudo udevadm trigger
adb kill-server
adb start-server

For Root-Owned ADB Files:#

Delete root-owned adb files in /tmp and restart adb:

sudo rm -f /tmp/adb*  # Remove root-owned adb temp files
adb kill-server       # Stop any running adb server
adb start-server      # Start adb as your user

4. Best Practices to Avoid Permission Issues Altogether#

Prevention is better than cure. Follow these practices to avoid permission headaches:

Install Android Studio in Your User Directory#

Instead of system-wide paths like /opt, install Android Studio in your user folder (e.g., ~/Applications/AndroidStudio). This ensures you own all files by default.

  1. Download the Android Studio tarball from the official site.
  2. Extract it to ~/Applications: 
    mkdir -p ~/Applications
tar -xzf android-studio-*.tar.gz -C ~/Applications/
  3. Launch it via ~/Applications/android-studio/bin/studio.sh (add a desktop shortcut for convenience).

Set the Android SDK Path to a User-Writable Location#

During initial setup, choose ~/Android/Sdk as your SDK path. This directory is owned by your user, so no write permissions are needed.

Never Run Android Studio or Tools with Sudo#

Avoid sudo ./studio.sh, sudo sdkmanager, or sudo avdmanager. If you need to run a tool with elevated privileges (e.g., installing system dependencies), use sudo only for that specific command (not Android Studio itself).

Regularly Check File Ownership#

Periodically verify that critical directories are owned by your user:

# Check SDK ownership
ls -la ~/Android/Sdk  # Should show your username as owner
 
# Check Android Studio config
ls -la ~/.config/Google/AndroidStudio<version>
 
# Check AVD directory
ls -la ~/.android/avd

Use a Dedicated Development User (Optional)#

For advanced users, create a separate user account for development to isolate project files and permissions from your main account.

When (If Ever) Should You Use Sudo?#

Almost never for running Android Studio itself. The only valid use cases for sudo are:

  • Installing System Dependencies: For example, installing 32-bit libraries required by the Android Emulator: 
    sudo apt install libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 libbz2-1.0:i386  # Ubuntu/Debian
  • Configuring udev Rules for ADB: As shown earlier, sudo is needed to edit /etc/udev/rules.d/.
  • Repairing Root-Owned Files: If you accidentally ran Android Studio with sudo, use sudo chown to restore ownership (as covered in Section 3).

Conclusion#

Running Android Studio with sudo on Linux is a risky and unnecessary practice. It exposes your system to security threats, causes file ownership conflicts, and leads to persistent permission errors. Instead, fix the root cause by adjusting file ownership, using user-writable directories, and following best practices for installation.

By keeping Android Studio and its tools in user-owned directories and avoiding sudo, you’ll ensure a smooth, secure development experience—free from permission headaches.

References#