Starting the IDE and creating your first app

To start the IDE and create your first app, you start, naturally, at the beginning:

1. Launch Android Studio.

   For details on launching Android Studio, see Chapter 2 of this minibook. To find out how to make the most of your Android Studio experience, see Book 2, Chapter 1.

   When you launch Android Studio for the first time, you see the Welcome screen. (See Figure 3-1.) The Welcome screen lists any Android Studio projects that you’ve already created. (Hint: You haven’t created any projects yet.) In addition, you see the version of Android Studio you’re using, which is 3.5.1 for this book.

   The Welcome screen also offers you some Quick Start options, such as Start a New Android Studio Project, Open an Existing Android Studio Project, and so on.

   

2. In the Welcome screen, select Start a New Android Studio Project.

   The Create New Project dialog box appears, as shown in Figure 3-2. You consider two things when creating a new project:

   • Device type: The device types appear across the top of the dialog box, such as Phone and Tablet, Wear OS, TV, Android Auto, and Android Things. Book 5 discusses each of these device types in detail, but for now all you need to know is that you can choose any of them for your app.
   • Starting point: A project has a starting point — the elements that the IDE provides for you automatically. The IDE controls what appears in the initial project using a template. If you choose the right starting point, you perform less work when creating an app because you don’t have to create all the code manually. The starting points vary by device type. You see the starting points for three Phone and Tablet projects in Figure 3-2, but there are many more. The available templates vary by device.

   

3. For this example, choose Empty Activity and click Next.

   You see the Configure Your Project screen, shown in Figure 3-3. This screen is where you tell Android Studio some of the characteristics of your app, such as

   • The app name
   • The name of the package to use to hold your code
   • The location to use to save the project
   • The programming language to use (all apps in this book use Kotlin, but you can also use Java)
   • The Android API level your app requires (the minimum level is 14, which is Android 4.0 [IceCreamSandwich], and the current maximum level is 29, which is Android 10.0 [Q])
   • Whether your app will support instant apps (kind of a micro-app that you can use without installing it)

4. Type My First App in the Name field.

   Notice that the Package Name and Save Location fields automatically change to match the name of your app. The wizard strips spaces from both the Package Name and Save Location fields because the presence of spaces would create problems when you compile the app and also causes problems when the IDE looks for the app on the hard drive.

   

   You don’t need to change the other fields for now. However, in a real app, you might. For example, the package name might need to use your domain name instead of com.example.

   The section “The more things stay the same, the more they change” in Chapter 2 of this minibook tells you about API levels. Newer versions of Android generally have more functionality and sometimes fewer problems than older versions do, but more devices run the older versions. A device that currently has Android 8.0 installed can run apps that require Android 8.0 or older. The Configure Your Project screen shows the percentage of devices that are likely able to run your app based on the Minimum API Level setting that you choose.

5. Click Finish.

   Android Studio creates a project that has the characteristics you chose. This process can take a while, so you need to be patient (the status bar will keep you informed as to the setup progress, but even the status bar can take a while to update). It's time to play that game of Solitaire you’ve been wanting for a while now. When the process of creating the project is finished, you see a window similar to the one shown in Figure 3-4. (If you see any informational dialog boxes, you can feel free to dismiss them.)

One of two things can happen the first time you create a project. If you installed the Offline Tools using the procedure in the “Installing offline tools” section of Chapter 2 of this minibook, the setup will progress rather quickly — we’re talking seconds. Otherwise, depending on your Internet speed, you can wait a l-o-n-g time for Android Studio to build the Gradle project info (whatever that is). You see a pop-up dialog box indicating that Android Studio is downloading something. The pop-up contains one of those annoying “un-progress” bars — the kind that doesn’t show you what percentage of the work is completed. (On some computers, the progress bar looks like a rotating, striped diagonal — the kind you see on old barbershop poles. On other computers, a solid bar simply moves back and forth, back and forth, back and forth. What were they thinking when they designed this pop-up? They probably figured that you’d be more willing to wait as long as this progress bar holds your cat’s attention.) Anyway, when Android Studio loads your first project, be prepared to wait several minutes for any signs of life on your screen.

Launching your first app

You’ve started up Android Studio and created your first project. The project doesn’t do much except display Hello world! on the screen. Even so, you can run the project and see it in action. Here’s how you start:

1. Take a look at Android Studio’s main window.

   When Android Studio initially creates your app, you see the MainActivity.kt (.kt is the Kotlin code file extension) file. For now, you want to see the activity_main.xml file, shown in Figure 3-5. Just click its tab (which is left of the MainActivity.kt tab).

   In Android Studio, your new app consumes the entire main window. If, for some reason, more than one Android Studio window is open, make sure that the window you're looking at is the one containing your newly created Android app.

