Gradle ایک بلڈ سسٹم ہے جو Android ایپلی کیشنز کی کمپائلیشن، جانچ اور پیکیجنگ کو خودکار کرتا ہے۔ Apache Ant یا Maven کے برعکس، یہ انکریمنٹل بلڈ اور نتائج کیشنگ کو سپورٹ کرتا ہے۔ اس کی خصوصیات کے بارے میں مزید جاننے کے لیے سرکاری Gradle دستاویزات دیکھیں۔ 2013 سے، یہ ٹول Android Studio میں Android پروجیکٹس کے لیے معیاری بلڈ سسٹم کے طور پر استعمال ہو رہا ہے۔
اہم نکات
Gradle ایک اوپن سورس بلڈ آٹومیشن ٹول ہے جو Java میں لکھا گیا ہے اور JVM پر چلتا ہے۔ یہ ان پٹ کے طور پر سورس کوڈ، انحصارات اور وسائل لیتا ہے، اور آؤٹ پٹ کے طور پر Android کے لیے APK یا AAB — ایک تیار ایپلی کیشن — تیار کرتا ہے۔ اس کے مرکز میں، Gradle ٹاسکس کے ڈائریکٹڈ ایسائکلک گراف (DAG) کے تصور کا استعمال کرتا ہے، جہاں ہر ٹاسک کام کی ایک ایٹمی اکائی ہے اور ان کے درمیان روابط عملدرآمد کی ترتیب کا تعین کرتے ہیں۔ Make یا Ant کے برعکس، Gradle کو دستی طور پر اقدامات کی ترتیب بیان کرنے کی ضرورت نہیں ہے: ٹاسکس کے درمیان انحصار کا اعلان کرنا کافی ہے، اور سسٹم خود بہترین ترتیب کا تعین کرے گا۔ یہ طریقہ Gradle کو کسی بھی حجم کے پروجیکٹس کے لیے لچکدار اور قابل توسیع بناتا ہے۔
سسٹم تین عملدرآمد مراحل کا استعمال کرتا ہے: ابتداء (حصہ لینے والے پروجیکٹس کی شناخت)، کنفیگریشن (ٹاسک گراف کی تعمیر) اور عملدرآمد (مطلوبہ ترتیب میں ٹاسک چلانا)۔ کنفیگریشن کا مرحلہ Gradle کی ایک کلیدی خصوصیت ہے: ٹاسک شروع ہونے سے پہلے پورا بلڈ اسکرپٹ چلتا ہے، جو شرائط کی بنیاد پر گراف میں متحرک تبدیلیوں کی اجازت دیتا ہے۔ یہ ممکن بناتا ہے، مثال کے طور پر، کوڈ کو نقل کیے بغیر صرف مخصوص بلڈ ویریئنٹس کے لیے ٹاسک شامل کرنا۔ بلڈر Groovy میں لکھا گیا ہے، لیکن کنفیگریشن فائلیں دو زبانوں کو سپورٹ کرتی ہیں: Groovy DSL اور Kotlin DSL۔
Gradle کے لیے Android پلگ ان com.android.application اور com.android.library پر مشتمل ہے، جو Android ٹولز کے ساتھ کام کرنے کے لیے پروجیکٹ میں ٹاسک شامل کرتے ہیں۔ جب کوئی ڈویلپر بلڈ شروع کرتا ہے، Gradle ترتیب وار درجنوں ٹاسکس کو انجام دیتا ہے: javac یا kotlinc کے ذریعے Kotlin اور Java کی کمپائلیشن، AAPT2 کے ذریعے وسائل کی پروسیسنگ، R.java کی تخلیق، D8 یا R8 کے ذریعے بائٹ کوڈ کو DEX میں کمپائلیشن، APK پر دستخط اور زپ کرنا۔ ہر ٹاسک چیک کرتا ہے کہ آیا اس کا ان پٹ ڈیٹا تبدیل ہوا ہے، اور اگر نہیں، تو کیش شدہ نتیجہ استعمال کرتا ہے۔ اس میکانزم کو انکریمنٹل بلڈ کہا جاتا ہے اور یہ مکمل دوبارہ تعمیر کے مقابلے میں دوبارہ کمپائلیشن کو 60–80% تیز کرتا ہے۔
Android ماڈیول کی کنفیگریشن build.gradle.kts فائل کے android بلاک میں سیٹ کی جاتی ہے۔ بلاک کے اندر، compileSdk، minSdk، targetSdk، ایپ ورژن، دستخط اور دیگر پیرامیٹرز کی وضاحت کی جاتی ہے۔ Gradle خود بخود ہر ماڈیول کے لیے متعدد بلڈ ویریئنٹس تخلیق کرتا ہے — قسم (release, debug) اور فلیور کا مجموعہ۔ مثال کے طور پر، دو فلیورز اور دو قسموں والے ماڈیول کے لیے، Gradle چار ٹاسک تخلیق کرتا ہے: assembleDemoDebug، assembleDemoRelease، assembleFullDebug، assembleFullRelease۔ ان تمام ٹاسکس کو انفرادی طور پر انجام دیا جا سکتا ہے یا ایک ہی کمانڈ سے تمام ویریئنٹس کے لیے ایک ساتھ چلایا جا سکتا ہے۔
ہر Android پروجیکٹ میں دو سطحوں کی کنفیگریشن ہوتی ہے: روٹ build.gradle.kts (تمام ماڈیولز کے لیے ترتیبات) اور ماڈیول-سطح build.gradle.kts (ایک مخصوص ماڈیول کے لیے ترتیبات)۔ روٹ فائل میں پلگ انز کو لاگو کیے بغیر اعلان کیا جاتا ہے، ریپوزٹریز اور مشترکہ متغیرات۔ ماڈیول فائل میں، پلگ انز مخصوص ماڈیول پر لاگو ہوتے ہیں اور بلڈ پیرامیٹرز کنفیگر کیے جاتے ہیں۔ یہ طریقہ ورژن کیٹلاگ یا ext-بلاک کے ذریعے انحصار ورژنز کے مرکزی انتظام کی اجازت دیتا ہے۔
@Suppress("UnstableApiUsage")
plugins {
id("com.android.application") version "8.2.2"
id("org.jetbrains.kotlin.android") version "1.9.22"
}
android {
namespace = "com.example.myapp"
compileSdk = 34
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
}dependencies بلاک build.gradle.kts کا ایک اور اہم عنصر ہے۔ یہ ان لائبریریوں، ماڈیولز اور فائل انحصاروں کی فہرست دیتا ہے جن کی ایپلی کیشن کو ضرورت ہے۔ Gradle متعدد انحصار کنفیگریشنز کو سپورٹ کرتا ہے: implementation (صرف موجودہ ماڈیول کے لیے دستیاب)، api (منحصر ماڈیولز کے لیے بھی دستیاب)، testImplementation (صرف ٹیسٹ کے لیے)، androidTestImplementation (آلاتی ٹیسٹ کے لیے) اور compileOnly (صرف کمپائلیشن کے وقت)۔ ہر کنفیگریشن انحصار گراف میں کلاس ویوزیبلٹی کا انتظام کرتی ہے، جو بلڈ ٹائم اور حتمی آرٹیفیکٹ کے سائز کو متاثر کرتی ہے۔
dependencies {
implementation("androidx.core:core-ktx:1.12.0")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
implementation("androidx.activity:activity-compose:1.8.2")
testImplementation("junit:junit:4.13.2")
androidTestImplementation("androidx.test.ext:junit:1.1.5")
}Build variant منفرد ترتیبات، کوڈ اور وسائل کے ساتھ ایپ ورژن کی وضاحت کرنے والا بلڈ ٹائپ اور پروڈکٹ فلیور کا مجموعہ ہے۔ بلڈ ٹائپ پیکیجنگ کے پیرامیٹرز کی وضاحت کرتا ہے: debug (ڈیبگنگ اور .debug لاحقے کے ساتھ) یا release (مبہم کاری اور دستخط کے ساتھ)۔ پروڈکٹ فلیور فعالی ویریئنٹس کی وضاحت کرتا ہے: مثال کے طور پر، demo (محدود ورژن) اور full (اضافی خصوصیات کے ساتھ مکمل ورژن)۔ Gradle ہر مجموعے کے لیے خود بخود ٹاسک تخلیق کرتا ہے، جس سے تمام ورژنز کو ایک ہی کمانڈ سے بنایا جا سکتا ہے۔
android {
buildTypes {
release {
isMinifyEnabled = true
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
applicationIdSuffix = ".debug"
}
}
flavorDimensions += "version"
productFlavors {
create("demo") {
dimension = "version"
applicationIdSuffix = ".demo"
}
create("full") {
dimension = "version"
applicationIdSuffix = ".full"
}
}
}ہر build variant کا ایک علیحدہ سورس سیٹ ہوتا ہے۔ Gradle ڈائرکٹریز src/demo/release، src/full/debug اور دیگر استعمال کرتا ہے، جو ایک مخصوص ویریئنٹ کے لیے منفرد وسائل، مینی فیسٹ اور سورس فائلیں ذخیرہ کرتی ہیں۔ مشترکہ کوڈ src/main میں رہتا ہے۔ یہ طریقہ مرکزی منطق کو دوبارہ استعمال کرنے اور صرف مختلف حصوں کو تبدیل کرنے کی اجازت دیتا ہے: سٹرنگز، آئیکنز، API اینڈپوائنٹس یا کنفیگریشن فائلیں۔ ایک سورس سیٹ main سے کسی بھی وسائل کو اووررائیڈ کر سکتا ہے: مینی فیسٹ، drawable، values یا حتیٰ کہ Kotlin کلاسز۔ کسی مخصوص ویریئنٹ کی تعمیر کرتے وقت، Gradle main اور متعلقہ سورس سیٹ سے فائلوں کو ضم کرتا ہے، جس میں ویریئنٹ کی فائلوں کو ترجیح دی جاتی ہے۔
Gradle پلگ ان ایکو سسٹم Android ایپلی کیشن ڈویلپمنٹ کے تمام مراحل کا احاطہ کرتا ہے۔ Google کے سرکاری پلگ انز میں com.android.application (ایپ ماڈیول کے لیے)، com.android.library (لائبریری ماڈیول کے لیے)، com.android.test (ٹیسٹ ماڈیولز کے لیے) اور JetBrains کے Kotlin پلگ انز شامل ہیں۔ پلگ انز پروجیکٹ میں نئے ٹاسک شامل کرتے ہیں، نئے کنفیگریشن بلاکس کے ساتھ DSL کو بڑھاتے ہیں اور اضافی ٹولز کو جوڑتے ہیں۔ com.android.application پلگ ان کے بغیر، کوئی پروجیکٹ APK نہیں بنا سکتا: یہ پلگ ان تمام Android-مخصوص ٹاسکس کو رجسٹر کرتا ہے اور انہیں بلڈ گراف میں جوڑتا ہے۔
تیسرے فریق کے پلگ انز زیادہ مخصوص کام حل کرتے ہیں۔ Google Services (com.google.gms.google-services) Firebase اور Google Play Services کو مربوط کرتا ہے، خود بخود بلڈ میں google-services.json داخل کرتا ہے۔ Hilt (dagger.hilt.android.plugin) کمپائلیشن کے وقت انحصار انجیکشن کوڈ تیار کرتا ہے۔ Safe Args (androidx.navigation.safeargs.kotlin) فریگمنٹس کے درمیان نیویگیشن کے لیے ٹائپ-سیف کلاسز بناتا ہے۔ ہر پلگ ان روٹ build.gradle.kts میں plugins بلاک کے ذریعے شامل کیا جاتا ہے اور عموماً کم سے کم کنفیگریشن کی ضرورت ہوتی ہے۔ Gradle پلگ انز کے درمیان عبوری انحصاروں کو خود بخود حل کرتا ہے اور Bom فائلوں اور ورژن کیٹلاگز کے ذریعے ورژن مطابقت کو یقینی بناتا ہے۔
ٹاسک Gradle میں کام کی ایک ایٹمی اکائی ہے۔ ہر ٹاسک میں ان پٹ ڈیٹا، آؤٹ پٹ ڈیٹا اور ایک عمل ہوتا ہے۔ Android کے لیے بلٹ ان ٹاسکس میں assemble (تمام ویریئنٹس کی تعمیر)، lint (کوڈ کی جانچ)، test (یونٹ ٹیسٹ چلانا) اور clean (عارضی فائلوں کی صفائی) شامل ہیں۔ ڈویلپرز Groovy یا Kotlin DSL کا استعمال کرتے ہوئے اپنے ٹاسک شامل کر سکتے ہیں۔ کسٹم ٹاسک معمول کے کاموں کو خودکار کرنے کے لیے مفید ہیں: رپورٹس تیار کرنا، آرٹیفیکٹس کاپی کرنا، ٹیسٹ ڈیوائسز پر ڈپلائے کرنا یا CI سسٹمز کے ساتھ انضمام۔
tasks.register("printBuildInfo") {
description = "بلڈ کی معلومات دکھاتا ہے"
group = "custom"
doLast {
println("Build variant: ${project.name}")
println("Version: ${android.defaultConfig.versionName}")
}
}ہر ٹاسک dependsOn میکانزم کے ذریعے دوسرے ٹاسکس پر منحصر ہو سکتا ہے۔ اگر ٹاسک A، ٹاسک B پر منحصر ہے، Gradle ضمانت دیتا ہے کہ B، A سے پہلے عمل میں آئے گا۔ سسٹم کو ہر جوڑی کے لیے دستی طور پر ترتیب بتانے کی ضرورت نہیں ہے — انحصار کا اعلان کرنا کافی ہے، اور Gradle آزاد ٹاسکس کے متوازی عملدرآمد کے لیے ایک ڈائریکٹڈ گراف بنائے گا۔ Android پلگ ان کے بلٹ ان ٹاسک پہلے سے آپس میں جڑے ہوئے ہیں: lint کمپائلیشن پر منحصر ہے، test assemble پر منحصر ہے، assembleDebug compileDebugKotlin پر منحصر ہے۔ ڈویلپرز dependsOn، mustRunAfter یا shouldRunAfter کا استعمال کرتے ہوئے گراف کے کسی بھی نوڈ میں اپنے ٹاسک داخل کر سکتے ہیں۔
اکثر مسائل میں سے ایک انحصار ورژن تصادم ہے، جب دو لائبریریوں کو ایک ہی عبوری انحصار کے مختلف ورژنز کی ضرورت ہوتی ہے۔ Gradle تصادم کی غلطی کی اطلاع دیتا ہے، لیکن ہمیشہ خودکار حل پیش نہیں کرتا۔ تشخیص کے لیے، ./gradlew :app:dependencies کمانڈ استعمال کریں، جو مکمل انحصار کا درخت دکھاتی ہے۔ سفارش کی جاتی ہے کہ resolutionStrategy بلاک کے ذریعے تصادم کرنے والی لائبریری کے ورژن کو زبردستی متعین کریں۔ ایک اور عام منظرنامہ انکریمنٹل پروسیسنگ کی کمی کی وجہ سے سست بلڈ ہے۔ یقینی بنائیں کہ تمام پلگ انز اپ ڈیٹ ہیں، Gradle Daemon فعال ہے (org.gradle.daemon=true) اور gradle.properties میں کافی میموری سیٹ ہے: org.gradle.jvmargs=-Xmx4096m۔
کیشنگ کے مسائل انحصار کو اپ ڈیٹ کرنے کے بعد پیدا ہوتے ہیں: Gradle پرانی کیش استعمال کر سکتا ہے اور بلڈ ناکام ہو جاتا ہے۔ حل — --refresh-dependencies فلیگ کے ساتھ بلڈ چلانا یا ./gradlew cleanBuildCache کے ذریعے دستی طور پر کیش صاف کرنا۔ تیسری سب سے عام غلطی Android Gradle Plugin (AGP) اور Gradle کے درمیان ورژن کی عدم مطابقت ہے۔ AGP کے ہر ورژن کو Gradle کے ایک مخصوص کم از کم ورژن کی ضرورت ہوتی ہے۔ مطابقت کی میز developer.android.com پر شائع کی جاتی ہے۔ اگر ورژن غیر مطابقت رکھتے ہیں، Gradle کنفیگریشن مرحلے میں کم از کم مطلوبہ ورژن کے پیغام کے ساتھ ناکام ہو جاتا ہے۔ ہمیشہ چیک کریں کہ Gradle ریپر کا ورژن AGP کی ضروریات سے میل کھاتا ہے۔
اکثر پوچھے گئے سوالات
Gradle پروجیکٹس کی تعمیر کے لیے ایک پروگرام آٹومیٹر ہے۔ یہ Kotlin یا Java میں آپ کے سورس کوڈ کو لیتا ہے، انٹرنیٹ سے لائبریریاں جوڑتا ہے، سب کچھ بائٹ کوڈ میں کمپائل کرتا ہے اور APK میں پیک کرتا ہے۔ یہ JVM پر چلتا ہے اور دستی ہدایات کے بجائے اعلانیہ اسکرپٹ استعمال کرتا ہے۔ ڈویلپر کو صرف قواعد بیان کرنے کی ضرورت ہے، اور Gradle باقی کرتا ہے۔
Build.gradle Groovy میں لکھا جاتا ہے — ایک متحرک زبان جس میں لچکدار نحو اور کم سختی ہے۔ Build.gradle.kts Kotlin DSL استعمال کرتا ہے: مضبوط ٹائپنگ، Android Studio میں آٹوکمپلیٹ اور کمپائلیشن کے وقت غلطی کی جانچ۔ Google تمام نئے پروجیکٹس کے لیے Kotlin DSL کی سفارش کرتا ہے۔ Groovy فائلوں کو منتقل کرنا آسان ہے، لیکن Kotlin فائلیں دیکھ بھال میں زیادہ قابل اعتماد ہیں۔
Gradle Daemon (org.gradle.daemon=true) اور متوازی بلڈ (org.gradle.parallel=true) کو فعال کریں۔ org.gradle.jvmargs کے ذریعے JVM میموری کو 4–8 GB تک بڑھائیں۔ آن-ڈیمانڈ پروجیکٹ کنفیگریشن (org.gradle.configureondemand=true) استعمال کریں۔ Android پروجیکٹس کے لیے، ٹاسک کیشنگ کنفیگر کریں اور صرف مطلوبہ ABI کے لیے بلڈ کریں۔ Android Studio میں، رکاوٹیں تلاش کرنے کے لیے Build Analyzer چلائیں۔
Build variant بلڈ ٹائپ (مثلاً، debug یا release) اور پروڈکٹ فلیور (مثلاً، demo یا full) کا مجموعہ ہے۔ ہر ویریئنٹ کا اپنا پیکیج نام، ورژن، وسائل اور سورس فائلیں ہو سکتی ہیں۔ Gradle ہر ویریئنٹ کے لیے خود بخود ایک علیحدہ بلڈ ٹاسک بناتا ہے۔ یہ ایک پروجیکٹ سے ایپلی کیشن کے متعدد ورژن بنانے کی اجازت دیتا ہے۔
انحصار build.gradle.kts فائل کے dependencies بلاک میں شامل کیے جاتے ہیں۔ فارمیٹ ہے: configuration("group:artifact:version")۔ مثال کے طور پر، implementation("androidx.core:core-ktx:1.12.0")۔ ٹیسٹ کے لیے testImplementation استعمال کریں، آلاتی ٹیسٹ کے لیے — androidTestImplementation۔ ورژنز کو libs.versions.toml فائل کے ذریعے علیحدہ ورژن کیٹلاگ میں رکھنا آسان ہے۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں