Install Android Studio on Fedora 45 / 44: SDK and Emulator

Android Studio itself runs cleanly on Fedora, with a native Wayland window, a bundled JDK and no need for the 32-bit libraries that older guides still list. The emulator is the component that fails. On the Fedora 45 test VM, where it falls back to software rendering, it segfaulted within about half a minute of boot, and Fedora 44 logged the same SELinux denial. The same software path is likely on remote sessions and boxes without a GPU it can drive. The cause is a single SELinux permission, execheap, which the default targeted policy denies on both Fedora 45 and Fedora 44.

Original content from computingforgeeks.com - post 111437

This guide installs the official tarball, runs the setup wizard, builds a Compose app from the IDE and from the terminal, fixes the emulator crash without switching SELinux off, and then covers the Flathub package and a complete uninstall. Every number below was measured on two test boxes, bench01 on Fedora 45 and bench02 on Fedora 44, both Fedora Cloud images with the Workstation package environment installed on top, running GNOME on Wayland with SELinux enforcing.

Tested October 2026 on Android Studio Rabbit 1 (Fedora 45 and Fedora 44).

What the test boxes measured

Both boxes were KVM guests with 4 and 3 vCPUs, 12 GB and 10 GB of RAM and a 70 GB disk. The download times describe the lab link more than the software, so the build and boot times are the figures worth planning around.

Measurement	Fedora 45 (bench01)	Fedora 44 (bench02)
Studio tarball	1.5 GB, 3.6 GB extracted	1.5 GB, 3.6 GB extracted
Wizard SDK download (Standard)	2.67 GB, 4.2 GB on disk	2.67 GB, 4.2 GB on disk
First Gradle sync, new Compose project	4 m 7 s	4 m 34 s
First assembleDebug from the terminal	2 m 21 s	2 m 54 s
Clean rebuild, warm caches	9.3 s	not recorded
Debug APK	12 MB	12 MB
Emulator with SELinux defaults	SIGSEGV, exit 139	crashed, execheap AVC logged
ATD image boot after the fix (window)	71 s	58 s
Google APIs image boot after the fix	65 s	not tested
SELinux policy package	selinux-policy-targeted 45.21	selinux-policy-targeted 44.11
kernel.yama.ptrace_scope	1	0
Secret Service provider in GNOME	oo7-daemon	gnome-keyring-daemon

The ptrace and keyring rows changed between the two releases and had no visible effect on Studio in these tests. They are still the first places to look if a future Studio build misbehaves on one release and not on the other.

Step 1: Check the CPU, RAM and KVM device

Google asks for 8 GB of RAM for Studio alone, 16 GB for Studio plus the emulator, 16 GB of free disk with the emulator (8 GB for Studio alone) and a 64-bit x86 CPU with virtualization enabled in firmware. ARM Linux machines are not supported at all, and the same page calls Intel U-series laptop CPUs “not recommended”, which includes the i7-1165G7 in both test boxes. For Studio plus the emulator, the minimum also lists a GPU with 4 GB of VRAM, and the test VMs had none, so the emulator fell back to the software renderer that Step 9 is about. Confirm the virtualization flag and the KVM device node on the target machine with these two commands.

lscpu | grep -E "Virtualization|Model name"
ls -l /dev/kvm

On the Fedora 45 test box, the output showed an Intel CPU with VT-x and a world-writable KVM device.

Model name:                              11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
Virtualization:                          VT-x
Virtualization type:                     full
crw-rw-rw-. 1 root kvm 10, 232 Oct 10 12:14 /dev/kvm

Fedora creates /dev/kvm with mode 0666, so no account has to join the kvm group before running the emulator. If the device is missing, enable VT-x or AMD-V in firmware first, and use the KVM on Fedora guide for the kernel module side of the setup.

The official install page still tells Fedora users to add zlib.i686, ncurses-libs.i686 and bzip2-libs.i686 before the first launch, so it is worth checking whether that advice still holds.

