The Android Project Folder Structure View

After setting up the Android development environment using the Android Studio and creating the application, you can notice that the android project folder structure is as shown below.

Manifests Folder

The below image is the structure of the manifests folder in an Android application.

The Manifests folder contains a manifest file (AndroidManifest.xml) for your android application.

This manifest file will contain information about your application and its components, such as the Android version, access permissions, metadata, and so on.

It acts as an intermediate between the Android OS and your application.

The AndroidManifest.xml file contains information of your package, including components of the application such as activities, services, broadcast receivers, content providers etc.

It performs some other tasks also:

• It is responsible to protect the application to access any protected parts by providing the permissions.
• It also declares the android api that the application is going to use.
• It lists the instrumentation classes. The instrumentation classes provide profiling and other information’s. These information’s are removed just before the application is published etc.

This is the required xml file for all the android application and located inside the root directory.

A simple AndroidManifest.xml file looks like this:

Elements of the AndroidManifest.xml file

<manifest>

manifest is the root element of the AndroidManifest.xml file. It has package attribute that describes the package name of the activity class.

<application>

application is the subelement of the manifest. It includes the namespace declaration. This element contains several subelements that declares the application component such as activity etc.

The commonly used attributes are of this element are icon, label, theme etc.

android:icon represents the icon for all the android application components.

android:label works as the default label for all the application components.

android:theme represents a common theme for all the android activities.

<activity>

activity is the subelement of application and represents an activity that must be defined in the AndroidManifest.xml file. It has many attributes such as label, name, theme, launchMode etc.

Java Folder

The Java folder contains all the Java source code (.java) files that you will create during the application development, including the JUnit test code.

Whenever you create any new project/application, the class file MainActivity.java will be created automatically under the package name by default for example “rishiz.site.firstapp” here, as shown.

res (Resources) Folder

The res folder is a critical folder that contains all the non-code resources, such as bitmap images, UI strings, and XML layouts, as shown in the image.

The res folder includes different types of folders, such as:

• drawable
• layout
• mipmap
• values
• xml

Drawables

• Drawables contains the bitmap file to be used in the program.
• There are different folders to store the drawables, namely drawable-ldpi, drawable-mdpi, drawable-hdpi, drawable-xdpi, and so on.
  • Ldpi, mdpi, and hdpi stand for low density, medium density, and high-density screens, respectively.
• The folders intend to provide alternative image resources to specific screen configurations.
  • That is, the resources for various screen resolutions are stored in the respective folders, and the android system will choose it according to the pixel density of the device.

Layout

• It contains the XML files that define the User Interface of the application.

Menu

• XML files that define menus for the application go into this folder

Mipmap

• Used for placing the app icons only.
• Any other drawable assets should be placed in relevant drawable folders.

Values

• XML files that define simple values such as strings, arrays, integers, dimensions, colors, styles, and so on are placed in this folder.

Xml

• the “xml” folder is a common directory used to store XML files related to your Android application. XML files are used for various purposes in Android development, such as defining layout structures, menu items, animation resources, and more.

Gradle Scripts

The image above is the structure of the Gradle Scripts in an Android application.

In Android development, Gradle is the build system that is commonly used to automate the building, testing, and packaging of Android applications

Android Studio performs application builds in the background without any intervention from the developer.

This build process is handled using the Gradle system, an automated build toolkit designed to allow the configuration and management of building projects through a set of build configuration files.

Project-level Gradle file

This file is typically named build.gradle and resides in the root directory of your Android project. It defines build configurations and dependencies that are common to all modules within the project.

Some common elements found in the project-level Gradle file include:

buildscript: This block defines the build script dependencies used by the project, such as the Android Gradle Plugin.

repositories: This block specifies the repositories where Gradle should look for dependencies.

dependencies: This block declares the dependencies needed for the build script itself, such as plugins.

Module-level Gradle file

android: This block includes settings related to the Android-specific build configurations for the module. Some commonly used attributes within the android block are:

• compileSdkVersion: Specifies the Android SDK version against which the module should be compiled.
• buildToolsVersion: Defines the version of the Android build tools to use.
• defaultConfig: Configures default settings for the module, such as the application ID, minimum SDK version, target SDK version, and version code and name.
• buildTypes: Configures different build types, such as “debug” and “release,” and allows customization of their specific attributes like signing configurations, proguard rules, and build-specific manifest entries.
• productFlavors: Defines product flavors, which are customized versions of the module that can have their own configurations, resources, and code.
• sourceSets: Specifies the directories containing the module’s source code, resources, and assets.

 buildTypes: This block allows you to define custom build types specific to the module. Each build type can have its own configurations, such as enabling/disabling code shrinking, enabling debuggable builds, or specifying custom build-specific manifest entries.

minifyEnabled:The minifyEnabled attribute is typically found within the buildTypes block in the module-level Gradle file of an Android project.

When set to false, it disables the process of code shrinking and obfuscation during the build.

In the example above, the minifyEnabled attribute is set to false for the release build type. This means that when you build the project with the release configuration, code shrinking and obfuscation will be disabled.

Code shrinking, also known as “ProGuard,” removes unused code and resources from the compiled APK, resulting in a smaller APK file size. Obfuscation, on the other hand, renames classes, fields, and methods to make it more difficult for someone to reverse-engineer the code.

Disabling minifyEnabled can be useful during development or testing phases when you don’t require code shrinking and obfuscation. It can help speed up the build process and make debugging easier since the code retains its original form and names.

However, for the final release version of your application, it’s generally recommended to enable code shrinking and obfuscation (minifyEnabled true) to optimize the APK size and protect your code from reverse engineering.

productFlavors: This block is used to define different product flavors specific to the module. Each product flavor can have its own configurations, such as application ID suffixes, resource configurations, or custom source code.

dependencies: This block declares the dependencies required by the module. It specifies the external libraries or other modules within the project that the module depends on. Dependencies can be defined using the implementation, api, or compileOnly configurations, depending on the desired scope of the dependency.

gradle-wrapper.properties

The gradle-wrapper.properties file is an essential file in an Android project that is used by the Gradle Wrapper.

It resides in the root directory of the project alongside the Gradle Wrapper scripts (gradlew and gradlew.bat). The gradle-wrapper.properties file contains configuration settings for the Gradle Wrapper, specifying the version of Gradle to use for building the project.

• distributionBase and distributionPath: These properties specify the base directory and relative path where the Gradle distribution will be stored on the local machine. By default, GRADLE_USER_HOME points to the user’s Gradle home directory.
• zipStoreBase and zipStorePath: These properties specify the base directory and relative path where the downloaded Gradle distribution ZIP file will be stored on the local machine.
• distributionUrl: This property defines the URL from which the Gradle distribution will be downloaded. In the example above, it points to the distribution hosted on the official Gradle services.

When the Gradle Wrapper scripts are executed (e.g., running gradlew), they check the gradle-wrapper.properties file to determine the specified Gradle version. If the specified version is not already available locally, the Wrapper automatically downloads it and uses that version for the project build.

The gradle-wrapper.properties file is important for maintaining consistent build environments across different machines and ensuring that all developers working on the project use the same Gradle version. It allows projects to easily specify and distribute a specific Gradle version without requiring each developer to install and configure Gradle separately.

gradle.properties

This file contains project-wide properties that can be accessed and used in Gradle scripts. It allows you to define variables, such as API keys or custom configuration values, that can be shared across different Gradle files.

settings.gradle

This file defines the structure of the Android project, including the modules that are part of the project. It is used to specify which modules should be included in the build and can also be used to configure multi-module projects.

Next: How to run app in android studio.