Android: шта је то, архитектура система и развој у Kotlin

Шта је Android?

Android је мобилни оперативни систем заснован на Linux језгру, који Google развија од 2007. године. Изворни код је отворен под Apache 2.0 лиценцом у оквиру пројекта Android Open Source Project (AOSP). Сваки произвођач може да модификује систем и инсталира га на своје уређаје.

Према StatCounter-у (2026), Android заузима око 72% глобалног тржишта мобилних ОС-а. Највећи произвођачи су Samsung, Xiaomi, Oppo, Vivo, Google Pixel. Фрагментација је кључни проблем платформе: хиљаде модела са различитим верзијама ОС-а се користе истовремено.

Архитектура Android-а је изграђена на принципу дозвола (permissions): свака апликација ради под одвојеним Linux UID-ом и има приступ само својим подацима. Приступ системским ресурсима (камера, микрофон, контакти) захтева се путем Android Permissions током извршавања, почевши од Android 6 (API 23).

Историја верзија Android-а

Android 1.0 је објављен 2008. године на HTC Dream-у. Кључне прекретнице: Android 4.0 Ice Cream Sandwich (јединствени UI за телефоне и таблете), Android 5.0 Lollipop (Material Design), Android 6.0 (дозволе у runtime-у), Android 10 (тамна тема, покрети), Android 12 (Material You). Од 2023. Google је прешао на годишња велика издања без десертних назива.

Архитектура Android-а: четири кључна слоја

Архитектура Android-а се састоји од четири главна слоја који изолују хардвер од корисничких апликација. Сваки слој користи услуге слоја испод кроз строго дефинисане интерфејсе.

Linux језгро и HAL

Најнижи слој је модификовано Linux језгро (LTS, верзија 6.x у Android 15). Оно управља меморијом, процесима, мрежним стеком и драјверима. HAL (Hardware Abstraction Layer) пружа јединствени API за интеракцију са хардвером: камера, Bluetooth, Wi-Fi, сензори. Произвођачи имплементирају 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-а.

// Пример рада са Binder-ом кроз AIDL интерфејс
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, системске апликације се ажурирају путем Google Play System Updates независно од OTA ажурирања произвођача.

Kotlin — основни језик Android развоја

Kotlin је статички типизиран програмски језик компаније JetBrains који ради на JVM-у. Google је прогласио Kotlin званичним језиком Android-а 2017. на Google I/O конференцији. Kotlin је потпуно компатибилан са Java-ом, али отклања њене недостатке: null-безбедност, data класе, функције проширења и корутине.

Null безбедност и типови

Главна карактеристика Kotlin-а је уграђена заштита од NullPointerException-а. Типови су подељени на nullable (String?) и non-null (String). Компајлер проверава nullable приступ током компајлирања. Safe call (?.) и Elvis оператор (?:) поједностављују рад са опционим вредностима без угнеждених провера.

// Пример Kotlin кода са корутинама и 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)
    }
}

Пример приказује корутине (suspend функција) за асинхрони приступ мрежи и бази података, Flow за реактивно посматрање промена података и Result за безбедно руковање грешкама. Корутине замењују callback-ове и RxJava без додатног оптерећења нити.

Kotlin корутине и Flow

Kotlin корутине су лагане нити које се покрећу на заједничком pool-у нити. Dispatchers.IO за мрежу и диск, Dispatchers.Main за UI, Dispatchers.Default за CPU-интензивне задатке. viewModelScope и lifecycleScope аутоматски отказују корутине када се компонента уништи.

// ViewModel са корутинама и 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 и алати за развој

Android Studio је званични IDE заснован на IntelliJ IDEA, који је развио Google. Укључује уређивач кода, Layout Inspector, емулатор уређаја, APK Analyzer, Profiler (CPU, Меморија, Мрежа, Енергија) и интеграцију са Firebase-ом. Android Studio 2024 (Ladybug) подржава Kotlin 2.0 са вишeплатформским KMP режимом.

Android емулатор

Android емулатор користи KVM (Linux) или Hyper-V (Windows) за хардверско убрзање. Подржава симулацију GPS-а, сензора, камере, позива и SMS-а. Google Pixel 9 Pro је препоручена конфигурација за тестирање са API 35 и 8 GB RAM меморије емулатора.

Android Profiler и отклањање грешака

Profiler у реалном времену приказује оптерећење CPU-а, алокацију меморије, мрежне захтеве и потрошњу енергије. Memory Profiler омогућава дамповање heap-а и анализу цурења кроз referentno stablo. Network Inspector бележи све HTTP/HTTPS захтеве са телом и заглављима. За дубинску анализу користи се Android Studio Canary.

Компоненте Android апликације

Android апликација се састоји од четири типа компоненти, од којих свака има сопствену улазну тачку и животни циклус. Компоненте се региструју у AndroidManifest.xml датотеци.

Activity и Intent

Activity је основна компонента корисничког интерфејса. Сваки екран је посебна Activity или Fragment унутар Activity. Навигација између екрана се врши путем 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 распореди (RecyclerView, ConstraintLayout, FrameLayout) су стандард од 2008. Jetpack Compose је представљен 2021. као декларативна алтернатива.

Google препоручује Jetpack Compose за све нове пројекте. XML распореди остају релевантни за подршку старијим пројектима и за случајеве када је потребна максимална прилагођавање View-а (Canvas, SurfaceView). Compose код је у просеку 40% краћи од еквивалентног XML + ViewBinding-а.

// 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 — описује UI декларативно без креирања инстанци View-а. Compose аутоматски ажурира екран када се user промени. @Preview приказује резултат директно у IDE-у без компајлирања и покретања на емулатору.

Животни циклус Activity и Fragment

Свака Activity у Android-у пролази кроз шест стања животног циклуса: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment додаје onAttach, onCreateView, onViewCreated. Разумевање животног циклуса је кључно за управљање меморијом и спречавање цурења.

Главна стања Activity

onCreate — позива се једном приликом креирања Activity. Овде се врши иницијализација: setContentView, подешавање адаптера, претплата на LiveData. onResume — Activity је у предњем плану и интерагује са корисником. onPause — Activity губи фокус (дијалог, друга Activity). onStop — Activity није видљива. onDestroy — Activity се уништава.

// Activity са обрадом животног циклуса путем 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", "")
    }
}

Коришћење 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 захтева декларацију Data Safety — формулар са навођењем врста прикупљених података и сврхе обраде. Апликације за Android 14+ морају да користе Declarations API за декларисање дозвола.