Solution For Bazel is Not Setting Up Properly On Windows.

[TanishMoral11]

Operating System

Windows 11

Android Studio Version

Giraffe

RAM size

16 GB

Free disk space

50 GB

Which step are you stuck on?

Bazel is not setting up properly on Windows.

Error Log

N/A

Approaches already used to resolve the issue

Here's a step-by-step guide to help you through it. It will be easy to follow, and throw in some tips along the way.

---

1. If You're on Windows, Here's My Suggestion

Okay, if you're using Windows, please consider dual-booting Ubuntu 22.04.
Why? Windows has a few annoyances like long path issues and Bazel plugin issues that could drive you crazy. On Ubuntu, everything just works much smoother, especially for development. 🖥️✨

Also, when you're setting up Ubuntu, I recommend installing the Android Studio Giraffe version. Trust me, it's a good idea.

---

2. Getting Started on Ubuntu 22.04

Alright, let's get down to business! Open up that Ubuntu terminal and let's start.

---

Step 1: Update Your System

First things first, let's make sure your system is up to date:

$ sudo apt update && sudo apt upgrade

Step 2: Install JDK 17 and Dependencies

You'll need OpenJDK 17 for Bazel to run properly. Here's how to install it:

$ sudo apt install openjdk-17-jdk
$ java --version
# You should see something like:
# openjdk 17.0.10 2024-01-16
# OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
# OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)

Next, we'll install Python 2 and GCC:

$ sudo apt install python2
$ sudo apt install gcc

Step 3: Set Up the Android SDK

Let's set up the Android SDK. First, create the SDK folder:

$ mkdir -p $HOME/Android/Sdk

Download the command line tools from here and then run:

$ cp /mnt/c/Users/<Name>/Downloads/commandlinetools*.zip $HOME/Android/Sdk
$ cd $HOME/Android/Sdk
$ sudo apt install unzip
$ unzip commandlinetools*.zip

Now, let's move the files into the correct folder:

$ cd cmdline-tools/
$ mkdir tools
$ mv -i * tools
$ cd ..

Set up the environment variables for Android SDK:

$ echo "export ANDROID_HOME=\$HOME/Android/Sdk" >> ~/.bashrc
$ echo "export PATH=\$ANDROID_HOME/cmdline-tools/tools/bin/:\$PATH" >> ~/.bashrc
$ source ~/.bashrc

Now install the necessary Android SDK components:

$ sdkmanager
$ sdkmanager --install "platform-tools"
$ sdkmanager --install "platforms;android-34"   # Use the latest version
$ sdkmanager --install "build-tools;32.0.0"

Step 4: Install Bazel

Let's move on to Bazel. Here's how you can install it:

$ sudo apt install apt-transport-https curl gnupg -y
$ curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg
$ sudo mv bazel-archive-keyring.gpg /usr/share/keyrings
$ echo "deb [arch=amd64 signed-by=/usr/share/keyrings/bazel-archive-keyring.gpg] https://storage.googleapis.com/bazel-apt stable jdk1.8" | sudo tee /etc/apt/sources.list.d/bazel.list
$ sudo apt update && sudo apt install bazel
$ bazel --version

If you see Bazel 8.0.0, no problem, just install the version you need:

$ sudo apt install bazel-6.5.0
$ bazel --version   # This should show bazel 6.5.0 now!

If it's still not switching, you can force it like this:

$ sudo rm /usr/bin/bazel
$ sudo ln -s /usr/bin/bazel-6.5.0 /usr/bin/bazel
$ bazel --version   # Confirm it's bazel 6.5.0

Step 5: Set Up Your Oppia Project

Let's get your Oppia project ready. First, create a folder for it:

$ mkdir $HOME/opensource
$ cd $HOME/opensource

Clone the Oppia Android repo:

$ git clone https://github.com/<GitHub-Username>/oppia-android.git
$ cd oppia-android/

Run the setup script:

$ scripts/setup.sh

If you run into a Permission Denied error, just fix the permissions:

$ chmod +x scripts/setup.sh
$ scripts/setup.sh

You should see messages like this:

Using Ktlint 0.37.1
Ktlint file downloaded
Using Checkstyle version 8.37
Checkstyle file downloaded
Using Bufbuild version v0.37.1
Buf downloaded
Using Buildifier version 3.4.0
Buildifier file downloaded

Step 6: Build Oppia

Let's build the project with Bazel:

$ bazel build //:oppia_dev

You should see something like this:

Target //:oppia up-to-date:
  bazel-bin/oppia_deploy.jar
  bazel-bin/oppia_unsigned.apk

Step 7: Running and Installing the APK

Now, to build and install the APK with the latest changes on your emulator, you need this command:

$ bazel mobile-install //:oppia_dev_binary

This is your life-saver command! :) Save it somewhere — you'll thank me later!

Step 8: Troubleshooting Tips

Laptop Crashing During Build?

If your laptop crashes while building, don't worry! Just close Android Studio and any unnecessary background processes. Then try running the build again On Ubuntu Terminal:

$ bazel build //:oppia_dev
# or
$ bazel mobile-install //:oppia_dev_binary

Work in the Terminal (You're a Developer, After All!)

Try to do as much as possible directly in the Ubuntu terminal. You'll be way more productive, plus it just feels like you're a true developer. :)

