I’ve been playing with React Native now for 7 months, since April 2015. Geez… has it really been that long already? Time sure flies when you’re… uh… you know!
Up until now, I’ve been happy to develop my iOS app alone, pushing Android off to the future. But that changed when I came across a call for help on Stack Overflow this past weekend titled ‘Unable to download JS bundle’ error on Android 4. Intrigued, I decided to setup my Android environment and see if I had any better luck (spoiler alertL I didn’t… have any better luck that is). But I did document every step of my experience, and here I lay it out for your pleasure… every gruesome detail.
Start Time: 11:45a
Time Check: 12:40p
- Installed Android SDK Build Tools – this is where I apparently just screwed up. Firstly, I remember clicking on the build tools at the Configure SDK step above, but for some reason it didn’t install. My best guess is that I didn’t accept all the licenses correctly. In any case this time, I installed both Android SDK Build-tools 23.0.1 && 23.0.2 since it’s available.
- Try to Emulate Something (SUCCESS!) – It worked! It took 1 minute 21 seconds to build, which is dagnabit slow, but it worked in the emulator! Apparently I can make the builds run faster by installing the Gradle Daemon, but I’ll save that for another time.
Time Check: 2:25p
I’m finally to the point where I can attempt to duplicate the stack overflow issue ‘Unable to download JS bundle’ error on Android 4. These are the instructions I followed, which were what was live at the time I did this (fyi: they’ve been updated since to be more clear)
Before I could even get started on these instructions, I had to first understand the nomenclature. The author is clearly making assumptions about what he/she thinks I already know, but I am totally new to Android development and have to start from square one.
- What’s a rage shake menu?
I had to research what the “rage shake” was to ensure I understood. As it turns out, both Facebook and Google use this feature to send debug info to their testers from the wild. My phone, however uses the rage-shake to start the camera. Once I disabled that for the camera, it still didn’t open the “rage shake menu”
- What is adb?
This turns out to be the Android Debug Bridge, a CLI tool for debugging.
- How do I run adb?
I started by typing adb in the terminal. Success! I was given a list of valid commands.
Ok, so now I felt like I understood the language and understood the tools enough to get started on this. Referring back to the docs image above, the first step in configuring device to connect to the dev server via wifi was “Open rage shake menu (shake the device) or run adb shell input keyevent 82.“
I shook the hell out of my phone, but rage shake didn’t work for me. On the MotoX, I can start the camera at anytime by shaking my phone, so I disabled that feature to test this. I had no luck. So, I was left figuring out how to send the adb command to my phone.
As I said earlier, when I typed adb <enter> in the terminal, I was shown a list of available commands. One of the commands was adb devices which showed me all connected devices. I gave it a try and got this response…
At this point, I had no idea whether that was my wifi connected device or the emulator. I’m not even clear what a device has to do to become “connected” or what “connected” means. But, I figure that if I issued the keyevent, it would get sent to this device, so I gave it a try.
<span style="color: #993300;">adb shell input keyevent 82 </span>
This opened the dev menu in the emulator. Ok, that answers the question as to whether it was my device or the emulator. I see the option for Dev settings > debug server host for device (Steps 2 & 3), so I entered the local IP of my local machine as instructed (10.0.0.4:8081), then…
App Crashed – immediately after closing the menu, the emulated app crashed. It’s no surprise really. I didn’t expect it to work. But I thought I’d give it a try just in case. When you’ve never seen it work correctly, you just don’t have any idea whether you’re on the right track or not. I clearly wasn’t.
Try to Undo – I’ve no idea how to undo the debug server settings. I tried restarting the simulator, restarting the packager, restarting the simulator, restarting genymotion, and finally just deleted the emulator from genymotion, shut everything down, and started building it all up from the beginning. This worked, thank gawd!
Try Connecting my Wifi Device – my next thought was to try and figure out how to connect my device. I found my device IP address (settings > phonen info > status > IP address) and thinking I could use the adb connect with IP address to connect, I tried this…
<span style="color: #993300;">adb connect 10.0.0.2 </span>
FAIL! The result was unable to connect to 10.0.0.2:5555 (scratches head!)
Thankfully, Brent Vatne and Martin Konicek were helpful on twitter and clued me in that I’d need to have the app open on the device before issuing the keyevent 82. That makes sense, but how? Scrolling up to the top of the Running on device page is instructions on connecting via USB that I had been ignoring till now because I didn’t want to connect via USB, I wanted to connect via Wifi. In any case, once I figured that out, I connected my device via USB (making sure to have usb debugging enabled) and ran the command again. And again it failed with the error: more than one device and emulator. Apparently you can only have one device connected at a time, so I quit the emulator and built again…
<span style="color: #993300;">react-native run-android
</span>
I tried and tried, but never was able to get the app to build on the device itself. I verified it works in the emulator again before throwing in the towel for the night.
Finished: 7p
In Summary, it took me 2 hours and 40 minutes to configure my machine for Android. As you can see from the screenshot above, I was still working on this at 7p, which means I’ve invested close to 8 hours trying to get a simple Android build to run on my device. Unfortunately, I wasn’t successful in the end, but I learned a lot in the journey. And I’m sure the core team will get this fixed. They’re a great, hard working group.