Jetpack — o que é, componentes de arquitetura

O que é Android Jetpack?

Android Jetpack é uma coleção de bibliotecas, ferramentas e diretrizes arquiteturais do Google, apresentada em 2018 no Google I/O. O Jetpack substituiu a Support Library e o Android Architecture Components, unificando-os em um único ecossistema. Antes do Jetpack, cada biblioteca Android era atualizada independentemente, criando conflitos de versão. O Jetpack sincronizou as versões sob um único identificador AndroidX e introduziu um modelo de versões principais estáveis com patches menores.

As bibliotecas do Jetpack são divididas em quatro categorias: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Cada categoria aborda tarefas de uma camada específica do aplicativo — do gerenciamento de dados à interface do usuário.

Filosofia do Jetpack

O Google promove três princípios do Jetpack: accelerate development (menos boilerplate, mais lógica de negócios), eliminate boilerplate (ViewModel elimina a necessidade de salvar estado manualmente, Room elimina a necessidade de escrever SQLiteOpenHelper) e build with confidence (cada biblioteca passa por mais de 15.000 testes antes do lançamento). De acordo com o Android Developers (2026), aplicativos que usam Jetpack têm 30% menos falhas relacionadas ao ciclo de vida.

AndroidX como base

Todas as bibliotecas do Jetpack são distribuídas sob o identificador AndroidX (artefatos como androidx.*). O AndroidX substituiu a Support Library (artefatos como com.android.support.*), dividindo a biblioteca monolítica em artefatos modulares com versionamento independente. A migração para AndroidX é feita através da opção android.useAndroidX=true no gradle.properties — o Android Studio converte automaticamente as importações.

Componentes de arquitetura: ViewModel, Lifecycle, LiveData

ViewModel é o componente central da arquitetura Jetpack que armazena dados da UI. Ao contrário de uma Activity, que é destruída na rotação da tela, o ViewModel permanece na memória. O usuário preenche um formulário, gira o telefone — os dados não são perdidos. O ViewModel é limpo automaticamente quando o LifecycleOwner (Activity ou Fragment) finaliza permanentemente seu ciclo de vida (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Tela iniciada")
    }
}

LiveData — um contêiner de dados observável que respeita o ciclo de vida. Se a tela não estiver visível (onStop), o LiveData não envia atualizações — isso evita vazamentos de memória e falhas ao tentar atualizar uma Activity inexistente. Lifecycle — uma classe que armazena o estado atual (CREATED, STARTED, RESUMED) e permite que outros componentes se inscrevam em mudanças de estado. Juntos, ViewModel, LiveData e Lifecycle formam a base da arquitetura reativa do Android.

ViewModelScope e corrotinas

viewModelScope — um CoroutineScope integrado vinculado ao ciclo de vida do ViewModel. Todas as corrotinas lançadas neste escopo são canceladas automaticamente quando o ViewModel é limpo. Isso elimina o gerenciamento manual de Disposable e CompositeDisposable em cada ViewModel. Para trabalhar com viewModelScope, é necessária a dependência androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: trabalhando com banco de dados no Android

Room é uma biblioteca ORM do Jetpack que fornece uma camada abstrata sobre SQLite. Em vez de escrever consultas SQL brutas e converter manualmente Cursor em objetos, o desenvolvedor declara uma Entity (tabela), DAO (Data Access Object) e Database (ponto de entrada). O Room verifica consultas SQL em tempo de compilação através da anotação @Query — se tabelas ou colunas não existirem, a compilação falha com um erro claro.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

A Entity User descreve uma tabela com três colunas. O DAO declara funções suspend para trabalhar com corrotinas — a consulta é executada em uma thread de fundo automaticamente. Room suporta migrações através da anotação @Migration: o desenvolvedor descreve o script SQL de transição entre versões, e o Room o executa sem perda de dados. Na ausência de migração, o Room lança IllegalStateException — isso protege os projetos contra perda acidental de dados ao atualizar o esquema.

TypeConverters e relacionamentos

O Room armazena apenas tipos primitivos e seus wrappers. Para armazenar listas, Date ou objetos personalizados, é usado @TypeConverter — um método estático que converte um tipo em String (JSON) ou Long (timestamp). Relacionamentos entre tabelas são modelados através de objetos aninhados com a anotação @Relation e classes POJO auxiliares com @Transaction para consultas join eficientes.

