Android Studio projects are built around the Gradle build system. When you create an Android Studio project, it's populated with two Gradle scripts and a couple of other important configuration files. I'm looking at this project, Gradle Scripts, and I'm using the Android view, so I'm only looking at files that I'll use during the development process. I'll open the Gradle Scripts folder and go to this file, local.properties. Now, I'm not including this file in each of the projects in the exercise files because its setting is unique to each computer's file system.
- [Instructor] Android Studio projects are built around the Gradle build system. When you create an Android Studio project, it's populated with two Gradle scripts and a number of other important configuration files. I'm looking at this project in the project window with the Android scope, and I've opened up the Gradle Scripts virtual directory. The purpose of this virtual directory in the Android scope is to group all of the configuration files together in a single list even though in reality they're stored in different locations on the hard disk. I'll start with the file local.properties.
This is a file that includes the location of your Android SDK. It'll look different on Windows versus Mac, and it'll also be very specific to your particular directory structure. If you delete the local.properties file, it'll be regenerated automatically when you start up the project. You can change the location of your Android SDK, but it's best not to do it in this particular file. Instead, you should go to the Project Structure dialogue, which is under the File menu, and you'll see the SDK location is listed right at the top.
If I were to change to another location here, that would be reflected in the local.properties file automatically. You can also switch to a different JDK here. That's the Java Development Kit. In Android Studio 2.2, you're using an embedded version of the JDK, and that's the recommended approach. That will avoid conflicts that might occur between the expected version of OpenJDK and another version of Java that you might download from the Oracle website.
You'll see other useful settings in the Project Structure dialogue including a lot of settings relating to your app module, the module that represents your particular application. I'll come back to some of these in just a moment. Next, I'm going to open the build.gradle file in the app module. This is where you define a number of critical properties. Every app needs to have a compileSdkVersion and a targetSdkVersion, and those two values should always match each other. I'm working with Android 7 Nougat, and that means I'm working with API level 24.
That's the numeric value that you apply here. You also set a minimum SDK version in this file, and this will control which devices can install your app from the Google Play store and from other distribution channels. API level 15 means Android 4.0.3 Ice Cream Sandwich, so that means I'm not supporting versions of Android prior to that API level. The buildToolsVersion matches up with a component of the Android SDK, and you need to make sure that you've downloaded the correct version of the build tools in the SDK Manager.
I'll go to the SDK Manager and show you where that is. I'll click on SDK Tools. Then, I'll show package details, and I'll scroll down and show that I've installed 24.0.3 down here. Now, if you're working on multiple projects, you might have one project that's working with 24.0.1 and one with 24.0.3, and to make sure things are stable you might not want to update everything to the same version. And that's fine. You can have multiple versions of the build tools installed at the same time.
Whatever you need for your particular projects. The applicationId is your app's unique identifier, and it's stated in a couple of different places. Here, in the Gradle build file but also in the application manifest where it's shown here as the package attribute of the manifest element. These two values must match each other, and they also need to match the base package that you use for your Java code. If you need to change the unique identifier, it's pretty easy to do with Android Studio.
I typically start in the Java package, and then I refactor the name of the package by pressing Shift + F + 6. It tells me multiple directories correspond to the package, and so I want to rename the package. I'm not going to follow through with that, because there's typically some cleanup to do. But, if you need to do it, this is where I would start. Only one app with a particular application ID can be a part of the Google Play store, and there are some restrictions. If you were to try to package and upload this app to the Google Play store, it would be rejected, because com.example is a reserved domain name.
Next is the versionCode and versionName. Each time you deploy a version of your application it'll have a unique version code. The version code is an integer, and it's never actually seen by the end user. Each time you update your application typically you increment this value by one. The version name can be seen by the user in a number of different contexts, and you can choose whatever naming convention you want. For example, some developers will start with 1.0, and then for a bug fix version they might set it to 1.0.1.
Or, for a significant change, it might go to 1.1, and then only with major new releases would you change the actual integer value. Notice that whenever you make any changes to these Gradle files you'll be prompted to resync your application, and you need to do that. You can click the Sync Now link up here to make that happen. I'll go back to versionName of one and click Sync Now, and I see messages at the bottom of the screen indicating the progress of the task. Under buildTypes you'll see something called release, and this is something called a build variant.
If I click on the Build Variants tab on the side, I see right now I only have a build variant of debug, and that means I haven't actually built a release version of my application yet. Within the release section, there are properties named minifyEnabled and proguardFiles. Minifying an app means that you're compressing and obfuscating the application's code, and you do that with a legacy build process using a product named ProGuard that's packaged with the SDK. If you switch over to the Jack compiler toolchain, then the same minify feature will be happening, but instead of ProGuard it'll be handled by the Jack compiler chain.
And, finally, down here at the bottom are the dependencies. This is where you register various code libraries that you need to build your application. By default, almost every project that you create in Android Studio will have the appcompat support repository registered. When using the support repositories, the major version number must match the version of your compileSdkVersion, 24 in this case. And if there is an upgrade to the support repository, when you open this file you'll prompted to update it to the most recent version.
It's typically safe to always update to the most recent version of the support repositories. Other support repositories might appear, such as the design repository, depending on which activity template you used when you created your project. And, finally, there's a compile directive here that's referring to the libs directory. Under the Android scope you don't see this directory, so I'll switch over to Project, and then I'll see under the app module directory that there's an empty libs directory. If I have a Java JAR file that I want to incorporate into my application, I can add the JAR file to that directory, and then I would need to right-click on that file and say add it as a library.
It would then be compiled with the rest of the application because it's a library and because of this compile directive. So that's a little bit about how the Gradle system works and what properties you need to control when you build and configure your application.
- Installing Android Studio
- Creating your first Android Studio project
- Managing profile files, including Gradle scripts and support libraries
- Defining screens with activities
- Implementing designs in XML layouts