How to Install Android Studio on Linux

Installing Android Studio on Linux starts with a 1.5 GB download that unpacks to 3.5 GB before the Android SDK arrives. The dependency list has gone stale. The official page still asks 64-bit Ubuntu users for i386 libraries, while every 32-bit binary inside the archive is a payload for a phone, not for your desktop.

The three things that decide whether the IDE launches are free disk space, an install directory your user can write to, and KVM for the emulator. I checked each one against the archive itself rather than against the instructions around it.

There Is No apt Package, So the Route Is the Decision

Google ships Android Studio as a tarball and a store listing, not as a package in your distribution’s repository. That leaves one decision before any command: which route you want to maintain afterwards.

The current stable release is Android Studio Quail 4, version 2026.1.4, and the Linux archive is named android-studio-quail4-linux.tar.gz. Both the codename and the build number sit in that file name, so it is the fastest way to tell whether the page you are reading is current.

The route with the shortest life was the Launchpad PPA, and it is the one to skip. The two routes worth choosing between are the tarball, where you own the directory, and the snap, where the store owns the update.

What the Machine Needs Before the Download

I would spend a minute on these three checks before the download, because a truncated 1.5 GB transfer costs more than the check does.

uname -m
free -h
df -h ~

Every machine Google supports for this release is x86_64, and the requirements page states plainly that ARM-based Linux is not supported. A Raspberry Pi or an ARM laptop stops here rather than five gigabytes later.

Memory is the simpler of the two, with 8 GB as the supported minimum for the IDE and 16 GB when the emulator runs beside it, because each virtual device you keep open allocates about 4 GB. The recommended figure is 32 GB once several emulators are in play at the same time.

Disk is where the official numbers and the measured ones separate. I measured both on one disk, and the archive came to 1,536,243,986 bytes while the extracted tree reached 3.5 GB, before the setup wizard pulls a single SDK platform or system image.

So plan for that 3.5 GB to land on the disk that holds your home directory, then keep room for the SDK, the emulator system images, and the Gradle caches a first build creates.

Then there is the dependency list. Google’s install page still carries an apt line for i386 libraries under 64-bit Ubuntu, and that instruction dates from an era when the SDK tools shipped 32-bit binaries.

I scanned every executable in the 2026.1.4 archive to check, and the split is one-sided. Of its ELF files, 22 are 32-bit, and all 22 sit under plugins/android/resources or plugins/android-ndk/resources as device payloads for armeabi-v7a and x86 phones, while nothing under jbr or lib is 32-bit.

The archive no longer depends on i386 libraries to start on a current 64-bit distribution, whatever the install page still lists.

The JDK question has an answer that surprises people who install Java first out of habit. Android Studio bundles the JetBrains Runtime, an enhanced JDK that Google tests the IDE against, which is why the download is 1.5 GB.

Install a system JDK only when you plan to run Gradle builds from a terminal. The Android Gradle Plugin 9.4 that ships with this release requires JDK 17, so openjdk-17-jdk or openjdk-21-jdk is the sensible floor, and neither one is needed for the IDE to start.

Install Android Studio From the Tarball

The tarball route works on any 64-bit distribution with glibc 2.31 or newer, and it is the only route where you pick the install directory.

Download and verify the archive

The download page sits behind a licence agreement, so accept the terms there first and use the link it hands you. The file name and the folder in its URL both carry the build number 2026.1.4.7.

cd ~/Downloads
curl -LO https://edgedl.me.gvt1.com/android/studio/ide-zips/2026.1.4.7/android-studio-quail4-linux.tar.gz
echo "4be240083df5ada290975d87d60fc212a3d38d4f258a1250989885a9dbc79980  android-studio-quail4-linux.tar.gz" > studio.sha256
sha256sum -c studio.sha256

I verified the bytes against the hash published on that page before unpacking anything, so a passing check prints the archive name followed by OK and exits with status 0. Anything else means the bytes on disk are not the bytes Google published, and the useful next move is to delete the file and download it again rather than unpack a truncated archive.

Unpack it where you can write

My tar command walkthrough takes the option string apart if you want to know which flag does what. The location decision matters more here, since the official steps suggest /usr/local for a single user or /opt for a machine shared by several, and both decide who owns the files.

tar -xzf android-studio-quail4-linux.tar.gz
du -sh android-studio*

The extraction took just over a minute, and I measured the tree at 3.5 GB with the launcher waiting in its bin directory. A sudo extraction into /opt leaves root as the owner, so the write test below answers what that costs you.

sudo tar -xzf android-studio-quail4-linux.tar.gz -C /opt
ls -ld /opt/android-studio
test -w /opt/android-studio && echo writable || echo "not writable by this user"

Launch it and open the wizard

The launcher is a shell script, and I read the archive’s own install notes for this step: running it creates the configuration directory and opens the import dialog.

cd ~/android-studio/bin
./studio.sh

Settings land in ~/.config/Google/AndroidStudio2026.1.4, and the setup wizard is the step that downloads the SDK, so the disk number from the previous section grows here. Declining the wizard’s standard install and pointing the SDK at a directory you choose keeps the toolchain separate from the IDE.

The IDE does not need the Java on your PATH, which I confirmed by reading the runtime the archive ships instead of assuming it.

