Figure 17: Android Studio, As Initially Launched, Showing Error
Creating an Android application first involves creating an Android “project”. As with many other development environments, the project is where your source code and other assets (e.g., icons) reside. And, the project contains the instructions for your tools for how to convert that source code and other assets into an Android APK file for use with an emulator or device, where the APK is Android’s executable file format.
Hence, in this tutorial, we kick off development of a sample Android application, to give you the opportunity to put some of what you are learning in this book in practice.
The application we will be building in these tutorials is called EmPubLite.
EmPubLite will be a digital book reader, allowing users to read
a digital book like the
one that you are reading right now.
EmPubLite will be a partial implementation of
the EmPub reader used for the APK
version of this book. EmPub itself is a fairly extensive application, so
EmPubLite will have only a subset of its features.
The “Em” of EmPub and EmPubLite stands for “embedded”. These readers are
not designed to read an arbitrary EPUB or MOBI formatted book that you might
download from somewhere. Rather, the contents of the book (largely an unpacked
EPUB file) will be “baked into” the reader APK itself, so by distributing
the APK, you are distributing the book.
Of course, you may have little interest in writing a digital book reader app.
The tutorials presented in this book are certainly optional. There is no expectation that you have to write any code in order to get value from the book. These tutorials are here simply as a way to help those of you who “learn by doing” have an opportunity to do just that.
Hence, there are any number of ways that you can use these tutorials:
EmPubLite app.T2-Project/
directory containing a copy of the EmPubLite sample app after having completed
the steps found in this tutorial.
You can import these projects into your IDE,
examine what they contain, cross-reference them back to the tutorials themselves,
and run them.Any of these are valid options — you will need to choose for yourself what you wish to do.
The instructions in the remaining tutorials should be accurate for Android Studio 3.0.x. The instructions may work for other versions of this IDE, but there may also be some differences.
We need to create the Android project for EmPubLite.
Normally, you would use the new-project wizard to create a new project. However, the problem with the new-project wizard is that Google keeps changing what the new-project wizard generates. In most situations, that is not a huge problem. However, it becomes a problem for tutorials like this one, as if Google changes what is in the new project, the tutorial’s instructions become out of date.
So, instead, we will import an existing project, so we can start from a stable base.
Visit the releases page of this book’s GitHub repository.
Then, scroll down to this book’s version and download the EmPubLite-Starter.zip
file for it. UnZIP that project to some place on your development machine. It will
unZIP into an EmPubLite/ directory.
Then, import the project. From the Android Studio welcome dialog, that is handled by the “Import project (Eclipse ADT, Gradle, etc.)” option. From an existing open Android Studio IDE window, you would use File > New > Import Project… from the main menu.
Importing a project brings up a typical directory-picker dialog. Pick the EmPubLite/
directory and click OK to begin the import process. This may take a while,
depending on the speed of your development machine. A “Tip of the Day” dialog
may appear, which you can dismiss.
At this point, you should have an empty Android Studio IDE window, probably with an error message, such as:
Figure 17: Android Studio, As Initially Launched, Showing Error
or:
Figure 18: Android Studio, As Initially Launched, Showing a Different Error
In the “Messages Gradle Sync” tool pane, towards the bottom of the screen, you may have a “Failed to find Build Tools revision 27.0.3”. Each Android project states what version of the development tools it uses, and this one uses a version slightly older than the current. In that tool pane, the “Install Build Tools 27.0.3 and sync project” message is a hyperlink — click that to download the missing bits. This is a common pattern with these error messages, where the message will contain a link to try to fix the problem.
Or, if you get “Failed to find target with hash string android-25…”, there
should be a “Install missing platform(s) and sync project” link. Click that to try
to fix the problem.
Next, after several moments, you will get a pop-up dialog like this one:
Figure 19: Android Studio, Update Recommendation Dialog
The trigger for this dialog is similar to the trigger for the preceding error message: the project that you imported is looking to use some older tools than what is the latest-and-greatest. For projects that you create yourself from scratch, you will not get this message, as the new-project wizard always uses the latest tools… even if that is not always the best idea. For projects like this one, that you import from elsewhere, this dialog is common. For the purposes of these tutorials, click the “Don’t remind me again for this project” button. For other projects that you import, you could opt to click the “Update” button, which will adjust the project to use the newer tools, though this may cause compatibility problems that you would have to debug.
The “Project” tool — docked by default on the left side, towards the top — brings up a way for you to view what is in the project. Android Studio has several ways of viewing the contents of Android projects. The default one, that you are presented with when creating or importing the project, is known as the “Android view”:
Figure 20: Android Studio “Android View”
While you are welcome to navigate your project using it, the tutorial chapters in this book, where they have screenshots of Android Studio, will show the project view:
Figure 21: Android Studio “Project View”
To switch to this view — and therefore match what the tutorials will show you — click the “Android” entry above the tree, to display a drop-down of different views. Choose “Project”, and that will switch you to the project view used by these tutorials.
Your first decision to make is whether or not you want to bother setting up an emulator image right now. If you have an Android device, you may prefer to start testing your app on it, and come back to set up the emulator at a later point. In that case, skip to Step #4.
Otherwise, here is what you may need to do, based on the operating system on your development machine.
If your CPU met the requirements, and you successfully enabled the right things in your system’s BIOS, the Android Studio installation should have installed HAXM, and you should be ready to go.
If, on the other hand, you got some error messages in the installation wizard regarding HAXM, you would need to address those first.
The wizards of Cupertino set up their Mac hardware to be able to run the Android x86 emulator, which is awfully nice of them, considering that Android competes with iOS. The Android Studio installation wizard should have installed HAXM successfully, and you should be able to continue with the next step of the tutorial.
The Android x86 emulator on Linux does not use HAXM. Instead, it uses KVM, a common Linux virtualization engine.
If, during the Android Studio installation process, the wizard showed you a page that said that you needed to configure KVM, you will need to do just that before you can set up and use the x86 emulator. The details of how to set up KVM will vary by Linux distro (e.g., Ubuntu).
The Android emulator can emulate one or several Android devices. Each configuration you want is stored in an “Android virtual device”, or AVD. The AVD Manager is where you create these AVDs.
Note that Android Studio now has its own implementation of the AVD Manager that is separate from the one Android developers have traditionally used. You may see screenshots of the older AVD Manager in blog posts, Stack Overflow answers, and the like. The AVD Manager still fills the same role, but it has a different look and feel.
To open the AVD Manager in Android Studio, choose Tools > AVD Manager from the main menu.
You should be taken to “welcome”-type screen:
Figure 22: Android Studio AVD Manager, Welcome Screen
Click the “Create Virtual Device” button, which brings up a “Virtual Device Configuration” wizard:
Figure 23: Android Studio Virtual Device Configuration Wizard, First Page
The first page of the wizard allows you to choose a device profile to use as a starting point for your AVD. The “New Hardware Profile” button allows you to define new profiles, if there is no existing profile that meets your needs.
Since emulator speeds are tied somewhat to the resolution of their (virtual) screens, you generally aim for a device profile that is on the low end but is not completely ridiculous. For example, an 800x480 or 1280x768 phone would be considered by many people to be fairly low-resolution. However, there are plenty of devices out there at that resolution (or lower), and it makes for a reasonable starting emulator.
If you want to create a new device profile based on an existing one — to change a few parameters but otherwise use what the original profile had – click the “Clone Device” button once you have selected your starter profile.
However, in general, at the outset, using an existing profile is perfectly fine. The Galaxy Nexus or Nexus 4 images are likely choices to start with.
Clicking “Next” allows you to choose an emulator image to use:
Figure 24: Android Studio Virtual Device Configuration Wizard, Second Page
The emulator images are spread across three tabs:
For the purposes of the tutorials, you do not need an emulator image with the “Google APIs” — those are for emulators that have Google Play Services in them and related apps like Google Maps. However, in terms of API level, you can choose anything from API Level 15 (Android 4.0.3) on up. You should have one or more suitable images already set up for you, courtesy of having installed Android Studio.
If you click on the x86 Images tab, you should see some images with a “Download” link, and others without it:
Figure 25: Android Studio Virtual Device Configuration Wizard, x86 Images
The emulator images with “Download” next to them will trigger a one-time download of the files necessary to create AVDs for that particular API level and CPU architecture combination, after another license dialog and progress dialog:
Figure 26: Android Studio Component Installer Dialog, Downloading API 23 ARM Image
Once you have identified the image(s) that you want — and have downloaded any that you did not already have — click on one of them in the wizard:
Figure 27: Android Studio Virtual Device Configuration Wizard, After Choosing Image
Clicking “Next” allows you to finalize the configuration of your AVD:
Figure 28: Android Studio Virtual Device Configuration Wizard, Third Page
A default name for the AVD is suggested, though you are welcome to replace this with your own value.
Change the AVD name, if necessary, to something valid: only letters, numbers,
spaces, and select punctuation (e.g., ., _, -, (, )) are supported.
The rest of the default values should be fine for now.
Clicking “Finish” will return you to the main AVD Manager, showing your new AVD. You can then close the AVD Manager window.
You do not need an Android device to get started in Android application development. Having one is a good idea before you try to ship an application (e.g., upload it to the Play Store). And, perhaps you already have a device – maybe that is what is spurring your interest in developing for Android.
If you do not have an Android device that you wish to set up for development, skip this step.
The first step to make your device ready for use with development is to go into the Settings application on the device. What happens now depends a bit on your Android version:
Figure 29: Developer Options, in Settings App
You may need to slide a switch in the upper-right corner of the screen to the “ON” position to modify the values on this screen.
Generally, you will want to scroll down and enable USB debugging, so you can use your device with the Android build tools:
Figure 30: Debugging Options, in Settings App
You can leave the other settings alone for now if you wish, though you may find the “Stay awake” option to be handy, as it saves you from having to unlock your phone all of the time while it is plugged into USB.
Note that on Android 4.2.2 and higher devices, before you can actually use the setting you just toggled, you will be prompted to allow USB debugging with your specific development machine via a dialog box:
Figure 31: Allow USB Debugging Dialog
This occurs when you plug in the device via the USB cable and have the driver appropriately set up. That process varies by the operating system of your development machine, as is covered in the following sections.
When you first plug in your Android device, Windows will attempt to find a driver for it. It is possible that, by virtue of other software you have installed, that the driver is ready for use. If it finds a driver, you are probably ready to go.
If the driver is not found, here are some options for getting one.
Some versions of Windows (e.g., Vista) will prompt you to search Windows Update for drivers. This is certainly worth a shot, though not every device will have supplied its driver to Microsoft.
In your Android SDK installation, if you chose to install the “Google USB Driver”
package from the SDK Manager, you will find an extras/google/usb_driver/
directory, containing a generic Windows driver for Android devices. You can try
pointing the driver wizard at this directory to see if it thinks this driver is
suitable for your device. This will often work for Nexus devices.
If you still do not have a driver, the OEM USB Drivers in the developer documentation may help you find one for download from your device manufacturer. Note that you may need the model number for your device, instead of the model name used for marketing purposes (e.g., GT-P3113 instead of “Samsung Galaxy Tab 2 7.0”).
Odds are decent that simply plugging in your device will “just work”. You can
see if Android recognizes your device via running adb devices in a shell
(e.g., macOS Terminal), where adb is in your platform-tools/ directory of
your SDK. If you get output similar to the following, the build tools detected your
device:
List of devices attached
HT9CPP809576 device
If you are running Ubuntu (or perhaps other Linux variants), and this command
did not work, you may need to add some udev rules. For example, here is a
51-android.rules file that will handle the devices from a handful of
manufacturers:
SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
SUBSYSTEM=="usb", SYSFS{idVendor}=="22b8", MODE="0666"
SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="0c01", MODE="0666", OWNER="<me>"
SUBSYSTEM=="usb", SYSFS{idVendor}=="19d2", SYSFS{idProduct}=="1354", MODE="0666"
SUBSYSTEM=="usb", SYSFS{idVendor}=="04e8", SYSFS{idProduct}=="681c", MODE="0666"
Drop that in your /etc/udev/rules.d directory on Ubuntu, then either reboot
the computer or otherwise reload the udev rules (e.g., sudo service udev reload).
Then, unplug and re-plug in the device and see if it is detected.
Now, we can confirm that our project is set up properly by running it on a device or emulator.
To do that in Android Studio, just press the Run toolbar button (usually depicted as a green rightward-pointing triangle).
You will then be presented with a dialog indicating where you want the app to run: on some existing device or emulator, or on some newly-launched emulator:
Figure 32: Android Studio Device Chooser Dialog
If you do not have an emulator running, choose one from the list, then click OK. Android Studio will launch your emulator for you.
And, whether you start a new emulator instance or reuse an existing one, your app should appear on it:
Figure 33: Android 7.0 Emulator with EmPubLite
Note that you may have to unlock your device or emulator to actually see the app running.
The first time you launch the emulator for a particular AVD, you may see this message:
Figure 34: Android Emulator Cold-Boot Warning
The emulator now behaves a bit more like an Android device. Closing the emulator window used to be like completely powering off a phone, but now it is more like tapping the POWER button to turn off the screen. The next time you start that particular AVD, it will wake up to the state in which you left it, rather than booting from scratch (“cold boot”). This speeds up starting the emulator. Occasionally, though, you will have the need to start the emulator as if the device were powering on. To do that, in the AVD Manager, in the drop-down menu in the Actions column, choose “Cold Boot Now”.
… we will modify the AndroidManifest.xml file of our tutorial project.