Android: یہ کیا ہے، نظام کا فن تعمیر اور Kotlin میں ترقی

Android کیا ہے؟

Android ایک موبائل آپریٹنگ سسٹم ہے جو Linux کرنل پر مبنی ہے، جسے Google 2007 سے تیار کر رہا ہے۔ سورس کوڈ Android Open Source Project (AOSP) کے حصے کے طور پر Apache 2.0 لائسنس کے تحت کھلا ہے۔ ہر صنعت کار سسٹم میں ترمیم کر سکتا ہے اور اسے اپنے آلات پر انسٹال کر سکتا ہے۔

StatCounter (2026) کے مطابق، Android عالمی موبائل OS مارکیٹ کا تقریباً 72% حصہ رکھتا ہے۔ سب سے بڑے صنعت کار Samsung, Xiaomi, Oppo, Vivo, Google Pixel ہیں۔ ٹکڑے ٹکڑے ہونا پلیٹ فارم کا ایک اہم مسئلہ ہے: مختلف OS ورژن والے ہزاروں ماڈل ایک ساتھ استعمال ہوتے ہیں۔

Android کا فن تعمیر اجازتوں (permissions) کے اصول پر بنایا گیا ہے: ہر ایپلی کیشن ایک علیحدہ Linux UID کے تحت چلتی ہے اور صرف اپنے ڈیٹا تک رسائی رکھتی ہے۔ سسٹم کے وسائل (کیمرہ، مائیکروفون، رابطے) تک رسائی Android 6 (API 23) سے شروع کرتے ہوئے رن ٹائم پر Android Permissions کے ذریعے درخواست کی جاتی ہے۔

Android ورژن کی تاریخ

Android 1.0 2008 میں HTC Dream پر جاری کیا گیا تھا۔ اہم سنگ میل: Android 4.0 Ice Cream Sandwich (فونز اور ٹیبلٹس کے لیے متحد UI)، Android 5.0 Lollipop (Material Design)، Android 6.0 (رن ٹائم اجازتیں)، Android 10 (ڈارک تھیم، اشارے)، Android 12 (Material You)۔ 2023 سے، Google نے ڈیزرٹ ناموں کے بغیر سالانہ بڑی ریلیزز پر سوئچ کر لیا ہے۔

Android فن تعمیر: چار کلیدی پرتیں

Android فن تعمیر چار اہم پرتوں پر مشتمل ہے جو ہارڈویئر کو صارف کی ایپلی کیشنز سے الگ کرتی ہیں۔ ہر پرت سختی سے متعین انٹرفیس کے ذریعے نیچے والی پرت کی خدمات استعمال کرتی ہے۔

Linux کرنل اور HAL

سب سے نیچے والی پرت ایک ترمیم شدہ Linux کرنل ہے (LTS، Android 15 میں ورژن 6.x)۔ یہ میموری مینجمنٹ، عمل، نیٹ ورک اسٹیک اور ڈرائیورز کو سنبھالتا ہے۔ ہارڈویئر ایبسٹرکشن لیئر (HAL) ہارڈویئر (کیمرہ، Bluetooth، Wi-Fi، سینسرز) کے ساتھ انٹرفیس کرنے کے لیے ایک متحد API فراہم کرتی ہے۔ صنعت کار اوپری پرتوں کو متاثر کیے بغیر HAL ماڈیولز نافذ کرتے ہیں۔

Android Runtime (ART)

ART ایپلی کیشنز کا DEX بائٹ کوڈ چلاتا ہے۔ Android 5.0 سے شروع کرتے ہوئے، ART نے Dalvik کی جگہ لے لی ہے اور کارکردگی بہتر بنانے کے لیے Ahead-of-Time (AOT) کمپائلیشن استعمال کرتا ہے۔ ہر ایپلی کیشن کا ایک علیحدہ ART انسٹینس کے ساتھ اپنا عمل ہوتا ہے۔ کوڑا کرکٹ جمع کرنا (GC) کم سے کم وقفوں کے ساتھ چلتا ہے — ایک عام GC وقفہ 2-4 ms ہے۔

Application Framework

Framework وہ پرت ہے جس کے ساتھ ڈویلپر براہ راست کام کرتا ہے۔ اس میں Activity Manager (اسکرین اسٹیک)، Content Providers (ڈیٹا تک رسائی)، Resource Manager (لوکلائزیشن، وسائل)، Notification Manager، Location Manager شامل ہیں۔ تمام سسٹم سروسز Binder IPC — Android کے انٹر پروسیس کمیونیکیشن میکانزم کے ذریعے کال کی جاتی ہیں۔

// AIDL انٹرفیس کے ذریعے Binder کے ساتھ کام کرنے کی مثال
interface IDataService : android.os.IInterface {
    fun getData(): List<DataItem>
    fun saveData(item: DataItem): Boolean
}