rpm -q zlib.i686 ncurses-libs.i686 bzip2-libs.i686

None of the three packages was present on either box for the entire run.

package zlib.i686 is not installed
package ncurses-libs.i686 is not installed
package bzip2-libs.i686 is not installed

The wizard, the Gradle builds, the emulator and adb all worked without these packages, so that step can be skipped on current Fedora releases.

Step 2: Download and verify the tarball

The archive name now carries the release codename instead of the build number, which means older scripts that build the URL as android-studio-${VER}-linux.tar.gz download a 1.5 KB HTML error page in place of the IDE. Pull the real link from the download page with this scrape instead.

URL=$(curl -s https://developer.android.com/studio | grep -oE "https://[^\"]+ide-zips/[^\"]+-linux\.tar\.gz" | head -1)
echo $URL

On the test day the scrape returned the following link to the codename archive.

https://edgedl.me.gvt1.com/android/studio/ide-zips/2026.2.1.8/android-studio-rabbit1-linux.tar.gz

Download the file under its own name and compare its SHA-256 with the checksum published on the same page, where the final command prints 1 when the hash appears in the page source. Using the exact file name instead of a wildcard keeps the commands correct when an older archive is still in the same directory.

TARBALL=$(basename "$URL")
curl -sSL -o "$TARBALL" "$URL"
ls -lh "$TARBALL"
SUM=$(sha256sum "$TARBALL" | cut -d" " -f1)
curl -s https://developer.android.com/studio | grep -c $SUM

The checksum matched on both boxes, after downloads of 4 m 5 s on Fedora 45 and 3 m 53 s on Fedora 44.

-rw-r--r--. 1 klinsmann klinsmann 1.5G Oct 10 12:12 android-studio-rabbit1-linux.tar.gz
1

A 0 from the last command means either a truncated file or a download page that has already moved to a newer build, and in both cases the right move is to download again before extracting anything.

Step 3: Extract to /opt and launch

Unpack the archive into /opt from the same shell, so that $TARBALL is still set and every account on the machine shares a single copy of the IDE.

sudo tar -xzf "$TARBALL" -C /opt
du -sh /opt/android-studio

Extraction took 15.8 s and the tree measured 3.6 GB, and because the archive bundles its own JetBrains Runtime, the IDE needs no separate Java package from Fedora.

grep -m3 -E "\"(version|buildNumber|dataDirectoryName)\"" /opt/android-studio/product-info.json
/opt/android-studio/jbr/bin/java -version

The build metadata and the bundled runtime read the same on both releases.

  "version": "AI-262.9437.185.2621.16467767",
  "buildNumber": "262.9437.185.2621.16467767",
  "dataDirectoryName": "AndroidStudio2026.2.1",
openjdk version "25.0.3" 2026-04-21
OpenJDK Runtime Environment (build 25.0.3+-15898627-b508.16)
OpenJDK 64-Bit Server VM (build 25.0.3+-15898627-b508.16, mixed mode)

Launch the IDE from a terminal inside the desktop session as the normal user, never with sudo, because a first launch as root places the SDK, the caches and the settings under /root. The /opt/android-studio tree stays owned by root, so the IDE cannot patch itself in place. To upgrade, remove the old tree first and extract the new tarball into a clean directory. Extracting over an existing install leaves the old jars and plugins mixed in. The settings and caches in the home directory survive this.

sudo rm -rf /opt/android-studio
sudo tar -xzf "$TARBALL" -C /opt

Run that pair only for an upgrade, with Android Studio closed and after repeating Step 2 for the new release. On the Fedora 45 box this sequence replaced the tree cleanly with an older archive still sitting in the download directory. For the first install, the two commands at the start of this step are all that is needed.

/opt/android-studio/bin/studio

The IDE log on Fedora 45 recorded toolkit: sun.awt.wl.WLToolkit, which means Studio selected the native Wayland toolkit under GNOME by itself and needed no XWayland setting. The first window asks whether to send usage statistics to Google, and either answer leads to the same setup wizard.

Step 4: Run the setup wizard

Choose the Standard install type, and the Verify Settings page then lists every component that will land in ~/Android/Sdk, with the system image accounting for 2.17 GB of the 2.67 GB total.

The license page holds a single android-sdk-license entry, and after accepting it the next page confirms that the machine can run the emulator with KVM acceleration. On the lab link the downloads completed in about 12 minutes, after which the wizard created a virtual device without being asked.

That device is named Medium_Phone_API_37.0 and uses the Google Play system image, and clicking Finish opens the welcome screen with the New Project, Open and Clone Repository actions.

Step 5: Add a desktop entry

At this point GNOME shows the running IDE with a generic icon and lists nothing in the app grid, and the welcome screen has no desktop entry item under More Actions. Write a system-wide launcher file by hand now, or wait for the IDE menu option described at the end of this step, which needs an open project.

sudo vim /usr/share/applications/android-studio.desktop

Paste the following content, which is the exact file used on both test boxes.

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

Validate the file with the standard desktop-file checker before relying on it.

desktop-file-validate /usr/share/applications/android-studio.desktop && echo valid

The check printed valid on both releases. A search for “android” in the overview found the entry, and the running Studio window grouped under the proper icon instead of the generic one. Launching from the entry started /opt/android-studio/bin/studio on the test box as expected.

Once Step 6 has opened a project, the IDE can write a per-user launcher instead: the main menu has Tools > Create Desktop Entry, which asks whether to create the entry for the current user or for all users with superuser privileges. Leaving the all-users box unticked wrote a per-user file on the Fedora 45 box. The all-users option was not tested here.

cat ~/.local/share/applications/jetbrains-studio.desktop

The generated file passed desktop-file-validate and contains the following lines.

[Desktop Entry]
Version=1.0
Type=Application
Name=Android Studio
Icon=/opt/android-studio/bin/studio.svg
Exec="/opt/android-studio/bin/studio" %f
Comment=The Drive to Develop
Categories=Development;IDE;
Terminal=false
StartupWMClass=jetbrains-studio
StartupNotify=true

The per-user file needs no sudo and points at the same /opt/android-studio/bin/studio launcher as the hand-written one, so either route gives the same result in the GNOME overview. Pick one of the two routes rather than creating both files.

Step 6: Create a project and time the first Gradle sync

Click New Project, pick Empty Activity, which is the Jetpack Compose template, and give it a name, which on the test boxes was Hello Fedora with the default minimum SDK and the Kotlin DSL.

After Finish, a “Sign in to Android Studio” dialog for Gemini covers the editor, and the project import does not begin until that dialog is dismissed. On both boxes the sync log entry appears only after Skip for now was clicked. The IDE log records the real duration of that first sync.

grep -E "GradleSyncStateHolder - (Started|Gradle sync finished)" ~/.cache/Google/AndroidStudio*/log/idea.log | cut -c1-24,100-

On Fedora 45, the log shows a sync of a little over four minutes.

2026-10-10 12:44:41,128 ateHolder - Started (TRIGGER_PROJECT_NEW) sync with Gradle for project 'Hello Fedora'.
2026-10-10 12:48:46,127 ateHolder - Started setup of project 'Hello Fedora'.
2026-10-10 12:48:48,220 ateHolder - Gradle sync finished in 4 m 7 s 90 ms

Fedora 44 took 4 m 34 s for the same project. Most of that time on both boxes went into downloading the Gradle distribution and the dependencies into ~/.gradle, which shows in the disk use right after the sync.

du -sh ~/Android/Sdk ~/.gradle ~/.android/avd

The SDK is the largest of the three directories at this stage.

4.2G	/home/klinsmann/Android/Sdk
1.5G	/home/klinsmann/.gradle
513M	/home/klinsmann/.android/avd

Step 7: Build from the terminal with the bundled JDK

The Gradle wrapper needs a JDK of its own, found through JAVA_HOME or a java binary on PATH. The Workstation boxes had one from a system OpenJDK package while a minimal install may not, and pointing JAVA_HOME at the runtime inside the IDE directory keeps the terminal and the IDE on exactly the same JDK.

cd ~/AndroidStudioProjects/HelloFedora
export JAVA_HOME=/opt/android-studio/jbr
./gradlew --version | grep -E "^(Gradle|Kotlin|Launcher JVM|Daemon JVM)"

The output shows that the project template pins the daemon JDK version through gradle/gradle-daemon-jvm.properties rather than taking whatever JDK happens to be installed.

Gradle 9.6.0
Kotlin:        2.3.21
Launcher JVM:  25.0.3 (JetBrains s.r.o. 25.0.3+-15898627-b508.16)
Daemon JVM:    Compatible with Java 25, any vendor, nativeImageCapable=false (from gradle/gradle-daemon-jvm.properties)

Build the debug APK from the project directory and list the output folder.

./gradlew assembleDebug
ls -lh app/build/outputs/apk/debug/

The first terminal build, which ran against the system OpenJDK before JAVA_HOME was set, took 2 m 21 s on Fedora 45 and 2 m 54 s on Fedora 44. A clean followed by assembleDebug with warm caches took 9.3 s on Fedora 45 with the bundled runtime, and both boxes produced the same 12 MB package.

total 12M
-rw-r--r--. 1 klinsmann klinsmann 12M Oct 10 12:51 app-debug.apk
-rw-r--r--. 1 klinsmann klinsmann 405 Oct 10 12:51 output-metadata.json

Add the JAVA_HOME export to ~/.bashrc to make the bundled runtime the default in every shell, or follow the Java on Fedora guide to use the system OpenJDK packages for terminal builds instead.

Step 8: Put the SDK tools on PATH

The wizard installs the emulator and platform-tools packages but leaves them off PATH, so add these two lines to ~/.bashrc with an editor and open a new terminal afterwards.

export ANDROID_HOME=$HOME/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/emulator:$ANDROID_HOME/platform-tools

Confirm in the new terminal that the emulator detects KVM and lists the virtual device created by the wizard.

emulator -accel-check
emulator -list-avds
adb version | head -2

The output was identical on the two releases, down to the adb build.

accel:
0
KVM (version 12) is installed and usable.
accel
Medium_Phone_API_37.0
Android Debug Bridge version 1.0.41
Version 37.0.1-15733141

The sdkmanager and avdmanager tools ship in a separate Command-line tools package that the Standard setup does not include, and the next steps need them to add system images from the terminal. The zip link sits on the same download page as the IDE.

CLT=$(curl -s https://developer.android.com/studio | grep -oE "https://dl.google.com/android/repository/commandlinetools-linux-[0-9]+_latest\.zip" | head -1)
curl -sSLo /tmp/clt.zip $CLT
mkdir -p $ANDROID_HOME/cmdline-tools
unzip -q /tmp/clt.zip -d $ANDROID_HOME/cmdline-tools
mv $ANDROID_HOME/cmdline-tools/cmdline-tools $ANDROID_HOME/cmdline-tools/latest
export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin

The zip measured 174 MB. Running sdkmanager --version afterwards printed a deprecation notice pointing to a new android command in the same directory, with android sdk as the replacement for the old tool. Both commands worked on the Fedora 44 box, the Android CLI guide covers the new one in depth, and this guide keeps sdkmanager because most existing CI scripts still call it.

The last export lasts only for the current shell, so append it to ~/.bashrc as well.

echo 'export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin' >> ~/.bashrc

A new terminal on the Fedora 45 box then found both tools on PATH. Add two lighter system images next, an Automated Test Device image for headless and CI use and a Google APIs image for interactive work, and create a virtual device for each.

export JAVA_HOME=/opt/android-studio/jbr
yes | sdkmanager "system-images;android-36;google_atd;x86_64"
yes | sdkmanager "system-images;android-36;google_apis;x86_64"
echo no | avdmanager create avd -n atd36 -k "system-images;android-36;google_atd;x86_64" -d pixel_6
echo no | avdmanager create avd -n pixel36 -k "system-images;android-36;google_apis;x86_64" -d pixel_6
emulator -list-avds

On Fedora 44, avdmanager printed two “Could not load devices from … devices.xml” errors for the Play image directory and still created the device, so those lines are harmless. The ATD image downloaded in about one minute and the Google APIs image in about two on the lab link, and the two new devices appear next to the one created by the wizard.

Medium_Phone_API_37.0
atd36
pixel36

ATD images boot fast and run apps but draw no interface, so atd36 suits CI while pixel36 is the device to watch the app on.

Step 9: Fix the emulator segfault (SELinux execheap)

With the default SELinux settings, the emulator never reached the home screen on either test box, and the Fedora 44 journal shows the same denial explained below. On the Fedora 45 box the crash held for the Play image from the wizard and for the ATD image, with a window or with -no-window, and with the default, guest and swiftshader_indirect GPU modes. Started from a terminal, the emulator process ends with exit code 139.

emulator -avd atd36 -no-window -no-audio -no-snapshot 2>&1 | tail -2; echo "exit=${PIPESTATUS[0]}"

The final lines before the crash give no hint about the cause, which is why this failure tends to get blamed on the GPU or on KVM.

INFO         | emulatorSetupEnvironment: Environment scene is not required
USER_INFO    | Emulator is performing a full startup. This may take upto two minutes, or more.
exit=139

Why it crashes: avc denied { execheap } for comm=”RenderThread”

A backtrace of the core dump on Fedora 45 placed the crashing thread inside gles_swiftshader/libGLESv2.so, with signal code 2 (SEGV_ACCERR) on a jump into a block of code that SwiftShader had generated on the heap. SwiftShader is the CPU renderer the emulator uses when no host GPU is available. It compiles shaders to machine code on the heap before running them, which the Fedora targeted policy denies to processes in a user session. The denial is recorded in the journal.

sudo journalctl --since today --no-pager | grep "avc:  denied  { execheap }" | tail -2

On Fedora 45, the journal held two denials from the crashing emulator process.

Oct 10 13:17:46 bench01 audit[13914]: AVC avc:  denied  { execheap } for  pid=13914 comm="RenderThread" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Oct 10 13:17:46 bench01 audit[13914]: AVC avc:  denied  { execheap } for  pid=13914 comm="RenderThread" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0

Control runs on the Fedora 45 box confirmed the cause. In enforcing mode with the boolean off, the ATD image crashed after 23.3 s, and the guest and swiftshader_indirect GPU modes crashed after 21.5 s and 22.3 s. Turning KVM off with -accel off still crashed after 1 m 31 s, which rules out the hypervisor. With setenforce 0 and nothing else changed, the same image reached sys.boot_completed in 30.8 s and then 28.7 s. A machine whose GPU the emulator can drive directly should not use SwiftShader at all, but no such machine was part of this test, so that case remains unverified.

Allow execheap for user sessions

Fedora ships a boolean for exactly this permission, which makes permissive mode and custom policy modules unnecessary. Check the current value, enable it persistently, and read it back.

getsebool selinuxuser_execheap
sudo setsebool -P selinuxuser_execheap 1
getsebool selinuxuser_execheap

The boolean was off by default on both releases and reads on after the change.

selinuxuser_execheap --> off
selinuxuser_execheap --> on

SELinux stays in enforcing mode throughout. The cost is that any program in the login session may now execute heap memory, a protection that mainly matters against memory-corruption exploits in desktop applications. On a development workstation that runs the emulator every day that is usually an acceptable exchange, but the RHEL HIPAA profile in scap-security-guide requires this boolean off (rule sebool_selinuxuser_execheap), so a machine scanned against that profile will flag it. None of the profiles shipped for Fedora itself selects the rule. On a shared machine, switch the boolean off again with sudo setsebool -P selinuxuser_execheap 0 whenever the emulator is not in use, and see the SELinux survival guide for Fedora for how booleans fit into the rest of the policy.

Step 10: Boot an emulator and run the app

With the boolean on, the crashes stopped on both releases, although the Play Store device from the wizard still showed only the boot logo when checked in the minutes after start, and had not finished booting when last checked. Two warnings explain most of that. The emulator suggested 16384 MiB of host RAM for that device against 11926 MiB available, and it raised an “Emulator Running in Nested Virtualization” notice stating that the setup “may not work at all”, because the test boxes are themselves KVM guests. The pixel36 Google APIs device from Step 8 did boot, so start it in the background and time how long it takes to report a completed boot.

emulator -avd pixel36 -no-snapshot-load -no-boot-anim &
time (for i in $(seq 1 300); do [ "$(adb shell getprop sys.boot_completed 2>/dev/null | tr -d "\r")" = "1" ] && break; sleep 2; done); adb devices

Boot completion took 65 seconds on the Fedora 45 box.

List of devices attached
emulator-5554	device

real	1m4.844s

Install the APK built in Step 7 and launch it, where am start -W waits for the activity and reports the cold-start time in milliseconds.

adb install -r ~/AndroidStudioProjects/HelloFedora/app/build/outputs/apk/debug/app-debug.apk
adb shell am start -W -n com.example.hellofedora/.MainActivity | grep -E "Status|LaunchState|TotalTime"

The software-rendered device installed the package and started the activity cold.

Performing Streamed Install
Success
Status: ok
LaunchState: COLD
TotalTime: 6848

A 6.8 s cold start reflects software rendering inside a VM, and the same APK cold-started in 1.2 s on the ATD image, which skips most of the interface work. The emulator window shows the greeting from the template right next to the editor.

Studio says “Missing system image” for a CLI-installed image

Pressing Run in the IDE that was already open, with pixel36 selected, failed with the message “Missing system image android-36/google_apis/x86_64. on device pixel36” even though the device was running. Studio reads the SDK inventory at startup and had not noticed the package added by sdkmanager, so a restart of the IDE clears the error. After the restart, with the greeting changed from Android to Fedora, Run rebuilt the app and pushed it to the device in one step.

A UI dump from the device then returned text="Hello Fedora!" on a fresh boot of the same device, which confirms that the edit, build and deploy loop works end to end on Fedora 45.

Alternative: the Flathub package

Fedora has no RPM for Android Studio, so dnf install android-studio finds nothing and the only packaged route is Flathub. The test boxes listed only the Fedora Flatpak remote, and a Workstation install where third-party repositories were not enabled during setup may be in the same state, so add Flathub first if it is missing, and the Flatpak and Flathub guide covers that setup in more detail.

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install -y flathub com.google.AndroidStudio
flatpak info com.google.AndroidStudio | grep -E "^ *(Version|Runtime|Origin):"

On the test day the Flatpak carried exactly the same build as the tarball from Step 2.

       Version: 2026.2.1.8
        Origin: flathub
       Runtime: org.freedesktop.Sdk/x86_64/26.08

The install took 5 m 26 s on Fedora 45 and 4 m 36 s on Fedora 44. The app is an extra-data package, so flatpak info reports only 26.5 MB while the IDE itself is downloaded from Google during the install. The app directory measured 3.6 GB plus 1.7 GB for the SDK runtime. The sandbox permissions are worth reading before choosing this route.

flatpak info --show-permissions com.google.AndroidStudio

The context section of the output shows how much of the host the app can reach.

[Context]
shared=ipc;network;
sockets=fallback-x11;gpg-agent;ssh-auth;wayland;
devices=all;
features=multiarch;
filesystems=home;

With devices=all and filesystems=home very little sandbox remains, and inside it /dev/kvm was readable and writable while JAVA_HOME pointed at the bundled runtime in /app/extra/jbr. Flathub marks the app as not verified, meaning Google does not publish it. Only the install and these sandbox checks were run on the Flatpak, the wizard and the emulator were tested on the tarball install alone, and the execheap fix applies to the emulator process in either case.

Uninstall Android Studio from Fedora

Deleting /opt/android-studio frees only a fraction of the space, and on the Fedora 44 box the per-user directories created by the steps above added up to far more than the IDE itself.

du -sh ~/.config/Google/AndroidStudio* ~/.cache/Google/AndroidStudio* ~/Android ~/.android ~/.gradle ~/AndroidStudioProjects

The virtual devices in ~/.android were the single largest item on the box.

1020K	/home/klinsmann/.config/Google/AndroidStudio2026.2.1
654M	/home/klinsmann/.cache/Google/AndroidStudio2026.2.1
6.3G	/home/klinsmann/Android
7.2G	/home/klinsmann/.android
1.7G	/home/klinsmann/.gradle
50M	/home/klinsmann/AndroidStudioProjects

Remove the IDE, the desktop entries and the Flatpak, skipping the two flatpak lines on a tarball-only install (the --unused pass removes every unused runtime on the system, not only this one), and set the SELinux boolean back to its default.

sudo rm -rf /opt/android-studio
sudo rm -f /usr/share/applications/android-studio.desktop
rm -f ~/.local/share/applications/jetbrains-studio.desktop
sudo rm -f /usr/local/share/applications/jetbrains-studio.desktop /usr/share/applications/jetbrains-studio.desktop
sudo flatpak uninstall -y com.google.AndroidStudio
sudo flatpak uninstall -y --unused
sudo setsebool -P selinuxuser_execheap 0

The next commands delete the per-user data, meaning the SDK, every virtual device and the Gradle cache, while leaving the projects in ~/AndroidStudioProjects untouched.

rm -rf ~/.config/Google/AndroidStudio* ~/.cache/Google/AndroidStudio* ~/.local/share/Google/AndroidStudio* ~/Android ~/.android ~/.gradle
sed -i "/ANDROID_HOME/d" ~/.bashrc

The sed line removes all three lines added in Step 8 because each of them contains ANDROID_HOME, along with any other line in the file that mentions it, but any JAVA_HOME line added in Step 7 has to be deleted by hand. The ~/.gradle cache is shared with every other Gradle project on the machine, so keep it when Java or Kotlin projects are also built outside Studio.

What to recheck after each Studio or Fedora update

Four parts of this setup depend on upstream behavior that has already changed once and is likely to change again.

• The execheap denial. After each selinux-policy update, start an emulator with the boolean switched off, and if it boots, the policy or the emulator renderer has changed and the boolean can stay off.
• The tarball URL. The move to codename file names broke every download script that assembled the URL from a version number, and the scrape in Step 2 survives that only as long as the download page markup stays stable.
• The sdkmanager tool. It is deprecated in favor of android sdk, so scripts that call it still work today but will need porting once Google removes it from the Command-line tools package.
• The Gradle daemon JDK. New project templates pin the Java version for the daemon, and when a Studio update raises it, a JAVA_HOME pointed at the bundled runtime follows automatically, while a system OpenJDK only works if Gradle can find or provision a matching toolchain.

The same IDE is covered for other distributions on Ubuntu and on Rocky Linux, AlmaLinux and Oracle Linux. Waydroid is the lighter option for running Android apps on the Fedora desktop without developing them, and package housekeeping on the same machine is in the DNF5 cheatsheet for Fedora.