Low SWAP RAM?

If your system is getting slow, increase your SWAP RAM to at least 8 GB. Trust me, it'll make a big difference.

Happy Coding! 🎉

Additional information

Special Thanks : @adhiamboperes @Rd4dev

[anmoltrvd01]

Trouble Setting Up Oppia Android (Issue #5607, Help & Settings Screens)

Hi, first of all, thank you so much for the detailed setup guide — it really helped me get Oppia Android installed and set up on my machine. I appreciate the time and effort you put into making it easier for contributors like me.

I’m now trying to contribute to issue #5607 (Help & Settings screens),

I followed the setup guide but I'm getting this error:

When running Oppia on my Android Virtual Device, System UI becomes unresponsive.
The app shows “Oppia is not responding” immediately after launch.
USB debugging is enabled, but Android Studio inside WSL does not detect the device reliably.
Bazel build issues – Some targets fail to build after I make changes, and I am unsure how to quickly verify changes.
Physical device not detected – I enabled USB debugging on my phone, but Android Studio inside WSL does not detect my device. I am unsure how to use a physical device for testing, or if I need to rely solely on the emulator.

I'm using:

OS: Windows 11 + WSL2 Ubuntu 22.04.5 LTS

Bazel version: 6.5.0

Java version: openjdk 17.0.18

Android Studio: Giraffe (running inside WSL)

Android SDK location: /home/anmol_aovswlk/Android/Sdk

Python2 version: 2.7.18

GCC version: 11.4.0

Memory: 7.8 GiB RAM, 8 GiB Swap (currently ~5.2 GiB used)

Disk: C: 355G total, 96G free

I tried:

Reinstalling Bazel

Cleaning the project (bazel clean --expunge)

Running scripts/setup.sh again

Checking my Android SDK and environment variables

Problem on Physical Device:

USB debugging is enabled, but Android Studio inside WSL does not detect the device reliably.

Issues / Questions

After following the setup and build scripts, I get red errors in the project.(I am pasting a Screenshot along with this)

Physical device not detected in Android Studio running in WSL, even with USB debugging enabled.

I want to test changes faster—can I use a physical device in WSL? Or is there a better/faster way?

Bazel builds are slow, sometimes my laptop memory fills up. Any tips to speed this up safely?

---

Please guide me on what I might be missing? Any tips to fix the error and/or speed up testing would be really appreciated.

Thanks again for all your help so far!

[adhiamboperes]

@ShankhanilSaha, @itsadityaaaaa, @CodeWithSangeeta, since you have recently set up the project, do you guys have thoughts?

[CodeWithSangeeta]

Yes, I faced very similar issues while setting up Oppia on Windows + WSL, and From my experience, most of the problems were related to WSL + Android Studio + ADB interaction, rather than Oppia itself.

Android Studio inside WSL + Physical Device
Android Studio running inside WSL does not reliably detect physical devices because:

• WSL2 is virtualized
• USB devices aren’t directly exposed
• Windows ADB and WSL ADB can conflict

Recommended setup:

• Install Android Studio on Windows
• Keep Bazel & build tools in WSL
• Use Windows ADB for device detection
• This avoids most USB/debugging issues.

“Oppia not responding” / Emulator freezing
This usually happens due to low RAM + heavy Bazel builds.
With 7–8 GB RAM, Bazel can easily exhaust memory.

For safer builds, try:
bazel build //:oppia_dev_binary.apk --jobs=2 --local_ram_resources=3000

Or slightly faster (if system allows):
bazel build //:oppia_dev_binary.apk --jobs=4 --local_ram_resources=4096

First build always takes time.
Avoid running bazel clean --expunge unless necessary — it makes the next build very slow.

Physical Device Not Detected in WSL
This is expected. WSL does not automatically forward USB devices.
Best options:

• Run Android Studio on Windows
• Or switch to full Ubuntu (dual boot)
• WSL + Android Studio + USB debugging together can be unstable.

Hope this helps @anmoltrvd01

[ShankhanilSaha]

Hey @anmoltrvd01, great to see you are interested in Oppia!

Honestly, the emulator crashing is likely just a hardware bottleneck rather than a mistake in your setup. Android Studio and its emulators are quite system heavy even my own machine with 16 Gigabytes of RAM struggles with them. I usually use a physical device for testing for that exact reason.

Android Studio on WSL won't see a USB connected phone by default because Windows doesn't share USB ports with Linux out of the box. Setting up a USB bridge can take up a lot of your time, so I’d recommend wireless debugging instead. It usually works with WSL out of the Box.

[itsadityaaaaa]

Hi @anmoltrvd01,

Thank you for your interest in Oppia. I completely agree with @ShankhanilSaha point. The issue seems to be related to system hardware limitations rather than anything on your end.

I was initially going to suggest using Linux, as I use it myself. However, since your system has only 8GB of RAM, setting up a dual boot may not be very practical. If you do not need Windows, you could consider switching entirely to Linux. Otherwise, I would recommend trying the suggestions provided by ShankhanilSaha.

[BenHenning]

Dual booting doesn't share resources (unlike hosting a VM which is what WSL2 is doing) so there shouldn't be a performance difference between a fully committed Linux machine and a dual-booted machine.

The main bottleneck would be in drive space since a second OS will require a lot of physical disk space on its own.