// سروس کا نفاذ
class DataService : Service() {
    private val binder = object : IDataService.Stub() {
        override fun getData(): List<DataItem> = repository.getAll()
        override fun saveData(item: DataItem): Boolean = repository.save(item)
    }

    override fun onBind(intent: Intent?): IBinder = binder
}

سسٹم ایپس

سب سے اوپر والی پرت معیاری سسٹم ایپلی کیشنز پر مشتمل ہے: فون، رابطے، کیمرہ، سیٹنگز، براؤزر۔ ان کے پاس صارف کی ایپلی کیشنز سے زیادہ مراعات نہیں ہیں، لیکن تیسرے فریق کی ایپلی کیشنز سے تبدیل کی جا سکتی ہیں۔ Android 15 میں، سسٹم ایپلی کیشنز صنعت کار کی OTA اپ ڈیٹس سے آزادانہ طور پر Google Play System Updates کے ذریعے اپ ڈیٹ ہوتی ہیں۔

Kotlin — Android ترقی کی بنیادی زبان

Kotlin JetBrains کی ایک جامد ٹائپ شدہ پروگرامنگ زبان ہے جو JVM پر چلتی ہے۔ Google نے 2017 میں Google I/O میں Kotlin کو Android کی سرکاری زبان قرار دیا۔ Kotlin Java کے ساتھ مکمل طور پر مطابقت رکھتی ہے لیکن اس کی خامیوں کو دور کرتی ہے: null حفاظت، ڈیٹا کلاسز، ایکسٹینشن فنکشنز اور coroutines۔

Null حفاظت اور اقسام

Kotlin کی اہم خصوصیت NullPointerException کے خلاف بلٹ ان تحفظ ہے۔ اقسام nullable (String?) اور non-null (String) میں تقسیم ہیں۔ کمپائلر بلڈ وقت پر nullable رسائی کی جانچ کرتا ہے۔ Safe call (?.) اور Elvis آپریٹر (?:) نیسٹڈ جانچ کے بغیر اختیاری اقدار کے ساتھ کام کو آسان بناتے ہیں۔

// Coroutines اور Flow کے ساتھ Kotlin کوڈ کی مثال
data class User(
    val id: Long,
    val name: String,
    val email: String
)

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Long): Result<User> {
        return try {
            val cached = dao.getUser(id)
            if (cached != null) {
                return Result.success(cached)
            }
            val remote = api.fetchUser(id)
            dao.insertUser(remote)
            Result.success(remote)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }

    fun observeUsers(): Flow<List<User>> {
        return dao.observeAll()
            .map { list -> list.sortedBy { it.name } }
            .flowOn(Dispatchers.Default)
    }
}

مثال غیر متزامن نیٹ ورک اور ڈیٹابیس تک رسائی کے لیے coroutines (suspend فنکشن)، ڈیٹا کی تبدیلیوں کے رد عمل کے مشاہدے کے لیے Flow اور محفوظ ایرر ہینڈلنگ کے لیے Result کو ظاہر کرتی ہے۔ Coroutines تھریڈ اوور ہیڈ کے بغیر callbacks اور RxJava کی جگہ لیتے ہیں۔

Kotlin Coroutines اور Flow

Kotlin coroutines ہلکے تھریڈز ہیں جو مشترکہ تھریڈ پول پر چلتے ہیں۔ نیٹ ورک اور ڈسک کے لیے Dispatchers.IO، UI کے لیے Dispatchers.Main، CPU انتہائی کاموں کے لیے Dispatchers.Default۔ viewModelScope اور lifecycleScope کمپوننٹ تباہ ہونے پر خود بخود coroutines کو منسوخ کر دیتے ہیں۔

// Coroutines اور StateFlow کے ساتھ ViewModel
class UserViewModel(
    private val repository: UserRepository
) : ViewModel() {

    private val _users = MutableStateFlow<List<User>>(emptyList())
    val users: StateFlow<List<User>> = _users.asStateFlow()

    private val _loading = MutableStateFlow(false)
    val loading: StateFlow<Boolean> = _loading.asStateFlow()

    init {
        viewModelScope.launch {
            repository.observeUsers().collect { userList ->
                _users.value = userList
            }
        }
    }

    fun refresh() {
        viewModelScope.launch {
            _loading.value = true
            repository.getUser(42).onSuccess { user ->
                _users.value = listOf(user)
            }
            _loading.value = false
        }
    }
}

Android Studio اور ترقیاتی اوزار

