Android Project Structure: Your App's Filing Cabinet

WHY IT EXISTS To provide a consistent, predictable layout for all Android applications. Without a standard structure, the build tools wouldn't know where to find source code, user interface layouts, or configuration files, making it impossible to compile and package an app reliably. This convention over configuration saves developers from reinventing the wheel on every project.

THE MENTAL MODEL An Android project is like a blueprint for a house. It has designated rooms for different functions: the java or kotlin folder is the living area where the main logic happens; the res folder is the storage room for all materials like images, text, and colors; and the AndroidManifest.xml is the front door, declaring the house's identity to the outside world. The Gradle scripts are the construction crew's instructions, detailing how to assemble everything.

HOW IT WORKS An Android project is composed of one or more modules. A typical app starts with a single app module containing these key directories: manifests: Holds AndroidManifest.xml, which declares essential app information like its name, permissions, and components (Activities, Services) to the Android OS. java or kotlin: Contains your application's source code, organized by package name. res: Contains all non-code resources. This is subdivided into folders like drawable for images, layout for UI XML files, mipmap for launcher icons, and values for collections of strings, colors, and styles. Gradle Scripts: These files (build.gradle or build.gradle.kts) define the build configuration. The module-level file specifies dependencies and app-specific settings, while the project-level one configures settings for all modules.

WHEN TO USE IT This structure is mandatory for all Android app development using standard tools like Android Studio and Gradle. You interact with it constantly when adding new screens, defining UI, managing dependencies, or including third-party libraries.

WHEN NOT TO USE IT You wouldn't use this specific structure for non-Android projects, like a standalone backend service or a pure Java library. While those projects have their own conventions (e.g., from Maven or standard Gradle), they don't use Android-specific folders like res or require an AndroidManifest.xml.

ONE CANONICAL EXAMPLE To add a new user profile picture, you would place the image file (e.g., profile_avatar.png) into the app/src/main/res/drawable folder. Then, in your UI layout file (e.g., app/src/main/res/layout/activity_profile.xml), you would reference it using @drawable/profile_avatar. You never use a direct file path like C:/Users/....