Android : qu'est-ce que c'est, architecture du système et développement en Kotlin

Qu'est-ce qu'Android ?

Android est un système d'exploitation mobile basé sur le noyau Linux, développé par Google depuis 2007. Le code source est ouvert sous licence Apache 2.0 dans le cadre du projet Android Open Source Project (AOSP). Chaque fabricant peut modifier le système et l'installer sur ses appareils.

Selon StatCounter (2026), Android détient environ 72 % du marché mondial des systèmes d'exploitation mobiles. Les plus grands fabricants sont Samsung, Xiaomi, Oppo, Vivo, Google Pixel. La fragmentation est un problème clé de la plateforme : des milliers de modèles avec différentes versions du système d'exploitation sont utilisés simultanément.

L'architecture d'Android est construite sur le principe des autorisations (permissions) : chaque application s'exécute sous un UID Linux distinct et n'a accès qu'à ses propres données. L'accès aux ressources système (appareil photo, microphone, contacts) est demandé via les autorisations Android au moment de l'exécution, à partir d'Android 6 (API 23).

Historique des versions d'Android

Android 1.0 est sorti en 2008 sur le HTC Dream. Étapes clés : Android 4.0 Ice Cream Sandwich (interface unifiée pour téléphones et tablettes), Android 5.0 Lollipop (Material Design), Android 6.0 (autorisations d'exécution), Android 10 (thème sombre, gestes), Android 12 (Material You). Depuis 2023, Google est passé à des versions majeures annuelles sans noms de desserts.

Architecture Android : quatre couches clés

L'architecture Android se compose de quatre couches principales qui isolent le matériel des applications utilisateur. Chaque couche utilise les services de la couche inférieure via des interfaces strictement définies.

Noyau Linux et HAL

La couche inférieure est un noyau Linux modifié (LTS, version 6.x dans Android 15). Il gère la mémoire, les processus, la pile réseau et les pilotes. La couche d'abstraction matérielle (HAL) fournit une API unifiée pour interagir avec le matériel : appareil photo, Bluetooth, Wi-Fi, capteurs. Les fabricants implémentent des modules HAL sans affecter les couches supérieures.

Android Runtime (ART)

ART exécute le bytecode DEX des applications. Depuis Android 5.0, ART a remplacé Dalvik et utilise la compilation Ahead-of-Time (AOT) pour améliorer les performances. Chaque application a son propre processus avec une instance ART distincte. Le ramasse-miettes (GC) fonctionne avec des pauses minimales — une pause GC typique est de 2 à 4 ms.

Application Framework

Le Framework est la couche avec laquelle le développeur travaille directement. Il comprend Activity Manager (pile d'écrans), Content Providers (accès aux données), Resource Manager (localisation, ressources), Notification Manager, Location Manager. Tous les services système sont appelés via Binder IPC — le mécanisme de communication inter-processus d'Android.

// Exemple de travail avec Binder via l'interface AIDL
interface IDataService : android.os.IInterface {
    fun getData(): List<DataItem>
    fun saveData(item: DataItem): Boolean
}

// Implémentation du service
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
}

Applications système

La couche supérieure est constituée d'applications système standard : Téléphone, Contacts, Appareil photo, Paramètres, Navigateur. Elles n'ont pas de privilèges supérieurs aux applications utilisateur, mais peuvent être remplacées par des applications tierces. Dans Android 15, les applications système sont mises à jour via Google Play System Updates indépendamment des mises à jour OTA du fabricant.

Kotlin — langage principal du développement Android

Kotlin est un langage de programmation statiquement typé de JetBrains fonctionnant sur la JVM. Google a annoncé Kotlin comme langage officiel d'Android en 2017 lors de Google I/O. Kotlin est entièrement compatible avec Java mais élimine ses défauts : sécurité null, classes de données, fonctions d'extension et coroutines.

Sécurité null et types

La principale caractéristique de Kotlin est la protection intégrée contre NullPointerException. Les types sont divisés en nullable (String?) et non-null (String). Le compilateur vérifie l'accès nullable au moment de la compilation. L'opérateur safe call (?.) et l'opérateur Elvis (?:) simplifient le travail avec les valeurs optionnelles sans vérifications imbriquées.

// Exemple de code Kotlin avec coroutines et 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)
    }
}

L'exemple montre les coroutines (fonction suspend) pour l'accès asynchrone au réseau et à la base de données, Flow pour l'observation réactive des changements de données et Result pour la gestion sécurisée des erreurs. Les coroutines remplacent les callbacks et RxJava sans surcharge de threads.

Coroutines Kotlin et Flow

Les coroutines Kotlin sont des threads légers s'exécutant sur un pool de threads partagé. Dispatchers.IO pour le réseau et le disque, Dispatchers.Main pour l'interface utilisateur, Dispatchers.Default pour les tâches intensives en CPU. viewModelScope et lifecycleScope annulent automatiquement les coroutines lorsque le composant est détruit.

// ViewModel avec coroutines et 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 et outils de développement

