Category: Android

fixing a flutter problem: accessing a google pixel 4a

whbeebe

I’m in the process of writing an Android app using Flutter. My target is a Google Pixel 4a. I’m using real hardware instead of a virtual handset because of the speed, especially on my low-cost development system. To give you an idea of what I’m running, here’s a capture of neofetch.

My little system is running with the latest Linux Mint release, and I’d just updated it to the latest packages, including the latest kernel for this distribution.

I’ve also got the latest version of Flutter (3.3.4)  installed. I’m not going to tell you how to install and set up Flutter. You can read about that at the Flutter site. Instead this is how I fixed an issue with Flutter unable to communicate with the Pixel 4a.

Even though I’d enabled developer mode on the Pixel 4a, when I plugged the 4a into my machine via USB and then ran flutter doctor, I was informed that adb couldn’t communicate with it. The error message, spit out on the console in lurid red text, said in part “adb: insufficient permissions for device: user in plugdev group; are your udev rules wrong?” It’s that bit about udev rules that’s the key clue to fixing the problem. In my case I had no udev rules for the plugged in 4a.

The udev (userland /dev, see https://opensource.com/article/18/11/udev ) subsystem allows a script to be run if a Linux device is created, usually by plugging in physical hardware. The rule files are located in /etc/udev/rules.d. For the case of plugging in a Pixel 4a, you need to create a rules file for when it’s connected so that code you run as a regular user can work with this specific device. The first step in writing a rules file is identifying the device by executing lsusb at the command line.

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubBus 003 Device 002: ID 8087:0029 Intel Corp. AX200 BluetoothBus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. HubBus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubBus 001 Device 008: ID 18d1:4ee7 Google Inc. Nexus/Pixel Device (charging + debug)Bus 001 Device 007: ID 10c4:ea60 Silicon Labs CP210x UART BridgeBus 001 Device 006: ID 2e8a:0005 MicroPython Board in FS modeBus 001 Device 005: ID 10c4:ea60 Silicon Labs CP210x UART BridgeBus 001 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 HubBus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying ReceiverBus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART BridgeBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I have a number of devices plugged in, one of which is the Pixel 4a identified in line 6. The key information I need to create a udev rule is the ID 18d1:4ee7.

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee7", MODE="0666", GROUP="plugdev"

You can see how I copied 18d1 to ATTR{idVendor}== and 4ee7 to ATTR{idProduct}==. I saved this single line of text to /etc/udev/rules.d/50-android.rules, then rebooted my system. Once it came back up when I re-ran flutter doctor I got the following;

The first run was after the reboot with the 4a plugged in. Believe it or not, the error message in the first run is actually a Good Thing. As noted on the console output, the 4a had a screen dialog asking if I wanted to trust the computer I was connected to to perform USB debugging “always”. When I selected yes, and re-ran flutter doctor, the output was totally clean.

yes i can develop for android on a chromebook, but do i want to?

whbeebe
Figure 1: Android Studio with my tutorial on running my Chromebook

You can indeed install Android Studio (Chipmunk, 2021.2.1) and then run the IDE and actually open a project in it, and have that project build and run inside the IDE. As I wrote earlier I checked this tutorial project I’d built into GitHub. On this Chromebook I checked it out and loaded it into the  local Android Studio running on the Chromebook. I had to make a few changes with regards to Java and Gradle because everything is running inside the Chromebook’s Chrostini Linux container. Once that was sorted the project built and I could see the project preview on the far right. I have not tried to kick off a virtual Android device, and frankly, I’m afraid to. Perhaps I should plug in one of my Android handsets I use for testing into the Chromebook’s USB-C port and give that a go. But I have a bigger decision to make.

Should I even try? Loading the project wasn’t a problem. Building it was. It takes a very long time to build this project on my Chromebook, far longer than on my low-end Minus Forum UM250 development box. Developing on the UM250 is reasonable, the Chromebook pushes my patience a bit. Unfortunately if all you have is a Chromebook like this Lenovo, then you go with what you have. I do say that simpler development with Visual Studio Code and Rust or Python is a far better experience than developing with Android Studio.

Having said that, I admit to be very impressed that it all worked as it should on the Chromebook. That speaks to the high quality of Android Studio and Chrome OS itself. For a beginning developer or a developer on a budget, you can get a tremendous amount done with a Lenovo if properly configured up front (Intel i3, 8GB RAM, 128GB SSD storage). For highschool STEM students or undergraduate college students (freshman and sophomore) it’s a great deal. And a Chromebook has all the other tools built-in for doing all the work required of students (writing papers, for example).

Another observation about working on a Chromebook with this Android Studio project is that two project files have been modified; .idea/gradle.xml and .idea/misc.xml. These were changed when I configured the project to work on the Chromebook. Do I check those files into main on GitHub, or do I create a branch for working on ChromeOS and then check them into that branch? Do I even want to bother? Since this was meant to be a proof-of-concept exercise, I’ll need to give that some more thought.