Every Android project follows a familiar structure that helps tools and developers find code and resources quickly even when the project grows to hundreds of files across many features. At first the folder tree can look confusing because the editor shows a simplified view that hides some folders while the disk view shows everything in a more detailed layout. Learning the standard structure saves time because you stop guessing where a layout file lives or why a build setting changes behaviour across the whole app. This guide explains the manifest and the source folders and the resource folders and the Gradle files in plain language with practical examples. Once you know these parts you can open any project and orient yourself within minutes instead of hours.
The top level of a project usually contains the Gradle wrapper and settings files and one or more modules with the app module being the most important module for a typical single app project. Each module has its own build file and its own source sets that separate main code from test code and from build variants such as debug and release configurations. The editor view groups files by type so layouts and drawables and values appear together even though they live in different folders on disk in a structured way. Switching to the project files view reveals the real disk layout and that view is useful when you need to find a generated file or check a configuration file directly. Knowing both views helps you move between high level navigation and detailed troubleshooting without getting lost in the folder tree.
The Manifest as the App Identity Card
The Android manifest is a single XML file that tells the system about your app identity and its components and the permissions it needs to perform its work on a device. It declares activities and services and receivers and providers so the system knows which screens can launch and which background work can run under what conditions. It also declares the package name and the application theme and the icon and the label that users see on their home screen and in system settings. Permissions in the manifest act as a declaration of intent and modern Android versions still require runtime requests for sensitive permissions even when they appear in this file. Editing the manifest carelessly can break launching or block features so you should change one entry at a time and test the result.
The manifest also controls how activities behave when they launch and how they interact with recent apps and deep links that open a specific screen from a web link or a notification. Intent filters in the manifest tell the system which actions your activity can handle and that mechanism powers sharing and opening files from other apps in a controlled way. Meta data entries can pass configuration to libraries and to system services without hard coding values in your source code where they are harder to change. When you add a library that needs a component the build system often merges library manifests into your app manifest automatically and conflicts can appear if two libraries declare the same component differently. Reading the merged manifest during troubleshooting reveals the final result and it explains behaviour that the source manifest alone does not show.
- Activities declare screens and their launch modes and their parent relationships for navigation.
- Services declare background work and whether the system may run them in the foreground.
- Receivers declare responses to system broadcasts such as boot completion or connectivity changes.
- Permissions declare access needs and sensitive permissions still need runtime approval from users.
- Meta data passes library configuration without hard coding values deep inside source code.
Source Folders and Package Organisation
Source code lives under a source set folder with a package path that mirrors your application identifier in a reverse domain style that keeps classes organised by feature or layer. Keeping related classes together by feature makes a project easier to navigate than grouping every activity in one folder and every adapter in another folder with no regard for the screens they serve. A feature folder can hold its activity and its view model and its adapter and its small helper classes so a developer can understand one screen without jumping across the whole tree. Test code lives in separate source sets so test helpers never ship inside the production app package and never increase the installed size for users. That separation also lets the build system run tests without packaging test code into a release artifact by mistake.
Package names should stay stable after release because changing the application identifier breaks updates for existing users and changes how the system identifies your app on a device. Inside the package you can refactor freely and move classes between feature folders as long as you update imports and keep public interfaces clear for other modules. Kotlin files and Java files can coexist in the same source set during a migration and the build system compiles both into the same output without extra configuration in most cases. You can learn more about language choices in Kotlin versus Java for modern Android development when you plan a mixed codebase for your team. Good package discipline pays off as soon as a second developer joins the project and needs to find code quickly.
Resources Under Res and Assets
Resource folders hold layouts and drawables and strings and colours and dimensions and menus that the system can select based on device configuration such as screen size and language and theme. Layout files describe user interfaces in XML and they reference string resources instead of hard coded text so translation becomes a matter of adding a new values folder for each language. Drawable resources can be vector graphics or bitmap images and vector drawables scale cleanly across densities without multiplying image files for every screen type. Values files hold colours and dimensions and styles that keep a consistent look across screens because changing one colour value updates every screen that references it. This separation of interface description from logic code makes design changes safer and faster than editing text inside many activity files.
Resource qualifiers let you provide alternative layouts for tablets and landscape orientation and dark themes without writing branching code that checks device properties in every activity. The system picks the best matching resource at runtime and your code simply asks for a resource by name without knowing which variant was chosen for the current device. Assets differ from resources because assets keep original file names and folder structure and your code opens them by path when you need raw files such as fonts or data files. Resources get compiled and assigned identifiers that code references through a generated class while assets remain as files inside the package for direct reading. Understanding this distinction prevents confusion when a file works in one place but cannot be found through the other access method.
Gradle Files That Drive the Build
Gradle build files define dependencies and plugins and build types and product flavours that control how your app compiles and packages for different environments and audiences. The project level build file declares plugin versions and repository locations that all modules can share so version management stays in one place for the whole project. The module level build file declares the application identifier and the minimum and target software versions and the dependencies for that module alone so each module can evolve with its own needs. Dependencies can come from local modules or from published libraries and Gradle resolves versions and downloads artifacts from configured repositories during sync and build. Changing a dependency version can change behaviour across the app so you should update one library at a time and run tests after each change.
Build variants combine build types and product flavours to produce different app versions from the same code base for development and testing and production release. A debug variant enables debugging tools and uses a debug signing key while a release variant enables shrinking and obfuscation and requires a proper signing configuration for distribution. Product flavours can change the application identifier suffix and resource values so a free version and a paid version can share most code while differing in features and branding. Gradle tasks automate compilation and testing and packaging and you can run them from the IDE or from the command line with identical results when the configuration is correct. Learning Gradle basics turns build errors from mysterious failures into readable messages that point to a specific file and setting.
Working With the Structure Every Day
A practical daily habit is to open the manifest when you add a new screen and to check the resource folders when you add a new string or image so nothing lands in a random location that later developers cannot find. Name layouts with a clear prefix for their screen and name drawables by purpose rather than colour so a later redesign does not force a rename across many files. Keep strings in resource files from the start because retrofitting translations into hard coded text across dozens of activities takes far longer than writing a resource reference once. Review the module build file when you add a library because a forgotten dependency or a version conflict often explains a missing class error during compilation. Small habits like these keep the project structure clean without requiring a large cleanup effort at the end of development.
When you inherit an unfamiliar project start by reading the manifest and the module build file and then browse the main source package by feature to build a mental map before you change any code. Run the project first and note which screens work and which features use network or database code so your later changes respect existing architecture. You can then explore related topics such as setting up Android Studio for beginners if your environment needs attention before serious work begins. Another useful step is building responsive layouts for phones tablets and foldables because layout resources play a large role in the structure you just learned. A clear mental map makes every later task faster and it reduces the risk of breaking a feature you did not know existed.
app/build.gradle.kts
plugins { id("com.android.application") }
android {
namespace = "com.example.myapp"
compileSdk = 34
defaultConfig { applicationId = "com.example.myapp" }
}The steps above follow the approach described in the official developer documentation for this platform and reflect common practice used by experienced developers when they build and test Android apps in a careful and organised way.