Android Studio est l'IDE officiel basé sur IntelliJ IDEA, développé par Google. Il comprend un éditeur de code, Layout Inspector, émulateur de périphériques, APK Analyzer, Profiler (UC, Mémoire, Réseau, Énergie) et l'intégration Firebase. Android Studio 2024 (Ladybug) prend en charge Kotlin 2.0 avec le mode multiplateforme KMP.

Émulateur Android

L'émulateur Android utilise KVM (Linux) ou Hyper-V (Windows) pour l'accélération matérielle. Il prend en charge la simulation du GPS, des capteurs, de l'appareil photo, des appels et des SMS. Google Pixel 9 Pro est la configuration recommandée pour les tests avec API 35 et 8 Go de RAM d'émulateur.

Profileur Android et débogage

Le profileur affiche en temps réel la charge CPU, l'allocation mémoire, les requêtes réseau et la consommation d'énergie. Le Memory Profiler permet les vidages de tas et l'analyse des fuites via l'arborescence des références. Network Inspector enregistre toutes les requêtes HTTP/HTTPS avec le corps et les en-têtes. Pour une analyse approfondie, Android Studio Canary est utilisé.

Composants d'une application Android

Une application Android se compose de quatre types de composants, chacun ayant son propre point d'entrée et cycle de vie. Les composants sont enregistrés dans le fichier AndroidManifest.xml.

Activity et Intent

Activity est le composant de base de l'interface utilisateur. Chaque écran est une Activity distincte ou un Fragment dans une Activity. La navigation entre les écrans se fait via Intent — un objet contenant une action (ACTION_VIEW, ACTION_SEND) et des données (URI). Dans Jetpack Navigation Graph, la navigation est décrite en XML.

Service et WorkManager

Service exécute des tâches en arrière-plan, mais depuis Android 8, les services d'arrière-plan sont restreints. WorkManager est la bibliothèque recommandée pour les tâches d'arrière-plan différées et garanties avec prise en charge des chaînes, des contraintes (par exemple, uniquement pendant la charge) et du redémarrage après crash.

Jetpack Compose vs XML Layouts

Le choix entre Jetpack Compose et les mises en page XML traditionnelles est la décision architecturale principale au démarrage d'un projet Android. Les XML Layouts (RecyclerView, ConstraintLayout, FrameLayout) sont la norme depuis 2008. Jetpack Compose a été introduit en 2021 comme alternative déclarative.

Google recommande Jetpack Compose pour tous les nouveaux projets. Les XML Layouts restent pertinents pour la prise en charge des projets hérités et pour les cas où une personnalisation maximale de View (Canvas, SurfaceView) est nécessaire. Le code Compose est en moyenne 40 % plus court que le XML + ViewBinding équivalent.

// Jetpack Compose — écran de profil utilisateur
@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 = "Avatar de l'utilisateur",
            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("Modifier le profil")
        }
    }
}

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

La fonction ProfileScreen est déclarée comme @Composable — elle décrit l'interface utilisateur de manière déclarative sans créer d'instances de View. Compose met automatiquement à jour l'écran lorsque user change. @Preview affiche le résultat directement dans l'IDE sans compilation ni exécution sur l'émulateur.

Cycle de vie d'Activity et de Fragment

Chaque Activity dans Android passe par six états du cycle de vie : onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment ajoute onAttach, onCreateView, onViewCreated. Comprendre le cycle de vie est essentiel pour la gestion de la mémoire et la prévention des fuites.

États principaux de l'Activity

onCreate — appelé une fois lors de la création de l'Activity. L'initialisation est effectuée ici : setContentView, configuration des adaptateurs, abonnement LiveData. onResume — l'Activity est au premier plan et interagit avec l'utilisateur. onPause — l'Activity perd le focus (dialogue, autre Activity). onStop — l'Activity n'est pas visible. onDestroy — l'Activity est détruite.

// Activity avec gestion du cycle de vie 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", "")
    }
}

L'utilisation de repeatOnLifecycle garantit que la collecte de données s'interrompt lorsque l'Activity passe en arrière-plan et reprend lorsqu'elle revient au premier plan. Cela évite les fuites et les requêtes réseau inutiles. onSaveInstanceState enregistre l'état temporaire lors de la rotation de l'écran.

Google Play : publication et exigences

Google Play est la boutique officielle d'applications Android. L'inscription du compte développeur coûte 25 $ US unique. Chaque application passe une vérification automatique Google Play Integrity pour détecter les codes malveillants, les violations de politiques et l'utilisation incorrecte des autorisations.

Exigences de publication

Google exige la signature de l'application via Android App Bundle (AAB) ou APK. AAB est le format recommandé, permettant de générer des APK optimisés pour chaque configuration d'appareil. L'application doit être signée avec une clé (keystore) avec un certificat valide. Google Play App Signing est un chiffrement facultatif de la clé côté Google.

Politique de confidentialité

Toutes les applications demandant l'accès à des données personnelles doivent fournir une Politique de confidentialité. Depuis 2024, Google exige une déclaration Data Safety — un formulaire spécifiant les types de données collectées et les finalités de traitement. Les applications ciblant Android 14+ doivent utiliser l'API Declarations pour déclarer les autorisations.