Android Studio IntelliJ IDEA پر مبنی سرکاری IDE ہے، جسے Google نے تیار کیا ہے۔ اس میں کوڈ ایڈیٹر، Layout Inspector، ڈیوائس ایمولیٹر، APK Analyzer، Profiler (CPU، میموری، نیٹ ورک، توانائی) اور Firebase انٹیگریشن شامل ہیں۔ Android Studio 2024 (Ladybug) ملٹی پلیٹ فارم KMP موڈ کے ساتھ Kotlin 2.0 کو سپورٹ کرتا ہے۔

Android ایمولیٹر

Android ایمولیٹر ہارڈویئر ایکسلریشن کے لیے KVM (Linux) یا Hyper-V (Windows) استعمال کرتا ہے۔ یہ GPS، سینسرز، کیمرہ، کالز اور SMS کے سمولیشن کو سپورٹ کرتا ہے۔ Google Pixel 9 Pro API 35 اور 8 GB ایمولیٹر RAM کے ساتھ ٹیسٹنگ کے لیے تجویز کردہ کنفیگریشن ہے۔

Android Profiler اور ڈیبگنگ

Profiler ریئل ٹائم میں CPU لوڈ، میموری مختص، نیٹ ورک کی درخواستیں اور توانائی کی کھپت ظاہر کرتا ہے۔ Memory Profiler ریفرنس ٹری کے ذریعے ہیپ ڈمپنگ اور لیک تجزیہ کی اجازت دیتا ہے۔ Network Inspector باڈی اور ہیڈر کے ساتھ تمام HTTP/HTTPS درخواستوں کو ریکارڈ کرتا ہے۔ گہرائی سے تجزیہ کے لیے Android Studio Canary استعمال کیا جاتا ہے۔

Android ایپلی کیشن کے اجزاء

ایک Android ایپلی کیشن چار قسم کے اجزاء پر مشتمل ہوتی ہے، ہر ایک کا اپنا داخلہ نقطہ اور لائف سائیکل ہوتا ہے۔ اجزاء AndroidManifest.xml فائل میں رجسٹر ہوتے ہیں۔

Activity اور Intent

Activity صارف انٹرفیس کا بنیادی جزو ہے۔ ہر اسکرین ایک علیحدہ Activity یا Activity کے اندر Fragment ہے۔ اسکرینوں کے درمیان نیویگیشن Intent کے ذریعے کی جاتی ہے — ایک آبجیکٹ جس میں ایک عمل (ACTION_VIEW, ACTION_SEND) اور ڈیٹا (URI) ہوتا ہے۔ Jetpack Navigation Graph میں، نیویگیشن XML میں بیان کی گئی ہے۔

Service اور WorkManager

Service پس منظر کے کام انجام دیتا ہے، لیکن Android 8 سے شروع کرتے ہوئے، پس منظر کی خدمات محدود ہیں۔ WorkManager زنجیروں، پابندیوں (مثلاً، صرف چارج کرتے وقت) اور کریش کے بعد دوبارہ شروع کرنے کے سپورٹ کے ساتھ موخر اور ضمانت شدہ پس منظر کے کاموں کے لیے تجویز کردہ لائبریری ہے۔

Jetpack Compose بمقابلہ XML Layouts

Jetpack Compose اور روایتی XML لے آؤٹ کے درمیان انتخاب Android پروجیکٹ شروع کرتے وقت اہم تعمیراتی فیصلہ ہے۔ XML Layouts (RecyclerView, ConstraintLayout, FrameLayout) 2008 سے معیاری ہیں۔ Jetpack Compose 2021 میں ایک اعلانیہ متبادل کے طور پر متعارف کرایا گیا تھا۔

Google تمام نئے پروجیکٹس کے لیے Jetpack Compose کی سفارش کرتا ہے۔ XML Layouts میراثی پروجیکٹس کی معاونت اور ان صورتوں کے لیے متعلقہ رہتے ہیں جہاں زیادہ سے زیادہ View حسب ضرورت (Canvas, SurfaceView) کی ضرورت ہو۔ Compose کوڈ مساوی XML + ViewBinding سے اوسطاً 40% چھوٹا ہوتا ہے۔

// Jetpack Compose — صارف پروفائل اسکرین
@Composable
fun ProfileScreen(
    user: User,
    onEditClick: () -> Unit,
    modifier: Modifier = Modifier
) {
    Column(
        modifier = modifier
            .fillMaxSize()
            .padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        AsyncImage(
            model = user.avatarUrl,
            contentDescription = "صارف کا اوتار",
            modifier = Modifier
                .size(120.dp)
                .clip(CircleShape)
        )

        Spacer(modifier = Modifier.height(16.dp))

        Text(
            text = user.name,
            style = MaterialTheme.typography.headlineMedium
        )

        Text(
            text = user.email,
            style = MaterialTheme.typography.bodyLarge,
            color = MaterialTheme.colorScheme.onSurfaceVariant
        )

        Spacer(modifier = Modifier.height(24.dp))

        Button(onClick = onEditClick) {
            Icon(Icons.Default.Edit, contentDescription = null)
            Spacer(modifier = Modifier.width(8.dp))
            Text("پروفائل میں ترمیم کریں")
        }
    }
}

