Android Development (Kotlin and Java) Questions

Approach (brief)
Use a LinkedHashMap access-order as LRU, track total bytes with AtomicLong, and guard mutations with a ReentrantLock for thread-safety. On put, insert or replace entry, update size, then evict least-recently-used entries until under capacity. For get, return value and update access-order via map.get (LinkedHashMap does it automatically when accessOrder=true).

Kotlin implementation

import android.graphics.Bitmap
import java.util.LinkedHashMap
import java.util.concurrent.atomic.AtomicLong
import java.util.concurrent.locks.ReentrantLock
import kotlin.concurrent.withLock

class LruBitmapCache(private val maxBytes: Long) {
  private val lock = ReentrantLock()
  private val currentSize = AtomicLong(0)
  private val map = object : LinkedHashMap<String, Bitmap>(16, 0.75f, true) {
    override fun removeEldestEntry(eldest: MutableMap.MutableEntry<String, Bitmap>?): Boolean {
      // eviction handled explicitly; keep default false
      return false
    }
  }

  fun get(key: String): Bitmap? {
    lock.withLock {
      return map[key] // access-order moves it to most-recent
    }
  }

  fun put(key: String, bitmap: Bitmap) {
    val size = bitmapByteSize(bitmap)
    lock.withLock {
      val previous = map.put(key, bitmap)
      if (previous != null) {
        currentSize.addAndGet(-bitmapByteSize(previous))
      }
      currentSize.addAndGet(size)
      evictIfNeeded()
    }
  }

  private fun evictIfNeeded() {
    while (currentSize.get() > maxBytes && map.isNotEmpty()) {
      val it = map.entries.iterator()
      val eldest = it.next()
      val removedBitmap = eldest.value
      val removedSize = bitmapByteSize(removedBitmap)
      it.remove()
      currentSize.addAndGet(-removedSize)
      // optionally recycle bitmap if app manages bitmaps lifecycle:
      // removedBitmap.recycle()
    }
  }

  private fun bitmapByteSize(b: Bitmap): Long {
    return try {
      // API 19+: allocationByteCount is more accurate
      if (android.os.Build.VERSION.SDK_INT >= 19) b.allocationByteCount.toLong()
      else b.byteCount.toLong()
    } catch (e: Exception) {
      (b.width * b.rowBytes).toLong()
    }
  }

  fun clear() {
    lock.withLock {
      map.clear()
      currentSize.set(0)
    }
  }
}

Key concepts & reasoning

• LinkedHashMap(accessOrder=true) provides LRU semantics cheaply.
• ReentrantLock ensures safe concurrent get/put/evict without coarse synchronized blocks.
• AtomicLong used for accurate size tracking across threads.
• Use allocationByteCount when available; fallback to byteCount or computed rowBytes to measure bytes for eviction precisely.

Complexity

• get: O(1) amortized. put: O(1) amortized plus O(k) for evicting k entries.

Edge cases & notes

• Ensure keys are unique and consistent (e.g., URL+transform).
• Consider bitmap.recycle() when removing if lifecycle requires.
• For high contention, consider ReadWriteLock or segmenting cache.

Brief approach
Show how to send extras (String + Parcelable) via Intent, read them in the receiving Activity in a null-safe way, and note the modern Activity Result API for returning results.

Sending Activity (MainActivity)

// create intent and start SecondActivity
val intent = Intent(this, SecondActivity::class.java).apply {
    putExtra(SecondActivity.EXTRA_MESSAGE, "Hello from Main")
    putExtra(SecondActivity.EXTRA_USER, User("alice", 30)) // User implements Parcelable
}
startActivity(intent)

// Preferred for returning results:
// val launcher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> ... }
// launcher.launch(intent)

Receiving Activity (SecondActivity)

class SecondActivity : AppCompatActivity() {
    companion object {
        const val EXTRA_MESSAGE = "extra_message"
        const val EXTRA_USER = "extra_user"
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Null-safe retrieval
        val message: String? = intent.getStringExtra(EXTRA_MESSAGE)
        // Use safe-call or default:
        val safeMessage = message ?: "Default message"

        // Parcelable retrieval (null-safe). For API 33+, prefer passing Class<T> parameter.
        val user: User? = intent.getParcelableExtra(EXTRA_USER)
        // If you need non-null:
        user?.let {
            // use it
        } ?: run {
            // handle missing user
        }
    }
}

Parcelable example

@Parcelize
data class User(val name: String, val age: Int) : Parcelable

Null-safety & best practices

• Always treat extras as nullable and provide defaults or graceful handling.
• Use companion object constants for keys to avoid typos.
• For Android 13+ (API 33) prefer the overload:

intent.getParcelableExtra( key, User::class.java )

which returns a nullable User safely.

Returning results

• Prefer the Activity Result API (registerForActivityResult with ActivityResultContracts) over startActivityForResult for clearer lifecycle-safe code and typed contracts.

Approach (brief)
Use a Flow adaptor from EditText (callbackFlow), apply debounce(300), distinctUntilChanged, then use mapLatest (or flatMapLatest) so any in-flight network call is cancelled when a new query arrives. Collect on Main to update UI.

Code

// Extension: Emit text changes as Flow<String>
fun EditText.textChangesAsFlow() = callbackFlow {
    val watcher = object : TextWatcher {
        override fun afterTextChanged(s: Editable?) { trySend(s?.toString().orEmpty()) }
        override fun beforeTextChanged(a: CharSequence?, b: Int, c: Int, d: Int) {}
        override fun onTextChanged(a: CharSequence?, b: Int, c: Int, d: Int) {}
    }
    addTextChangedListener(watcher)
    // send current text immediately
    trySend(text?.toString().orEmpty())
    awaitClose { removeTextChangedListener(watcher) }
}