2. In Android Studio’s main menu, choose Run⇒  Run ‘app’.

   If you see an error message saying “Error running ‘app’: No target device found,” it means that you haven’t created an Android Virtual Device (AVD) yet. The steps shown in the “Creating an Android virtual device” section in Chapter 2 of this minibook tells you how to create an AVD. You must have an AVD defined before the emulator will run. The example screenshots (starting with Figure 3-8) show how the app will look in a Google Pixel 3a running Android 10 (Q) with a Portrait startup orientation.

   

   As your application builds, you see messages in the Build Output window, as shown in Figure 3-6. Figure 3-6 actually shows the appearance of this window after the build process completes. Notice that it displays times for each step of the process, a completion message (“Install successfully finished in 10 s 676 ms.”), and a total time. You can even drill down into each of the individual steps to obtain further information.

   

   As activity occurs in the various windows, you see an indicator next to them telling you there is more information. In this case, notice that the success message is associated with the Run window.

3. Click the Run tab.

   You see a list of run events like those shown in Figure 3-7. Notice that the list tells you which parts of the code are running. This information isn’t very useful now, but you’ll find it invaluable later when debugging your app.

   

   It’s also useful to see how well your application is running. A profiler studies your application and determines how well it uses resources and what sort of load it places on the device. Because the profiler is separate from Android Studio, you may see one or more messages from your platform asking whether you want to grant permission to the profiler to perform its task. The next step requires you grant permission, but you can simply skip the next step if desired.

4. Click the Profiler tab.

   You see profiling information similar to that shown in Figure 3-7. Because this app is so simple, the CPU usage remains at 0%, for the most part. In this case, the app is using 42.1MB, there is no network activity, and it’s not even using enough energy to record.

5. Click the red square in the Profiler window.

   Profiling of your app stops.

Error message: Failed to find target

You’ve created a project with a certain target SDK or told the IDE to compile with a certain API level. But you haven’t installed that API level. If Android Studio displays a link offering to Install Missing Platform(s) and Sync Project, click the link. Otherwise, open the Android SDK manager and install that API level. For details, see Chapter 2 in this minibook.

If you don’t want to install a new API level, you can tinker with the SDK version numbers in the project’s build.gradle file. For details, see Chapter 4 of this minibook.

Error running ‘app’: No target device found

You must have at least one AVD configured before an app can run. In addition, the AVD must be able to support the app. Use the steps in the “Creating an Android virtual device” section of Chapter 2 of this minibook to fix this problem.

Error message: Android Virtual Device may be incompatible with your configuration

This message probably means that you haven’t created an AVD capable of running your project. If Android Studio offers to help you create a new AVD, accept it. Otherwise, open the AVD Manager to create a new AVD. For information about Android Virtual Devices and the AVD Manager, see Chapter 2 of this minibook.

You lose contact with the Android Debug Bridge (ADB)

The Android Debug Bridge (ADB) connects your development computer to a device that’s executing your new Android code. (The ADB also “connects” your development computer to a running emulator, even though the emulator is running on your development computer.)

If you see a message that hints of ADB trouble, try restarting your development computer’s Android Debug Bridge. Here’s how:

1. Click the Terminal tool button at the bottom of Android Studio’s main window.

   Congratulations! You just opened Android Studio’s Terminal tool window. If you’re a Mac or Linux user, you see the shell prompt. If you’re a Windows user, you see the Windows command prompt.

2. In the Terminal tool window, go to your ANDROID_HOME/platform-tools folder.

   For help finding your ANDROID_HOME folder, see the “Installing Android Studio” section in Chapter 2 of this minibook.

3. In the ANDROID_HOME/platform-tools folder, type the following two commands:

   Windows:

   adb kill-server
adb start-server

   Macintosh and Linux:

   ./adb kill-server
./adb start-server

For more information about the Android Debug Bridge, refer to see Book 1, Chapter 2.

You don't like whatever AVD opens automatically

In Chapter 2 of this minibook, you create an AVD. And, since the old Chapter 2 days, you may have created some additional AVDs. Now, when you launch an app, your computer fires up one of the many AVDs that you created. That’s fine, but what if the computer fires up your least-favorite AVD? To get control over which AVD starts up, do the following: In Android Studio’s main menu, choose Run⇒  Select Device. A context menu like the one shown in Figure 3-12 appears. The menu allows you to choose any of the devices you have created.

Notice that you can also choose to run your app on multiple devices. To use this option, you choose Run On Multiple Devices from the context menu, which displays the Select Deployment Targets dialog box, shown in Figure 3-13.

If you don’t see the device you want to use, perhaps you haven’t created it yet or accidentally deleted it. Choose Open AVD Manager in this case to create the device you want to use.

The Troubleshoot Device Connections option sees use only with devices you connect to your system using a USB connection. Selecting this option displays the Connection Assistant, which begins by scanning your system for USB devices that could be Android compatible. Just follow the directions the Connection Assistant provides to ensure that your system can see the device and to install appropriate drivers when it can’t.

The emulator stalls during startup

After five minutes or so, you don’t see Android’s lock screen or Android’s home screen. Here are several things you can try:

