Android Architecture Generic
Universal Project Blueprint — understanding directories, system components, build lifecycles, and cross-runtime executions for both Java and Kotlin.
Table of Contents
The App Module Directory Tree
An Android project is divided into logical modules. In a standard single-module architecture, the default app/ directory contains all the logic assets, source code targets, and deployment configuration parameters.
MyAndroidApp/ ├── gradle/ # Wrapper binaries for build execution ├── app/ # Main application container module │ ├── build.gradle.kts # Module-specific configuration dependencies │ └── src/ │ ├── main/ │ │ ├── AndroidManifest.xml # System declaration ledger │ │ ├── java/ # Source directories (Holds both .java and .kt files) │ │ └── res/ # Static visual UI/UX layout resources └── build.gradle.kts # Project-level generic configuration root
The AndroidManifest.xml Entry
The AndroidManifest.xml is the ultimate ledger file read by the Android OS before booting your software package. Regardless of language choice, you must register hardware permissions and structural views here.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"> <!-- Hardware interaction declaration permissions --> <uses-permission android:name="android.permission.INTERNET" /> <application android:label="@string/app_name" android:icon="@mipmap/ic_launcher"> <!-- Entry point Activity view node declaration --> <activity android:name=".MainActivity" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>
App Resources & R.java Mapping
The res/ directory houses non-code visual components. During the build workflow, the build system automatically generates a unique tracking file named R.java, turning asset pathways into static integer addresses referenced by your logic code.
The Gradle Build System Matrix
Android utilizes **Gradle** to orchestrate source code file compilation, dependency downloading, and final code signing processes. Modern configurations use Kotlin Script (.gradle.kts) or Groovy (.gradle).
plugins {
id("com.android.application")
id("org.jetbrains.kotlin.android") // Only declared if using Kotlin extensions
}
android {
namespace = "sh.vidux.project"
compileSdk = 34
defaultConfig {
applicationId = "sh.vidux.project"
minSdk = 26 // Lowest Android version baseline requirement
targetSdk = 34
versionCode = 1
}
}
dependencies {
// External library resolution mapping hooks
implementation("androidx.core:core-ktx:1.12.0")
}
Application & Activity Lifecycles
Unlike standard desktop software execution loops, the Android system controls process memory allocations directly. Visual containers called **Activities** travel along a strict state path to adapt smoothly to device interruptions.
// Memory space allocation and setup context initialization layer onCreate() ──> onStart() ──> onResume() // [ App UI is fully active and interactive ] // Interruption flow processing tracking triggers (e.g., incoming call, splitscreen) onPause() <── Application yields system rendering focus onStop() <── Screen element layout is completely hidden out of view boundary // Destruction loop sequence onDestroy() <── Memory space reference unlinked from active heap processing
Core System Components (The Big Four)
An application system interaction layer is constructed by utilizing varying combinations of the **Four Fundamental Component Elements** managed directly by the Android OS runtime layer.
┌───────────────────────────────────────────────────────────────────────┐ │ ANDROID COMPONENTS │ ├───────────────────┬───────────────────┬───────────────────────────────┤ │ Activities │ Services │ Broadcast Receivers │ │ Handles user │ Background task │ Listens for system alerts │ │ interaction and │ processing without│ like battery depletion hooks │ │ interface layouts │ UI dependencies │ │ └───────────────────┴───────────────────┴───────────────────────────────┘ * Linked seamlessly across application modules using asynchronous messaging: INTENTS * Sharing database schemas across isolated storage bounds: CONTENT PROVIDERS
Main Thread vs Background Workers
Android runs all interface drawing operations on a single, isolated execution track known as the **Main Thread** (or UI Thread). Forcing network requests or file modifications onto this track locks up the UI, triggering an immediate app freeze.
┌─────────────────────────────────────────────────────────────┐
│ MAIN (UI) THREAD │
│ Renders UI layout loops · Handles user touch interactions │
└──────────────────────────────┬──────────────────────────────┘
│ Offloads intensive tasks
▼
┌─────────────────────────────────────────────────────────────┐
│ BACKGROUND WORKER POOL │
│ Executes network API calls · Database I/O transactions │
├──────────────────────────────┼──────────────────────────────┤
│ JAVA CONCURRENCY FRAMEWORK │ KOTLIN COROUTINES PIPELINE │
│ ThreadPools / Executors │ Dispatchers.IO Execution │
└─────────────────────────────────────────────────────────────┘
Compilation Flow: Java/Kotlin to ART
Whether you choose to write your app logic in Java or Kotlin, both toolchains emit standard JVM instructions. A secondary compilation phase then compresses these bytecode files into custom register configurations optimized for mobile devices.
[ Source Files ] ────> (.java / .kt source code sheets)
│
▼ (javac / kotlinc tools compile source assets)
[ JVM Bytecode ] ────> (Standard intermediate .class structural packages)
│
▼ (The R8/D8 compilers optimize and compress byte strings)
[ Dex Bytecode ] ────> (Unified classes.dex layout file payload)
│
▼ (Assembled into final installation package file)
[ APK Archive ] ────> Shipped directly onto the target user hardware
│
▼ (Processed by the local on-device hardware virtual layer)
[ Android Runtime (ART) ] Run using AOT/JIT native machine code execution loops