suspend fun searchApi(query: String): List<ResultItem> {
    // suspend network call (Retrofit with suspend fun recommended)
    return api.search(query)
}

// Wiring in an Activity/Fragment (Lifecycle aware)
fun setupSearch(editText: EditText, updateUi: (List<ResultItem>) -> Unit, lifecycleScope: CoroutineScope) {
    lifecycleScope.launch {
        editText.textChangesAsFlow()
            .map { it.trim() }
            .debounce(300)
            .filter { it.isNotEmpty() }
            .distinctUntilChanged()
            .mapLatest { query ->
                // mapLatest cancels previous search when new query arrives
                try {
                    searchApi(query)
                } catch (e: CancellationException) { throw e }
                  catch (e: Exception) { emptyList<ResultItem>() }
            }
            .flowOn(Dispatchers.IO) // network on IO
            .collect { results ->
                withContext(Dispatchers.Main) { updateUi(results) }
            }
    }
}

Notes

• mapLatest cancels in-flight calls; flowOn(Dispatchers.IO) moves upstream work to IO.
• Use Retrofit suspend functions for cooperative cancellation.
• Handle empty queries, errors, and lifecycle via lifecycleScope to avoid leaks.

High-level overview
Android apps run in a Linux process with a managed Java/Kotlin heap (ART or legacy Dalvik) plus native memory (C/C++ libs, bitmaps, NDK). The runtime’s garbage collector (ART GC) reclaims objects on the managed heap; it does not automatically free native allocations.

Role of ART / Dalvik GC

• Scans managed heap, identifies unreachable objects, and reclaims them.
• Triggers pause/compaction depending on GC mode; frequent allocations or large live set increase GC pressure and pauses.

Heap vs native memory

• Managed heap: Java/Kotlin objects handled by GC.
• Native memory: native allocations (Bitmaps pre-Oreo sometimes, NDK, system buffers) not tracked by GC — if native grows you can still hit OOM.

What causes OutOfMemoryError

• Excessive allocations on managed heap (e.g., large collections), or native memory exhaustion.
• Memory churn causing GC to fail to free enough space.
• Large Bitmaps or multiple high-res images.

Common memory-leak sources & mitigations

• Bitmaps: keep sizes down, use inBitmap/LruCache, decode with inSampleSize, recycle when appropriate.
• Static references: static Activities/Views hold entire context — avoid storing Context in statics; use ApplicationContext when appropriate.
• Long-lived callbacks/listeners/handlers: background threads, anonymous inner classes, or Handler posts holding Activity references; unregister listeners, use WeakReference, remove callbacks in onDestroy.
• Other: WebView leaks, Cursor/stream not closed.

Tools & best practices

• Use Android Studio Memory Profiler and LeakCanary to detect leaks.
• Prefer lifecycle-aware components, avoid retaining heavy objects in Activity scope, and profile under realistic device limits.

Clarify goal
Design a secure OAuth2 auth flow for Android using Authorization Code + PKCE, safe token storage, refresh/rotation, revocation, and deep-link/CCT handling.

Why Authorization Code Flow with PKCE

• PKCE prevents code interception on public clients (no client secret).
• Mobile apps are public clients; PKCE ensures exchanged code is bound to the verifier generated by the app.

High-level flow

1. App generates cryptographically random code_verifier and code_challenge (S256).
2. Open authorization endpoint in Chrome Custom Tab (or system browser) with code_challenge and app redirect URI.
3. User authenticates; IdP redirects to app redirect (custom scheme or App Link).
4. App exchanges code + code_verifier for access_token ± refresh_token at token endpoint.

Token storage / avoid storing refresh tokens

• Prefer not storing long-lived refresh tokens on device. Options:
  • Backend-for-frontend (BFF): app authenticates to your backend; backend holds refresh tokens and issues short-lived app tokens. Best for security.
  • If refresh must be on-device: use Refresh Token Rotation (IdP rotates refresh tokens and issues one-time-use tokens) + short lifetime.
• When storing tokens on Android:
  • Use Android Keystore + EncryptedSharedPreferences or use AccountManager with encrypted storage.
  • Keep access tokens short-lived (minutes); avoid plaintext storage; minimize token scope.

Token refresh & revocation

• Implement refresh token rotation: when refreshing, send refresh_token to token endpoint; replace stored token with new one; detect reuse to force re-auth.
• On refresh failure (invalid/expired) prompt reauth via PKCE flow.
• Revoke tokens on logout: call token revocation endpoint for access and refresh tokens; clear local storage and invalidate session on backend.
• Log out across devices: backend tracks refresh tokens per device and can revoke specific tokens.

Deep links & Custom Tabs

• Use AppAuth Android library or custom flow:
  • Preferred: Chrome Custom Tabs or system browser to preserve user credentials and SSO.
  • Redirect URI: use App Links (https) when possible to avoid interception; fallback to private-use URI scheme if needed.
  • Configure intent filters for redirect; validate state param before exchange to prevent CSRF.
  • Close CCT on redirect and handle redirect in a secure activity that completes exchange and clears browser state if needed.

Additional protections

• Always use HTTPS, validate issuer/jwks when parsing ID tokens, verify nonce/state, pin IdP TLS if required, limit scopes, implement device fingerprinting for suspicious refresh attempts.

This design balances usability with defense-in-depth for mobile-specific threats.