@Preview(showBackground = true, showSystemUi = true)
@Composable
fun ProfileScreenPreview() {
    MaterialTheme {
        ProfileScreen(
            user = User(1, "آنا پیٹرووا", "anna@example.com"),
            onEditClick = {}
        )
    }
}

ProfileScreen فنکشن @Composable کے طور پر اعلان کیا گیا ہے — یہ View انسٹینسز بنائے بغیر UI کو اعلانیہ طور پر بیان کرتا ہے۔ Compose user تبدیل ہونے پر خود بخود اسکرین کو اپ ڈیٹ کرتا ہے۔ @Preview ایمولیٹر پر بنا کر چلائے بغیر براہ راست IDE میں نتیجہ دکھاتا ہے۔

Activity اور Fragment کا لائف سائیکل

Android میں ہر Activity لائف سائیکل کی چھ حالتوں سے گزرتی ہے: onCreate, onStart, onResume, onPause, onStop, onDestroy۔ Fragment onAttach, onCreateView, onViewCreated شامل کرتا ہے۔ لائف سائیکل کو سمجھنا میموری مینجمنٹ اور لیک کو روکنے کے لیے ضروری ہے۔

Activity کی اہم حالتیں

onCreate — Activity بننے پر ایک بار کال کیا جاتا ہے۔ یہاں ابتداء کی جاتی ہے: setContentView، ایڈاپٹر سیٹ اپ، LiveData سبسکرپشن۔ onResume — Activity پیش منظر میں ہے اور صارف کے ساتھ تعامل کر رہی ہے۔ onPause — Activity فوکس کھو دیتی ہے (ڈائیلاگ، دوسری Activity)۔ onStop — Activity نظر نہیں آتی۔ onDestroy — Activity تباہ ہو جاتی ہے۔

// LifecycleScope کے ذریعے لائف سائیکل مینجمنٹ کے ساتھ Activity
class MainActivity : ComponentActivity() {
    private val viewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MaterialTheme {
                lifecycleScope.launch {
                    repeatOnLifecycle(Lifecycle.State.STARTED) {
                        viewModel.users.collect { users ->
                            updateUi(users)
                        }
                    }
                }
            }
        }
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("last_search", searchQuery)
    }

    override fun onRestoreInstanceState(savedInstanceState: Bundle) {
        super.onRestoreInstanceState(savedInstanceState)
        searchQuery = savedInstanceState.getString("last_search", "")
    }
}

repeatOnLifecycle کا استعمال یقینی بناتا ہے کہ Activity کے پس منظر میں جانے پر ڈیٹا اکٹھا کرنا رک جاتا ہے اور پیش منظر میں واپس آنے پر دوبارہ شروع ہو جاتا ہے۔ یہ لیک اور غیر ضروری نیٹ ورک کی درخواستوں کو روکتا ہے۔ onSaveInstanceState اسکرین گھومنے پر عارضی حالت محفوظ کرتا ہے۔

Google Play: اشاعت اور تقاضے

Google Play سرکاری Android ایپ اسٹور ہے۔ ڈویلپر اکاؤنٹ رجسٹریشن کی لاگت $25 ایک بار ہے۔ ہر ایپلی کیشن نقصان دہ کوڈ، پالیسی کی خلاف ورزیوں اور غلط اجازت کے استعمال کے لیے خودکار Google Play Integrity جانچ سے گزرتی ہے۔

اشاعت کے تقاضے

Google کو Android App Bundle (AAB) یا APK کے ذریعے ایپلی کیشن پر دستخط کی ضرورت ہے۔ AAB تجویز کردہ فارمیٹ ہے، جو ہر ڈیوائس کنفیگریشن کے لیے بہتر APK جنریشن کو قابل بناتا ہے۔ ایپلی کیشن پر ایک درست سرٹیفکیٹ کے ساتھ کلید (keystore) سے دستخط ہونا چاہیے۔ Google Play App Signing Google کی طرف سے اختیاری کلید انکرپشن ہے۔

رازداری کی پالیسی

ذاتی ڈیٹا تک رسائی کی درخواست کرنے والی تمام ایپلی کیشنز کو رازداری کی پالیسی فراہم کرنی ہوگی۔ 2024 سے، Google کو ڈیٹا سیفٹی اعلامیہ کی ضرورت ہے — ایک فارم جو جمع کردہ ڈیٹا کی اقسام اور پروسیسنگ کے مقاصد کی وضاحت کرتا ہے۔ Android 14+ کو ہدف بنانے والی ایپلی کیشنز کو اجازتوں کے اعلان کے لیے Declarations API استعمال کرنا چاہیے۔