• Lather, rinse, repeat. Close the emulator and launch your application again. Sometimes, the second or third time’s a charm. On rare occasions, you may find that your first three attempts fail but the fourth attempt succeeds.
• Restart the Android Debug Bridge (ADB) server. Follow the instructions in the earlier section “You lose contact with the Android Debug Bridge (ADB).” And while you’re restarting things, it never hurts to restart Android Studio.
• If you have a more powerful computer, try running your app on it. Horsepower matters.

• Run your app on a real Android device. Testing a brand-new app on a real device makes us queasy. But Android’s sandbox is fairly safe for apps to play in. Besides, apps load quickly and easily on real phones and tablets.

  For instructions on installing apps to real Android devices, see the section “Testing Apps on a Real Device,” later in this chapter.

• Try the Genymotion emulator. For news about Genymotion, see Chapter 2 in this minibook.
• Switch to an Android Virtual Device with a lower resolution and screen density. In our experience, older AVDs consume fewer resources on your development computer. So, if an AVD drags you down, follow the instructions in the earlier section “You don’t like whatever AVD opens automatically.” Then, when you run an app, Android Studio prompts you with a Choose Device dialog box. Pick an AVD with the lowest API level (one that satisfies your app’s minimum SDK requirement), and you’ll be on your way.

You can lower an app’s target and minimum SDK version by editing the app’s build.gradle file. But if your app requires features that aren’t available in the lower target or SDK version, you won’t be happy with the results. In the best case, Android Studio displays an error message as soon as you make the change. In the worst case, you see no error message until you try to run the app. When you try to run the app, it crashes.

Error message: The user data image is used by another emulator

If you see this message, some tangle involving the emulator keeps Android from doing its job. First try closing and restarting the emulator.

If a simple restart doesn’t work, try the following steps:

1. Close the emulator.
2. In Android Studio’s main menu, choose Tools⇒  AVD Manager.
3. In the list of virtual devices, look for the AVD that’s causing you trouble.

4. In the Actions column, click the tiny downward-pointing arrow associated with that AVD. (See Figure 3-14.)

   A context menu appears.

   

5. In the context menu, select Wipe Data.

   A pop-up dialog box appears. The dialog box asks you to confirm the wiping of the AVD’s data.

6. In the Confirm Data Wipe pop-up dialog box, click Yes.

   The pop-up dialog box disappears (as you thought it would).

7. In the Actions column, click the right-pointing arrow (the arrow that looks like a Play button).

   As a result, Android Studio launches a new copy of the emulator, this time with a clean slate.

To read about the Android Virtual Device (AVD) Manager, see Chapter 2 in this minibook.

If the preceding set of steps doesn’t work, take a firmer approach, as follows:

1. Close the emulator.
2. Open whatever file explorer your computer uses to track down files.

3. In your user home folder, look for a folder named .android (starting with a dot).

   For tips on finding your user home folder, see Chapter 2 in this minibook.

4. From the .android folder, drill down even deeper into the avd folder.

   The avd folder contains a folder for each AVD that you've created.

5. Drill down one more level to the folder for the AVD that’s giving you trouble.

   For example, if you were running an AVD named Pie1 when you saw the Data Image Is Used by Another Emulator message, navigate to your Pie1.avd folder.

6. Inside your AVD’s folder, delete all the files whose names end with .lock.
7. Return to Android Studio and run your app again.

Error message: Unknown virtual device name

Android looks for AVDs in your home folder's .android/avd subfolder, and occasionally Android’s search goes awry. For example, consider that your Windows computer lists the home folder on an i drive. The AVDs are in i:Users<user name>.androidavd. But Android ignores the computer's home folder advice and instead looks in c:Users<user name>. When Android doesn't find any AVDs, Android complains.

You can devise fancy solutions to this problem with junctions or symbolic links. But fancy solutions require special handling of their own. To keep things simple, you can simply copy the i:Users<user name>.android folder's contents to c:Users<user name>.android. That fixes the problem.

The emulator displays a “process isn't responding” dialog box

The formal name for this dialog box is the Application Not Responding (ANR) dialog box. Android displays the ANR dialog box when an app takes too long to do whatever it’s supposed to do. When your app runs on a real device (a phone or tablet), the app shouldn’t make Android display the ANR dialog box. (Other chapters in this minibook give you tips on how to avoid the dialog box.)

But on a slow emulator, a few ANR boxes are par for the course. When you see the ANR dialog box in an emulator, the best idea is to select Wait. Within about ten seconds, the dialog box disappears and the app continues to run.

Changes to your app don’t appear in the emulator

Your app runs and you want to make a few improvements. So, with the emulator still running, you modify your app’s code. But after choosing Run⇒  Run ‘app’, the app’s behavior in the emulator remains unchanged.

When this happens, something is clogged up. Close and restart the emulator. If necessary, use the Wipe User Data trick that we describe in the section “Error message: The user data image is used by another emulator,” earlier in this chapter.