The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Eclipse, with the ADT plugin, had many structured editors and specialized dialogs for modifying Android project files and otherwise configuring Android project behavior.
Android Studio has fewer of those, and they are generally less critical. The editors and dialogs presented in this chapter can be useful, at least in some cases, but you do not need to use any of them to be able to create your Android projects. However, some may speed up your Android development a bit over working with bare resource and Gradle files.
Understanding this chapter requires that you have read the core chapters of this book, along with the chapter on Gradle and build variants.
The Project Structure dialog allows you to configure many aspects
build.gradle files from a tabbed property-style dialog, as
opposed to having to work with the Gradle scripts directly. On the
plus side, this can be easier. However, since Gradle is built on the
Groovy scripting language,
build.gradle files are not simple XML or
JSON data structures. It remains to be seen how well the Project
Structure dialog will be able to handle complex Gradle scripts.
To access the Project Structure dialog, choose File > Project Structure from the main IDE menu.
The left-hand side lists major areas of the dialog; choosing one of those switches to that area’s form on the right.
The sections that follow outline each of the major areas and what you can configure in them.
The Project Structure dialog opens up on the SDK Location area, where you can configure where your Android SDK is located, where your JDK is located, and where your NDK is located:
Figure 905: Project Structure Dialog, SDK Location Category
For new Android Studio 2.2+ installations, the default is for Android Studio to use a version of the Java JDK that ships with the IDE itself, in which case “Use embedded JDK (recommended)” will be checked.
Adjusting these in Project Settings affects this specific project. There is also File > Other Settings > Default Project Structure, where you can edit the default values to be used for new projects and projects that you import in the future.
The second entry in the Project Structure dialog category list is
“Project”. This allows you to configure four items found by default
build.gradle file in your project root or in the
implementationdirectives in your module’s
Figure 906: Project Structure Dialog, Project Settings Category
If you are using select portions of the Play Services SDK, the items under the “Developer Services” divider allow you to configure those portions. By default, they amount to checkboxes, to enable certain features:
Figure 907: Project Structure Dialog, Notifications Category
Below the “Modules” divider in the category list on the left will come all of your modules. If you are not using modules, there will be a single entry in the category list with the same name as your project, as a quasi-module.
Clicking on a module will bring up a set of tabs on the right to edit various properties of that module, independently of any other module in your project. The following sections outline the contents of those tabs.
The first tab is labeled “Properties” and allows you to adjust various
top-level settings in your module’s
Figure 908: Project Structure Dialog, Module Category, Properties Tab
compileSdkVersion(“Compile Sdk Version” drop-down)
buildToolsVersion(“Build Tools Version” drop-down)
repositoriesclosure (“Library Repository”)
aaptOptions(“Ignore Assets Pattern”)
If your module’s
build.gradle file has a
signingConfigs closure, the
“Signing” tab will let you edit those signing configurations:
Figure 909: Project Structure Dialog, Module Category, Signing Tab
Each signing configuration that you have defined will appear in the list on the left side of the tab. On the right are fields for you to fill in the signing configuration name, the keystore file and key alias to use, and the passwords to use for accessing that file and alias.
The green plus (“+”) icon on the right side of the list lets you define a new signing configuration, while the red minus (“-”) icon lets you delete an existing signing configuration.
The “Flavors” tab starts off with a single “flavor”, representing
defaultConfig settings. The green plus
icon next to the list of flavors lets you define a new flavor, while
the red minus icon lets you remove an existing flavor. Note that you
defaultConfig, as it is defined by the Gradle for
Figure 910: Project Structure Dialog, Module Category, Flavors Tab
On the right side of the tab, you can set or change the name of the
flavor, plus you can adjust various flavor (or
minSdkVersionvalue (“Min Sdk Version” drop-down)
targetSdkVersionvalue (“Target Sdk Version” drop-down )
testInstrumentationRunnerto use for instrumentation testing (“Test Instrumentation Runner”)
testApplicationIdvalue for instrumentation testing (“Test Application Id”)
versionNameto use (“Version Code” and “Version Name”), along with the suffix to apply to the version name (unique to this product flavor)
The “Build Types” tab allows you to adjust settings for the
release build types. The green plus
icon next to the list of build types lets you define a new build type, while
the red minus icon lets you remove an existing build type. Note that you
release, as they are defined by Gradle.
Figure 911: Project Structure Dialog, Module Category, Build Types Tab
On the right side of the tab, you can set or change the name of the
build type, plus you can adjust various settings in your
buildTypes closure, including:
debuggable, to control if the app is considered to be debuggable on production hardware (“Debuggable” drop-down)
jniDebuggableflag (“Jni Debuggable”)
renderscriptDebuggableflag (“Renderscript Debuggable”)
renderscriptOptimLevelproperty (“Renderscript Optim Level”)
minifyEnabled, to control whether the build process should attempt to strip out unused code (“Minify Enabled” drop-down)
pseudoLocalesEnabledflag (“Pseudo Locales Enabled”)
applicationId(“Application Id Suffix”)
versionName(“Version Name Suffix”)
zipalign(“Zip Align Enabled”)
If your project has any defined dependencies in a
these will appear in the “Dependencies” tab:
Figure 912: Project Structure Dialog, Module Category, Dependencies Tab
The tab is dominated by a two-column table, where the left column is the dependency itself. The right column is the “scope”, where the cell shows the current scope, and if you click on it, you get a drop-down list of available scopes:
Figure 913: Dependencies Tab, Showing Scope Drop-Down
Those scopes include:
androidTestImplementationdependency (i.e., one to be used only for instrumentation testing)
testImplementationdependency (i.e., one to be used only for unit testing)
compileOnlydependency (where the dependency is used only at compile time and its contents are not packaged into the APK file)
runtimeOnlydependency (where the dependency is not used at compile time, but its contents are packaged into the APK file)
The latter two scopes will be used infrequently.
If you click the green + button, you will be able to add a new dependency. A drop-down menu will let you choose between a library dependency (i.e., for an artifact in a repository), a file dependency, and a module dependency (i.e., to depend upon another module in your project).
Typically, you will be adding library dependencies. When you choose that option, another dialog appears to allow you to search for likely dependencies or type in the full dependency identifier (group ID:artifact ID:version).
Figure 914: Choose Library Dependency Dialog, As Initially Launched
Figure 915: Choose Library Dependency Dialog, With Search Results for “greenrobot”
The red - icon in the same toolbar as the green + will remove a dependency, while the up and down arrows allow you to reorder the dependencies.
The preview of this section was whisked away by a shark-infested tornado.