Android: vad det är, systemarkitektur och utveckling i Kotlin

Vad är Android?

Android är ett mobilt operativsystem baserat på Linux-kärnan, utvecklat av Google sedan 2007. Källkoden är öppen under Apache 2.0-licensen som en del av Android Open Source Project (AOSP). Varje tillverkare kan ändra systemet och installera det på sina enheter.

Enligt StatCounter (2026) innehar Android cirka 72% av den globala marknaden för mobila operativsystem. De största tillverkarna är Samsung, Xiaomi, Oppo, Vivo, Google Pixel. Fragmentering är ett nyckelproblem för plattformen: tusentals modeller med olika OS-versioner används samtidigt.

Android-arkitekturen är byggd på principen om behörigheter (permissions): varje app körs under en separat Linux-UID och har endast tillgång till sina egna data. Åtkomst till systemresurser (kamera, mikrofon, kontakter) begärs via Android Permissions under körning, från och med Android 6 (API 23).

Historik över Android-versioner

Android 1.0 släpptes 2008 på HTC Dream. Viktiga milstolpar: Android 4.0 Ice Cream Sandwich (enhetligt gränssnitt för telefoner och surfplattor), Android 5.0 Lollipop (Material Design), Android 6.0 (runtime-behörigheter), Android 10 (mörkt tema, gester), Android 12 (Material You). Sedan 2023 har Google övergått till årliga större utgåvor utan efterrättsnamn.

Android-arkitektur: fyra viktiga lager

Android-arkitekturen består av fyra huvudlager som isolerar hårdvaran från användarapplikationer. Varje lager använder tjänster från lagret under via strikt definierade gränssnitt.

Linux-kärna och HAL

Det nedersta lagret är en modifierad Linux-kärna (LTS, version 6.x i Android 15). Den hanterar minne, processer, nätverksstack och drivrutiner. Hardware Abstraction Layer (HAL) tillhandahåller ett enhetligt API för interaktion med hårdvaran: kamera, Bluetooth, Wi-Fi, sensorer. Tillverkare implementerar HAL-moduler utan att påverka de övre lagren.

Android Runtime (ART)

ART kör applikationernas DEX-bytekod. Från och med Android 5.0 ersatte ART Dalvik och använder Ahead-of-Time (AOT)-kompilering för förbättrad prestanda. Varje app har sin egen process med en separat ART-instans. Sopsamling (GC) fungerar med minimala pauser — en typisk GC-paus är 2–4 ms.

Application Framework

Ramverket är det lager som utvecklaren arbetar direkt med. Det inkluderar Activity Manager (skärmstack), Content Providers (dataåtkomst), Resource Manager (lokalisering, resurser), Notification Manager, Location Manager. Alla systemtjänster anropas via Binder IPC — Androids mekanism för interprocesskommunikation.

// Exempel på arbete med Binder via AIDL-gränssnitt
interface IDataService : android.os.IInterface {
    fun getData(): List<DataItem>
    fun saveData(item: DataItem): Boolean
}

// Serviceimplementering
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
}

Systemappar

Det översta lagret består av vanliga systemapplikationer: Telefon, Kontakter, Kamera, Inställningar, Webbläsare. De har inte högre privilegier än användarappar, men kan ersättas av tredjepartsappar. I Android 15 uppdateras systemappar via Google Play System Updates oberoende av tillverkarens OTA-uppdateringar.

Kotlin — det primära Android-utvecklingsspråket

Kotlin är ett statiskt typat programmeringsspråk från JetBrains som körs på JVM. Google tillkännagav Kotlin som officiellt Android-språk 2017 på Google I/O. Kotlin är fullt kompatibelt med Java men eliminerar dess brister: null-säkerhet, dataklasser, tilläggsfunktioner och koroutiner.

Null-säkerhet och typer

Huvudfunktionen i Kotlin är inbyggt skydd mot NullPointerException. Typer är uppdelade i nullable (String?) och non-null (String). Kompilatorn kontrollerar nullable-åtkomst vid byggtid. Safe call (?.) och Elvis-operatorn (?:) förenklar arbete med valfria värden utan nästlade kontroller.

// Exempel på Kotlin-kod med koroutiner och Flow
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)
    }
}

Exemplet visar koroutiner (suspend-funktion) för asynkron nätverks- och databasåtkomst, Flow för reaktiv observation av dataförändringar och Result för säker felhantering. Koroutiner ersätter callbacks och RxJava utan trådoverhead.

Kotlin-koroutiner och Flow

Kotlin-koroutiner är lätta trådar som körs på en delad trådpool. Dispatchers.IO för nätverk och disk, Dispatchers.Main för UI, Dispatchers.Default för CPU-intensiva uppgifter. viewModelScope och lifecycleScope avbryter automatiskt koroutiner när komponenten förstörs.

// ViewModel med koroutiner och StateFlow
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 och utvecklingsverktyg