That runtime is the JetBrains Runtime 25.0.3, and the product descriptor in the same directory asks for Java 21 at minimum. When a startup message complains about the JDK, the file to read is product-info.json rather than the java version of your shell.

Add a menu entry

Android Studio can write its own launcher from the menu bar through Tools and then Create Desktop Entry. If you would rather not open the IDE first, the same file written by hand in your applications directory does the job, with the paths pointing at wherever you unpacked the archive.

[Desktop Entry]
Type=Application
Name=Android Studio
Exec=/home/USER/android-studio/bin/studio.sh %f
Icon=/home/USER/android-studio/bin/studio.svg
Terminal=false
Categories=Development;IDE;
StartupWMClass=jetbrains-studio

I validated the file below with desktop-file-validate, because a single wrong key produces an entry that appears in the menu and then does nothing.

desktop-file-validate ~/.local/share/applications/android-studio.desktop

Install the Snap and Let It Update Itself

The snap route replaces the directory you maintain with a package the store maintains, which is the reason to choose it.

sudo snap install android-studio --classic

The stable channel currently carries version 2026.1.4.7-quail4 as revision 242, published on 1 September 2026 by Snapcrafters. The store page states plainly that the snap is maintained by that community publisher and is not necessarily endorsed by the upstream developers, which is worth knowing before you make it the only Android Studio on the machine.

The classic flag is not decoration. It removes the snap sandbox so the IDE can reach your home directory, your Android SDK and the USB debugging rules, and a strict snap cannot do that job. If they are new to you, the snaps introduction covers the rest.

• Choose the snap when you want updates without thinking about them, and when your distribution has snapd enabled already.
• Stay with the tarball when you need a specific release, a second version side by side, or a machine where nobody runs a snap daemon.
• Skip both if you want the store to manage canary and stable together, and use JetBrains Toolbox, which is built for that.

The channel map for this snap carries one limit worth stating before you commit, and it lists amd64 for stable, candidate and edge. On an ARM machine the route does not exist, so the tarball is the only path there.

Flathub hosts a third community build of the same IDE, and its own listing warns that the package is not verified by the Android Open Source Project. I would take the snap on a desktop that already runs snapd, and the tarball everywhere else.

Removing a snap is one command, and it takes the application directory with it while leaving your projects where they are.

sudo snap remove android-studio

When the Launch or the Emulator Stops

The failures that follow a successful install are visible before the IDE opens, and each one has a check that answers it in a single command.

The emulator needs KVM

The emulator runs without hardware acceleration, slowly enough that it is tempting to give up before the home screen finishes drawing. Linux acceleration comes through KVM, and the check fits in three commands.

grep -Ec '(vmx|svm)' /proc/cpuinfo
sudo apt install cpu-checker
sudo kvm-ok

A count of 1 or more means the flags are there, and kvm-ok then answers with either that /dev/kvm exists and KVM acceleration can be used, or that your CPU does not support KVM extensions. That second answer is what a virtual machine returns when nested virtualization is switched off, and no Android Studio setting changes it.

When the flags are present but the device is not, the missing piece is usually group membership. Add your user to the kvm group, sign out and back in, and the emulator picks the accelerated path. Inside the SDK the same question has a shorter answer, because the emulator binary reports it directly.

~/Android/Sdk/emulator/emulator -accel-check

A root-owned install directory

Extracting into /opt with sudo is the usual way to end up with an installation your own user cannot modify. The listing shows root as the owner, and the write test settles what that means for you.

I ran that write test against a root-owned /opt directory and it answered not writable by this user. That state is not broken, it is just in someone else’s name, and there are two repairs. Re-extract the archive into a directory your user owns and move the SDK to match, or keep the root-owned tree and run the replacement steps with sudo each time a new release lands.

The second option costs a password per release, since the IDE’s own update path cannot write there without elevation.

The launcher picks a runtime you did not expect

The startup script does not jump straight to the bundled runtime. I read its search order out of the script itself, and it looks for STUDIO_JDK, then a studio.jdk directory, then the jbr directory, then JDK_HOME, then JAVA_HOME, and only then falls back to the java command on your PATH.

Before it accepts the bundled directory, it compares the architecture named inside that directory against the machine’s own. A mismatch sends the launcher to the next candidate in the list rather than stopping with an error.

That search order is why a confusing class of failures happens. When JAVA_HOME points at an older JDK, the IDE starts on the java it finds there, and then a settings screen or a plugin reports a version error that has nothing to do with the code you are writing.

The descriptor that settles it is product-info.json, which names the minimum Java version this release accepts.

Keep the SDK Off the Install Directory

The IDE is the part you replace and the SDK is the part you keep. That distinction decides the layout: unpack the IDE wherever you like, then point the SDK somewhere durable, because the next release you unpack must not land on top of a toolchain that took an hour to download.

Each release also keeps its own settings directory, which means upgrading the IDE leaves the previous configuration in place rather than overwriting it. The descriptor inside the archive names that directory, and it is the file to check when you want to know which settings tree a build will use.

grep -m1 dataDirectoryName android-studio/product-info.json

Run it after the next release and the name changes with the version, while the SDK path you chose stays where you put it. That is the arrangement that survives the upgrade you have not done yet.

Questions the Install Raises