Gradle is the backbone of Android development, powering build automation, dependency management, and project configuration. As projects scale, module dependencies in Android Gradle become essential for keeping your codebase organized, improving reusability, and reducing build times. In this guide, we’ll break down: What module dependencies are in Android Gradle Different types of dependencies (implementation, api,...
If you’ve worked on an Android project, you’ve definitely dealt with Gradle dependencies. They help bring in external libraries, connect different parts of your project, and even let you add custom files. But not all dependencies work the same way. Some are used for linking modules, others for adding external projects, and some for including specific files. Choosing the right type can make your project more organized and easier to maintain.
In this blog, we’ll break down the different types of Gradle dependencies and when to use each one.
Gradle provides three main types of dependencies:
Each type serves a different purpose, and choosing the right one ensures better project organization, maintainability, and performance.
Module dependencies are the most commonly used in Android development. They allow you to connect different modules within the same project.
Example use case:
core module that handles networking and database logic.app module depends on core to access those functionalities.In Gradle, this might look like:
implementation project(":core")Why use module dependencies?
Project dependencies come into play when you want to include another Gradle project that isn’t part of your main project by default.
Example use case:
In Gradle:
implementation project(path: ':shared-library')Why use project dependencies?
File dependencies allow you to include JAR or AAR files directly into your project.
Example use case:
.jar file you need for backward compatibility.In Gradle:
implementation files('libs/custom-library.jar')Why use file dependencies?
Best practice: Use file dependencies sparingly. If a library is available via Maven Central or Google’s repository, prefer that method — it’s easier to update and maintain.
Gradle dependencies may seem simple, but choosing the right type — module, project, or file — can have a huge impact on your Android project’s structure and maintainability.
By understanding these distinctions, you’ll write cleaner code, speed up build times, and set yourself up for long-term project success.
Q1: What’s the difference between implementation and api in Gradle?
implementation: The dependency is only available in the current module.api: The dependency is exposed to modules that depend on your module.Q2: When should I use file dependencies in Gradle?
Q3: Can I convert a file dependency into a module or project dependency later?
Q4: Do Gradle dependencies affect build speed?
When building Android apps with Jetpack Compose, state management is one of the most important pieces to get right. If you don’t handle state properly, your UI can become messy, tightly coupled, and hard to scale. That’s where State Hoisting in Jetpack Compose comes in.
In this post, we’ll break down what state hoisting is, why it matters, and how you can apply best practices to make your Compose apps scalable, maintainable, and easy to debug.
In simple terms, state hoisting is the process of moving state up from a child composable into its parent. Instead of a UI component directly owning and mutating its state, the parent holds the state and passes it down, while the child only receives data and exposes events.
This separation ensures:
Let’s say you have a simple text field. Without state hoisting, the child manages its own state like this:
@Composable
fun SimpleTextField() {
var text by remember { mutableStateOf("") }
TextField(
value = text,
onValueChange = { text = it }
)
}This works fine for small apps, but the parent composable has no control over the value. It becomes difficult to coordinate multiple composables.
Now let’s apply state hoisting:
@Composable
fun SimpleTextField(
text: String,
onTextChange: (String) -> Unit
) {
TextField(
value = text,
onValueChange = onTextChange
)
}And in the parent:
@Composable
fun ParentComposable() {
var text by remember { mutableStateOf("") }
SimpleTextField(
text = text,
onTextChange = { text = it }
)
}Here’s what changed
text).onTextChange.This is the core idea of State Hoisting in Jetpack Compose.
As your app grows, different UI elements will need to communicate. If each composable owns its own state, you’ll end up duplicating data or creating inconsistencies.
By hoisting state:
A good rule of thumb: UI elements should be stateless and only care about how data is displayed. The parent decides what data to provide.
Example: A button shouldn’t decide what happens when it’s clicked — it should simply expose an onClick callback.
remember Wisely in ParentsState is usually managed at the parent level using remember or rememberSaveable.
remember when state only needs to survive recomposition.rememberSaveable when you want state to survive configuration changes (like screen rotations).var text by rememberSaveable { mutableStateOf("") }Compose encourages Unidirectional Data Flow (UDF):
This clear flow makes apps predictable and avoids infinite loops or messy side effects.
Don’t hoist all state to the top-level of your app. That creates unnecessary complexity. Instead, hoist it just far enough up so that all dependent composables can access it.
For example, if only one screen needs a piece of state, keep it inside that screen’s parent composable rather than in the MainActivity.
For larger apps, when multiple screens or composables need the same state, use a ViewModel.
class LoginViewModel : ViewModel() {
var username by mutableStateOf("")
private set
fun updateUsername(newValue: String) {
username = newValue
}
}Then in your composable:
@Composable
fun LoginScreen(viewModel: LoginViewModel = viewModel()) {
SimpleTextField(
text = viewModel.username,
onTextChange = { viewModel.updateUsername(it) }
)
}This pattern keeps your UI clean and separates business logic from presentation.
State Hoisting in Jetpack Compose is more than just a coding pattern — it’s the backbone of building scalable, maintainable apps. By lifting state up, following unidirectional data flow, and keeping components stateless, you set yourself up for long-term success.
To summarize:
By applying these best practices, you’ll build apps that are not only functional today but also easy to scale tomorrow.
In modern Android development, ViewModel has become an indispensable component for managing UI-related data in a lifecycle-conscious manner. One powerful application of ViewModels is sharing data between multiple fragments or activities. This guide provides a deep dive into shared ViewModels, explaining their purpose, implementation, and best practices for creating seamless data sharing in your Android apps.
A Shared ViewModel is a ViewModel instance that is accessible across multiple fragments or activities, enabling shared state management. This approach is ideal when:
Unlike standalone ViewModels scoped to a single UI component, shared ViewModels can be scoped to an entire activity or a specific navigation graph, allowing seamless state sharing while respecting lifecycle boundaries.
Here are some compelling reasons to choose shared ViewModels:
Add the core libraries you’ll need (use the latest stable versions from AndroidX/Hilt):
// app/build.gradle.kts
dependencies {
// Fragments & Activity KTX
implementation("androidx.fragment:fragment-ktx:<ver>")
implementation("androidx.activity:activity-ktx:<ver>")
// Lifecycle / ViewModel / coroutines support
implementation("androidx.lifecycle:lifecycle-viewmodel-ktx:<ver>")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:<ver>")
// Only if you still use LiveData:
implementation("androidx.lifecycle:lifecycle-livedata-ktx:<ver>")
// Jetpack Navigation (Fragment)
implementation("androidx.navigation:navigation-fragment-ktx:<ver>")
implementation("androidx.navigation:navigation-ui-ktx:<ver>")
// (Optional) Hilt for DI + ViewModels
implementation("com.google.dagger:hilt-android:<ver>")
kapt("com.google.dagger:hilt-android-compiler:<ver>")
implementation("androidx.hilt:hilt-navigation-fragment:<ver>")
kapt("androidx.hilt:hilt-compiler:<ver>")
}If using Hilt, also apply the plugin in your module’s Gradle file:
plugins {
id("com.google.dagger.hilt.android")
kotlin("kapt")
}Prefer a single source of UI state with immutable data classes and expose it via StateFlow. Keep side effects (like toasts or navigation) separate using a SharedFlow for one-off events.
// Shared ViewModel example (Kotlin)
@HiltViewModel // Remove if you’re not using Hilt
class ProfileSharedViewModel @Inject constructor(
private val repo: ProfileRepository, // Your data source
private val savedStateHandle: SavedStateHandle // For process death & args
) : ViewModel() {
data class UiState(
val user: User? = null,
val isLoading: Boolean = false,
val error: String? = null
)
private val _uiState = MutableStateFlow(UiState())
val uiState: StateFlow<UiState> = _uiState
// One-off events (navigation, snackbar, etc.)
private val _events = MutableSharedFlow<Event>()
val events: SharedFlow<Event> = _events
sealed interface Event { object Saved : Event }
fun load(userId: String) {
// Example of persisting inputs using SavedStateHandle
savedStateHandle["lastUserId"] = userId
viewModelScope.launch {
_uiState.update { it.copy(isLoading = true, error = null) }
runCatching { repo.fetchUser(userId) }
.onSuccess { user -> _uiState.update { it.copy(user = user, isLoading = false) } }
.onFailure { e -> _uiState.update { it.copy(isLoading = false, error = e.message) } }
}
}
fun updateName(newName: String) {
_uiState.update { state ->
state.copy(user = state.user?.copy(name = newName))
}
}
fun save() {
val current = _uiState.value.user ?: return
viewModelScope.launch {
runCatching { repo.saveUser(current) }
.onSuccess { _events.emit(Event.Saved) }
.onFailure { e -> _uiState.update { it.copy(error = e.message) } }
}
}
}
SavedStateHandlesurvives process death when used with Navigation and lets you read nav arguments viasavedStateHandle.get<T>("arg")or createStateFlows:savedStateHandle.getStateFlow("key", default).
Activity scope — share across all fragments in the same activity:
private val vm: ProfileSharedViewModel by activityViewModels()Activity is alive (across configuration changes).Navigation graph scope — share only within a specific flow:
private val vm: ProfileSharedViewModel by navGraphViewModels(R.id.profile_graph)NavBackStackEntry for that graph.Using Hilt? Get a Hilt-injected, nav-graph–scoped VM with:
private val vm: ProfileSharedViewModel by hiltNavGraphViewModels(R.id.profile_graph)Avoid sharing a ViewModel across different activities. Use a repository/single source of truth instead, or adopt a single-activity architecture.
Collect state with lifecycle awareness. Use repeatOnLifecycle so collection stops when the view is not visible.
@AndroidEntryPoint // if using Hilt
class EditProfileFragment : Fragment(R.layout.fragment_edit_profile) {
private val vm: ProfileSharedViewModel by activityViewModels() // or navGraphViewModels(...)
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
// State
viewLifecycleOwner.lifecycleScope.launch {
viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
vm.uiState.collect { state ->
// update text fields, progress bars, errors
}
}
}
// One-off events
viewLifecycleOwner.lifecycleScope.launch {
viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
vm.events.collect { event ->
when (event) {
is ProfileSharedViewModel.Event.Saved -> {
// e.g., findNavController().navigateUp()
}
}
}
}
}
// Example inputs
val save = view.findViewById<Button>(R.id.saveButton)
save.setOnClickListener { vm.save() }
}
}And another fragment in the same scope sees the same instance:
class PreviewProfileFragment : Fragment(R.layout.fragment_preview_profile) {
private val vm: ProfileSharedViewModel by activityViewModels()
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
viewLifecycleOwner.lifecycleScope.launch {
viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
vm.uiState.collect { state ->
// render preview using state.user
}
}
}
}
}If you prefer LiveData:
vm.liveData.observe(viewLifecycleOwner) { state -> /* ... */ }SavedStateHandleWhen you navigate with arguments, Navigation stores them in the destination’s SavedStateHandle, which the ViewModel can read:
// In the ViewModel (constructor already has savedStateHandle)
private val userId: String? = savedStateHandle["userId"]
init {
userId?.let(::load)
}You can also write to the handle to restore after process death:
savedStateHandle["draftName"] = "Amol"
val draftNameFlow = savedStateHandle.getStateFlow("draftName", "")Never mix events with state (or they re-trigger on rotation). Use SharedFlow (or Channel) for fire-and-forget actions:
private val _events = MutableSharedFlow<Event>(extraBufferCapacity = 1)
val events = _events.asSharedFlow()
// Emit: _events.tryEmit(Event.Saved)Use the coroutine test utilities and a fake repository:
@OptIn(ExperimentalCoroutinesApi::class)
class ProfileSharedViewModelTest {
@get:Rule
val mainDispatcherRule = MainDispatcherRule() // sets Dispatchers.Main to a TestDispatcher
private val repo = FakeProfileRepository()
private lateinit var vm: ProfileSharedViewModel
@Before
fun setUp() {
vm = ProfileSharedViewModel(repo, SavedStateHandle())
}
@Test
fun `load populates user and clears loading`() = runTest {
vm.load("42")
val state = vm.uiState.first { !it.isLoading }
assertEquals("42", state.user?.id)
assertNull(state.error)
}
}Implement
MainDispatcherRuleby swappingDispatchers.Mainwith aStandardTestDispatcher. Keep repositories pure and synchronous in tests, or userunTestwith fakes.
Use Activity scope when:
Use Nav-graph scope when:
StateFlow, LiveData) and keep mutables private.viewLifecycleOwner when observing in fragments (not this), to avoid leaks.SavedStateHandle.StateFlow for new code; LiveData is still fine if your app already uses it.SharedFlow/Channel for events, not StateFlow/LiveData.activityViewModels() or the same navGraphId).collect in repeatOnLifecycle(Lifecycle.State.STARTED).Navigation graph (excerpt):
<!-- res/navigation/profile_graph.xml -->
<navigation
android:id="@+id/profile_graph"
app:startDestination="@id/editProfileFragment">
<fragment
android:id="@+id/editProfileFragment"
android:name="com.example.EditProfileFragment">
<action
android:id="@+id/action_edit_to_preview"
app:destination="@id/previewProfileFragment" />
<argument
android:name="userId"
app:argType="string" />
</fragment>
<fragment
android:id="@+id/previewProfileFragment"
android:name="com.example.PreviewProfileFragment" />
</navigation>Fragments sharing the same ViewModel via nav graph:
class EditProfileFragment : Fragment(R.layout.fragment_edit_profile) {
private val vm: ProfileSharedViewModel by navGraphViewModels(R.id.profile_graph)
// collect uiState/events as shown earlier…
}
class PreviewProfileFragment : Fragment(R.layout.fragment_preview_profile) {
private val vm: ProfileSharedViewModel by navGraphViewModels(R.id.profile_graph)
// collect uiState and render preview…
}Shared ViewModels let fragments share state safely without talking to each other directly. Scope them to the activity for app-wide state or to a navigation graph for flow-scoped state. Expose state with StateFlow, drive UI with lifecycle-aware collectors, use SavedStateHandle for resilience, and keep one-off events separate. Follow these patterns and you’ll get predictable, testable, and decoupled UI flows.
State management is one of the most critical aspects of building dynamic and interactive Android applications. With Jetpack Compose, Android’s modern UI toolkit, managing state becomes more intuitive, but it also introduces new paradigms that developers need to understand. In this blog, we’ll explore state management in Jetpack Compose in detail. We’ll break down essential...
In today’s digital world, security and trust are essential, especially when it comes to sensitive information exchanged over the internet. Two foundational technologies that play a critical role in ensuring online security are digital signatures and SSL certificates. If you’re an Android user or developer, understanding these concepts is crucial for protecting your data and securing communications.
This blog will explain what a digital signature is, how SSL certificates work on Android devices, and their importance.
A digital signature is a kind of electronic fingerprint — a unique code attached to digital documents or messages that proves their authenticity and integrity. Think of it like a handwritten signature but much more secure because it’s based on cryptography.
Digital signatures use a pair of keys: a private key (known only to the signer) and a public key (shared with others). When you sign a document, your device uses your private key to create a unique signature. Others can use your public key to verify that signature’s authenticity.
Let’s look at a simplified workflow using cryptographic functions in Android’s Java/Kotlin environment to understand the digital signature process.
// Generating a digital signature in Android using Java
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.Signature;
public class DigitalSignatureExample {
public static void main(String[] args) throws Exception {
// Step 1: Generate key pair (public and private keys)
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(2048);
KeyPair pair = keyGen.generateKeyPair();
PrivateKey privateKey = pair.getPrivate();
PublicKey publicKey = pair.getPublic();
// Step 2: Sign data
String data = "This is a message to sign";
Signature signature = Signature.getInstance("SHA256withRSA");
signature.initSign(privateKey);
signature.update(data.getBytes());
byte[] digitalSignature = signature.sign();
// Step 3: Verify signature
Signature verifier = Signature.getInstance("SHA256withRSA");
verifier.initVerify(publicKey);
verifier.update(data.getBytes());
boolean isVerified = verifier.verify(digitalSignature);
System.out.println("Signature Verified: " + isVerified);
}
}Here,
An SSL (Secure Sockets Layer) certificate is a digital certificate that authenticates a website’s identity and enables an encrypted connection. When you visit a website with HTTPS, the SSL certificate is what makes the communication between your device (like an Android phone) and the website secure.
When your Android device connects to an HTTPS website, a process called the SSL/TLS handshake happens. This is a behind-the-scenes conversation between your device and the web server to establish a secure encrypted connection.
1. Client Hello: Your Android device sends a request to the server saying it wants to connect securely, including which encryption methods it supports.
2. Server Hello & Certificate: The server responds with its SSL certificate, which contains its public key and the digital signature from a CA to prove authenticity.
3. Verification: Your Android device verifies the certificate by checking:
4. Session Key Creation: Once verified, your device and the server create a shared secret key for encrypting data during the session.
5. Secure Communication: All data transferred is encrypted with this session key, keeping your information safe from eavesdroppers.
The digital signature within an SSL certificate is created by a trusted Certificate Authority (CA). This signature vouches for the authenticity of the certificate, confirming the server’s identity. Without this digital signature, an SSL certificate wouldn’t be trustworthy, and your Android device couldn’t be sure it’s communicating with the intended server.
By grasping these concepts, you empower yourself to better protect your digital life, whether you’re surfing the web or developing mobile apps.
With Android’s continuous evolution, power management has become increasingly fine-tuned. Starting from Android 9 (API level 28), Android introduced App Standby Buckets, a dynamic classification system that governs how apps can access system resources based on their usage patterns.
These buckets are essential for developers who rely on background jobs, alarms, or network access to power their app’s core functionality.
In this post, we’ll explore what these buckets are, how they limit your app’s capabilities, and how you can optimize your app to function efficiently within these boundaries.
App Standby Buckets categorize apps based on how frequently they are used. Android uses a combination of machine learning and user behavior analysis to dynamically assign apps to a bucket.
The buckets help Android prioritize system and battery resources without degrading the user experience.
Here are the five main buckets:
Each bucket determines how much access an app has to jobs, alarms, and network activity. Below is a breakdown of the execution time windows for each resource type:
Note (Android 16+): Prior to Android 16, apps in the Active bucket had no job execution limit.
Android distinguishes between two types of scheduled jobs:
JobScheduler or WorkManager.setExpedited(true) or expedited workers in WorkManager.Expedited jobs have separate quotas from regular jobs. Once those quotas are exhausted, they may still run under the regular job limits.
Best Practice: Use expedited jobs only for urgent tasks. For everything else, rely on regular job scheduling.
Starting with Android 12, alarm limits have tightened:
If your app depends on alarms, consider alternatives like
JobSchedulerorWorkManager, especially for non-critical tasks.
Apps in the Rare and Restricted buckets cannot access the network unless they are running in the foreground.
This has big implications for features like:
Make sure to test network-reliant tasks across all bucket conditions.
As of Android 13, the number of high-priority Firebase Cloud Messaging (FCM) messages an app can receive is no longer tied to the standby bucket.
This change benefits apps that rely on push messages (like messaging or ride-sharing apps), ensuring more consistent delivery.
UsageStatsManager to monitor your app’s current bucket status.adb shell am set-standby-bucket <package_name> <bucket_name>App Standby Buckets are a key piece of Android’s power management strategy. By tailoring your background behavior to each bucket’s constraints, you not only improve performance and battery life but also ensure a smoother user experience.
Understanding how these limits work — and respecting them — helps you build apps that are efficient, resilient, and Play Store compliant.
Q: Can I manually move my app to a different bucket?
A: No. The system dynamically assigns apps based on usage. You can only simulate bucket placement during testing.
Q: Do background restrictions help battery life?
A: Yes, but they can also restrict your app’s background capabilities. Design wisely.
Q: How do I test alarms or jobs under low buckets like Rare or Restricted?
A: Use ADB to simulate conditions, monitor behavior, and fine-tune fallback strategies.
Encryption is powerful, but if you don’t manage keys securely or follow best practices, your data might still be at risk. Here’s what you should know when working with encryption in Kotlin, especially for Android apps.
Think of encryption keys like the keys to your house. If someone steals your key, they can unlock everything — even if your door is super strong.
In encryption:
So, secure key management means generating, storing, and using encryption keys safely.
Android provides a secure container called the Keystore, where you can safely generate and store cryptographic keys. Keys stored here are hardware-backed and cannot be extracted, making it extremely hard for attackers to steal them.
Here’s a quick way to generate and use a key in Android Keystore:
import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import java.security.KeyStore
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey
fun generateKeyInKeystore(alias: String): SecretKey {
val keyGenerator = KeyGenerator.getInstance(
KeyProperties.KEY_ALGORITHM_AES,
"AndroidKeyStore"
)
val keyGenParameterSpec = KeyGenParameterSpec.Builder(
alias,
KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
.setBlockModes(KeyProperties.BLOCK_MODE_CBC)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_PKCS7)
.setRandomizedEncryptionRequired(true)
.build()
keyGenerator.init(keyGenParameterSpec)
return keyGenerator.generateKey()
}
fun getKeyFromKeystore(alias: String): SecretKey {
val keyStore = KeyStore.getInstance("AndroidKeyStore")
keyStore.load(null)
return keyStore.getKey(alias, null) as SecretKey
}Explanation:
generateKeyInKeystore creates a new AES key stored securely inside the Android Keystore.getKeyFromKeystore fetches the stored key when you need it for encryption or decryption.Avoid placing keys as constants in your source code. Hardcoded keys are easily extracted through reverse engineering. Always generate keys at runtime or securely fetch them from the Keystore.
IVs should be random and unique for every encryption. Never reuse IVs with the same key. The IV is usually sent alongside the encrypted data, often as a prefix, because it’s needed for decryption.
Here’s how to generate a secure IV in Kotlin:
import java.security.SecureRandom
fun generateRandomIV(): ByteArray {
val iv = ByteArray(16)
SecureRandom().nextBytes(iv)
return iv
}Encryption protects confidentiality, but attackers can still tamper with ciphertext if you don’t check data integrity. Use authenticated encryption modes like AES-GCM that combine encryption and integrity checks.
Here’s how you might switch to AES-GCM in Kotlin:
import javax.crypto.Cipher
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec
fun encryptGCM(message: String, secretKey: SecretKey, iv: ByteArray): ByteArray {
val cipher = Cipher.getInstance("AES/GCM/NoPadding")
val spec = GCMParameterSpec(128, iv) // 128-bit authentication tag
cipher.init(Cipher.ENCRYPT_MODE, secretKey, spec)
return cipher.doFinal(message.toByteArray(Charsets.UTF_8))
}AES-GCM provides both confidentiality and integrity, making your encryption more robust.
Encryption alone isn’t enough. Proper key management and following these best practices help you build secure apps that genuinely protect users’ data.
If you develop Android apps or Kotlin projects handling sensitive data, leveraging Android’s Keystore and authenticated encryption modes is a must.
If you’re getting started with Android Automotive OS (AAOS), you’ll quickly run into something called Car Service in AOSP. It’s one of those essential components that makes Android work inside a car — not on your phone, but actually on the car’s infotainment system.
In this guide, we’ll break down Car Service in AOSP step-by-step, explain how it works, what it does, and walk through code examples so you can understand and start building with confidence.
In the world of Android Open Source Project (AOSP), Car Service is a system service designed specifically for the automotive version of Android. It’s what bridges the gap between car hardware (like sensors, HVAC, speed, fuel level) and Android apps or services that need that data.
Think of it as the middleman that manages and exposes car hardware features to Android applications safely and consistently.
Let’s simplify the architecture. Here’s how the system flows:
Car Hardware Abstraction Layer (HAL)
↓
Car Service (System)
↓
Car APIs / CarApp Library
↓
Third-party or System AppsThis is the lowest layer. It connects directly to the car’s ECU and other hardware via vendor-specific code.
This lives in packages/services/Car in AOSP. It reads from the HAL and exposes data to the rest of Android using APIs.
Available via android.car namespace. Developers use these in their apps to access vehicle data in a clean, safe way.
You’ll find the Car Service source code here:
/packages/services/Car/Key files:
CarService.java – The main system service.CarPropertyService.java – Handles access to vehicle properties.VehicleHal.java – Bridges to the HAL.VehicleStubHal.java – A fake HAL used for emulators and testing.Here’s a super simplified example from CarService.java:
public class CarService extends Service {
@Override
public void onCreate() {
super.onCreate();
Log.i(TAG, "CarService started");
// Initialize vehicle property manager
mCarPropertyService = new CarPropertyService();
mCarPropertyService.init();
// Register the service to ServiceManager
ServiceManager.addService("car_service", this);
}
}Here,
CarService during boot.CarPropertyService which talks to the HAL.ServiceManager so apps can bind to it.This is what makes vehicle data accessible through Android’s Car APIs.
Accessing vehicle data isn’t open to everyone — and that’s a good thing.
You’ll need permissions like:
<uses-permission android:name="android.car.permission.CAR_SPEED"/>
<uses-permission android:name="android.car.permission.CAR_ENGINE"/>And apps must be system-signed or granted via whitelist in car_service.xml.
Here’s how a developer might access the vehicle speed:
Car car = Car.createCar(context);
CarPropertyManager propertyManager = (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);
float speed = (Float) propertyManager.getProperty(
VehiclePropertyIds.PERF_VEHICLE_SPEED, 0);Here,
Don’t have an actual car ECU to test with? Use the VehicleStubHal!
In VehicleStubHal.java, you can simulate data:
@Override
public void getProperty(...) {
if (propertyId == VehiclePropertyIds.PERF_VEHICLE_SPEED) {
return new VehiclePropValue(..., 42.0f); // Fake speed
}
}Perfect for development and debugging on emulators.
If you’re building a custom ROM for a car, you’ll likely need to:
hardware/interfaces/automotive/vehicle./packages/services/Car/.Make sure you align with VHAL (Vehicle HAL) AIDL interface definitions.
android.car APIs to safely read and respond to vehicle state.
When we talk about password security, the conversation usually goes straight to hashing algorithms — things like SHA-256, bcrypt, or Argon2.
But there are two lesser-known players that can make or break your defenses: salts and pepper.
Think of them as seasoning for your password hashes — not for flavor, but for security.
Hashing is like putting your password through a one-way blender — you can’t (easily) get the original password back.
But if attackers get your hashed password database, they can still use rainbow tables or brute-force attacks to figure out the original passwords.
That’s where salts and pepper come in.
They make every hash unique and harder to crack — even if someone has your database.
Salts
Pepper
In short:
Let’s see this in Kotlin. We’ll use the MessageDigest API for hashing (for simplicity), though in real production you should use stronger libraries like BCrypt or Argon2.
import java.security.MessageDigest
import java.security.SecureRandom
import java.util.Base64
object PasswordHasher {
// Generate a random salt for each password
fun generateSalt(length: Int = 16): String {
val random = SecureRandom()
val salt = ByteArray(length)
random.nextBytes(salt)
return Base64.getEncoder().encodeToString(salt)
}
// Your secret pepper - should be stored securely (e.g., env variable)
private const val PEPPER = "SuperSecretPepperValue123!"
// Hash with salt + pepper
fun hashPassword(password: String, salt: String): String {
val saltedPepperedPassword = password + salt + PEPPER
val digest = MessageDigest.getInstance("SHA-256")
val hashBytes = digest.digest(saltedPepperedPassword.toByteArray(Charsets.UTF_8))
return Base64.getEncoder().encodeToString(hashBytes)
}
// Verify password
fun verifyPassword(inputPassword: String, storedSalt: String, storedHash: String): Boolean {
val inputHash = hashPassword(inputPassword, storedSalt)
return inputHash == storedHash
}
}
fun main() {
val password = "MySecurePassword!"
// 1. Generate salt
val salt = PasswordHasher.generateSalt()
// 2. Hash password with salt + pepper
val hashedPassword = PasswordHasher.hashPassword(password, salt)
println("Salt: $salt")
println("Hash: $hashedPassword")
// 3. Verify
val isMatch = PasswordHasher.verifyPassword("MySecurePassword!", salt, hashedPassword)
println("Password match: $isMatch")
}Salt Generation
SecureRandom.Pepper Usage
Hashing
Verification
Attackers thrive on shortcuts. Salts remove the shortcut of using rainbow tables. Pepper blocks attackers even if they have your entire password database.
Together, they make your password security significantly harder to break.
When it comes to security, the little details — like salts and pepper — make a big difference.
Hashing without them is like locking your front door but leaving the window wide open.
So next time you store a password, make sure it’s seasoned with both.