Android Studio är den officiella IDE baserad på IntelliJ IDEA, utvecklad av Google. Den inkluderar kodredigerare, Layout Inspector, enhetsemulator, APK Analyzer, Profiler (CPU, Minne, Nätverk, Energi) och Firebase-integration. Android Studio 2024 (Ladybug) stöder Kotlin 2.0 med plattformsoberoende KMP-läge.

Android-emulator

Android-emulatorn använder KVM (Linux) eller Hyper-V (Windows) för hårdvaruacceleration. Den stöder simulering av GPS, sensorer, kamera, samtal och SMS. Google Pixel 9 Pro är den rekommenderade konfigurationen för testning med API 35 och 8 GB emulator-RAM.

Android Profiler och felsökning

Profiler visar i realtid CPU-belastning, minnesallokering, nätverksförfrågningar och energiförbrukning. Memory Profiler möjliggör heap-dumpning och läckageanalys via referensträdet. Network Inspector registrerar alla HTTP/HTTPS-förfrågningar med brödtext och rubriker. För djupgående analys används Android Studio Canary.

Android-appkomponenter

En Android-app består av fyra typer av komponenter, var och en med sin egen ingångspunkt och livscykel. Komponenterna registreras i filen AndroidManifest.xml.

Activity och Intent

Activity är den grundläggande komponenten i användargränssnittet. Varje skärm är en separat Activity eller ett Fragment i en Activity. Navigering mellan skärmar sker via Intent — ett objekt som innehåller en åtgärd (ACTION_VIEW, ACTION_SEND) och data (URI). I Jetpack Navigation Graph beskrivs navigering i XML.

Service och WorkManager

Service utför bakgrundsuppgifter, men från och med Android 8 är bakgrundstjänster begränsade. WorkManager är det rekommenderade biblioteket för fördröjda och garanterade bakgrundsuppgifter med stöd för kedjor, begränsningar (t.ex. endast vid laddning) och omstart efter krasch.

Jetpack Compose vs XML Layouts

Valet mellan Jetpack Compose och traditionella XML-layouter är det viktigaste arkitekturbeslutet när man startar ett Android-projekt. XML-layouter (RecyclerView, ConstraintLayout, FrameLayout) har varit standard sedan 2008. Jetpack Compose introducerades 2021 som ett deklarativt alternativ.

Google rekommenderar Jetpack Compose för alla nya projekt. XML-layouter förblir relevanta för stöd av äldre projekt och för fall där maximal View-anpassning (Canvas, SurfaceView) behövs. Compose-kod är i genomsnitt 40% kortare än motsvarande XML + ViewBinding.

// Jetpack Compose — användarprofils skärm
@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 = "Användaravatar",
            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("Redigera profil")
        }
    }
}

@Preview(showBackground = true, showSystemUi = true)
@Composable
fun ProfileScreenPreview() {
    MaterialTheme {
        ProfileScreen(
            user = User(1, "Anna Petrova", "anna@example.com"),
            onEditClick = {}
        )
    }
}

Funktionen ProfileScreen deklareras som @Composable — den beskriver UI deklarativt utan att skapa View-instanser. Compose uppdaterar automatiskt skärmen när user ändras. @Preview visar resultatet direkt i IDE utan att bygga och köra på emulatorn.

Livscykel för Activity och Fragment

Varje Activity i Android går igenom sex livscykeltillstånd: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment lägger till onAttach, onCreateView, onViewCreated. Att förstå livscykeln är avgörande för minneshantering och förebyggande av läckor.

Huvudsakliga tillstånd för Activity

onCreate — anropas en gång när Activity skapas. Här utförs initiering: setContentView, adapterinställning, LiveData-prenumeration. onResume — Activity är i förgrunden och interagerar med användaren. onPause — Activity förlorar fokus (dialogruta, annan Activity). onStop — Activity är inte synlig. onDestroy — Activity förstörs.

// Activity med livscykelhantering via LifecycleScope
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", "")
    }
}

Användning av repeatOnLifecycle säkerställer att datainsamling pausas när Activity går i bakgrunden och återupptas när den återgår till förgrunden. Detta förhindrar läckor och onödiga nätverksförfrågningar. onSaveInstanceState sparar temporärt tillstånd vid skärmrotation.

Google Play: publicering och krav

Google Play är den officiella Android-appbutiken. Utvecklarkontoregistrering kostar 25 USD en gång. Varje app genomgår en automatisk Google Play Integrity-kontroll för skadlig kod, policyöverträdelser och felaktig användning av behörigheter.

Publiceringskrav

Google kräver app-signering via Android App Bundle (AAB) eller APK. AAB är det rekommenderade formatet, som möjliggör generering av optimerade APK:er för varje enhetskonfiguration. Appen måste signeras med en nyckel (keystore) med ett giltigt certifikat. Google Play App Signing är valfri nyckelkryptering på Googles sida.

Sekretesspolicy

Alla appar som begär åtkomst till personuppgifter måste tillhandahålla en Sekretesspolicy. Från och med 2024 kräver Google en Data Safety-deklaration — ett formulär som anger vilka typer av data som samlas in och ändamålen med behandlingen. Appar som riktar sig till Android 14+ måste använda Declarations API för att deklarera behörigheter.