Navigation Component: grafos e argumentos

Navigation Component — uma biblioteca do Jetpack para gerenciar transições entre telas. Em vez de chamar manualmente FragmentTransaction, o desenvolvedor cria um grafo de navegação (arquivo XML com nós de destino), e o sistema gera uma classe Directions com métodos de transição type-safe. O Navigation Component garante o funcionamento correto da pilha de retorno, deep links e passagem de argumentos entre telas.

// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// No código do fragmento:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

Os argumentos userId são passados no grafo de navegação com especificação de tipo (integer) e valor padrão. A classe ProfileFragmentArgs é gerada automaticamente pelo plugin Navigation Safe Args — ela contém todos os argumentos com os tipos corretos do Kotlin. Os deep links são configurados no grafo: app:deepLink="app://profile/{userId}". O Navigation Component analisa a URL e cria a pilha de retorno como se o usuário tivesse navegado pela interface.

Bottom Navigation e navegação condicional

O Navigation Component se integra com BottomNavigationView através do NavController: cada item de menu é vinculado a um destino no grafo. Alternar entre abas não recria o fragmento — o Navigation Component preserva o estado através do NavBackStackEntry. Para navegação condicional (mostrar login se não autenticado), é usado navController.navigate(condition) com verificação em onCreate.

AndroidX: a Support Library de nova geração

AndroidX é uma arquitetura reprojetada da Support Library na qual cada biblioteca recebeu seu próprio artefato com versão independente. Em vez de um único com.android.support:appcompat-v7:28.0.0, o AndroidX oferece androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 e assim por diante. Isso eliminou o problema em que diferentes dependências puxavam versões diferentes da Support Library, causando conflitos.

A migração para AndroidX é feita automaticamente no Android Studio 3.2+ através do menu Refactor → Migrate to AndroidX. O Studio substitui todas as importações em arquivos Java/Kotlin, manifestos e recursos. A compatibilidade retroativa é a principal vantagem do AndroidX: as bibliotecas funcionam no Android 5.0 (API 21) e superior, cobrindo 97% dos dispositivos ativos de acordo com o Google Play Console (2025).

Principais artefatos do AndroidX

Os artefatos mais usados: appcompat (tema escuro, Material Design em APIs antigas), recyclerview (listas adaptativas com ViewHolder), constraintlayout (contêiner flexível com hierarquia plana), cardview (cartões Material Design), preference (tela de configurações com estilo Material). Cada artefato tem versionamento independente, acelerando a entrega de correções sem atualizar todo o pacote.

Outras bibliotecas importantes do Jetpack

Além de Architecture e AndroidX, o Jetpack inclui muitas bibliotecas especializadas para tarefas típicas de desenvolvimento mobile. WorkManager — para tarefas em segundo plano com execução garantida (sincronização, upload de logs), suporta tarefas periódicas e atrasadas, bem como restrições de rede e bateria. DataStore — um substituto para SharedPreferences baseado em corrotinas, suportando propriedades tipadas (Preferences DataStore) e Protocol Buffers (Proto DataStore).

• Hilt — um framework DI baseado em Dagger que simplifica a injeção de dependências através das anotações @HiltViewModel, @Inject, @Module. Integração embutida com ViewModel e Navigation.
• Paging 3 — uma biblioteca para carregamento paginado de dados da rede/BD com suporte a RemoteMediator (rede + cache), StateFlow e Compose.
• CameraX — uma API para trabalhar com a câmera, abstraindo diferenças de fabricantes (Samsung, Xiaomi, Honor) através de uma interface unificada CameraController.
• Security Crypto — criptografia de dados via EncryptedSharedPreferences e EncryptedFile baseada em AES-256 com chave mestre no Android Keystore.

Cada biblioteca tem seu próprio SDK mínimo e artefato. O Google lança versões principais uma vez por ano (coincidindo com o lançamento do Android) e patches de segurança trimestralmente. Recomendação — inclua apenas as bibliotecas necessárias para não aumentar o tamanho do APK. A coleção completa do Jetpack (todos os artefatos) pesa mais de 20 MB, mas um aplicativo típico usa 5–7 bibliotecas, adicionando 3–5 MB ao APK.