Android Development (Kotlin and Java) Questions

Approach overview

1. Detect → 2) Analyze → 3) Fix → 4) Verify. Use LeakCanary for passive detection, Android Studio Memory Profiler and heap dumps for deep analysis.

Detect (practical steps)

• Add LeakCanary dependency and run; it posts notifications with retained-paths when activities/fragments are leaked.
• Run Android Studio > View > Tool Windows > Profiler, select Memory to monitor allocations, GC, and allocation call stacks.

Analyze

• In Memory Profiler: trigger GC, take a heap dump, inspect Dominator Tree to find large retained sizes and reference chains to GC roots.
• Use heap dump exported (.hprof) and open in Android Studio or MAT to trace why object is retained.
• From LeakCanary reports, follow “leaking” path to identify the holding reference.

Common leak causes & fixes

• Static references: avoid storing Context/Views in static fields. Use Application context if truly global.
  Example:

// bad
object Cache { var ctx: Context? = null }
// good
object Cache { lateinit var appContext: Context
  fun init(c: Context) { appContext = c.applicationContext } }

• Long-lived callbacks (listeners, executors, Rx): unregister listeners in onStop/onDestroy, dispose Rx subscriptions, use weak references or lifecycle-aware components (LiveData, LifecycleObservers).
• RecyclerView adapters: avoid holding references to Views/Contexts in static fields; use adapter.viewHolder.itemView.context only when needed; null out listeners in onViewRecycled or use DiffUtil + payloads.
  Example:

override fun onViewRecycled(holder: VH) {
  holder.itemView.setOnClickListener(null)
  super.onViewRecycled(holder)
}

Verify

• Re-run LeakCanary and Memory Profiler after fixes; confirm heap dumps no longer show retained paths and retained size drops.

Best practices

• Use lifecycle-aware components, avoid anonymous inner classes capturing Activity, prefer applicationContext where appropriate, and add unit/instrumented tests to exercise navigation paths to catch leaks early.

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.

Kotlin null-safety overview

• Kotlin types are non-null by default: val s: String = "hi". To allow null: val s: String? = null.
• Compiler forces you to handle nullable types to avoid NPEs.

Common operators & patterns

• Safe-call ?. — call only if not null, returns null otherwise:

val len = user?.name?.length

• Elvis ?: — provide a default when left side is null:

val display = user?.name ?: "Anonymous"

• Non-null assertion !! — force unwrap, throws NPE if null (avoid except for quick checks):

val must = user!!.id

• Smart casts — if (s != null) { /* s treated as non-null */ }

lateinit vs lazy

• lateinit var (mutable, non-null) — for vars initialized later (e.g., view references, injected deps). Useful in Android components where lifecycle supplies value:

lateinit var binding: ActivityMainBinding
override fun onCreate(...) {
  super.onCreate(...)
  binding = ActivityMainBinding.inflate(layoutInflater)
}

• val lazy { } (immutable, thread-safe by default) — deferred initialization on first access, good for expensive computations or singletons:

private val repo by lazy { RepoImpl() }

When to use which

• Use lateinit for lifecycle-initialized, mutable properties (views, DI fields) where you guarantee init before use.
• Use lazy for read-only, possibly expensive initialization that you want only when needed.

Keep !! rare; prefer safe-call + Elvis or explicit checks to provide robust Android code.

Differences: started vs bound vs foreground Services

• Started Service
  • Launched via startService/startForegroundService.
  • Runs until it stops itself or is stopped; good for long-running background work.
• Bound Service
  • Clients bind via bindService and interact through an IBinder.
  • Lifecycle tied to clients: destroyed when no clients are bound (unless also started).
  • Good for client-server communication (e.g., activity controlling playback).
• Foreground Service
  • A started service that calls startForeground with a persistent notification.
  • Higher priority; unlikely to be killed; required for user-visible tasks (audio, location).
  • Must show notification; supports media actions.

Kotlin pseudocode: minimal foreground audio playback Service

class AudioService : Service() {
  private val CHANNEL_ID = "audio_playback"
  private val ACTION_PLAY = "ACTION_PLAY"
  private val ACTION_PAUSE = "ACTION_PAUSE"
  var isPlaying = false

  override fun onCreate() {
    createNotificationChannel()
    // init media player / audio focus / mediaSession if needed
  }

  override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
    when (intent?.action) {
      ACTION_PLAY -> { startPlayback(); updateNotification() }
      ACTION_PAUSE -> { pausePlayback(); updateNotification() }
      else -> startForegroundWithNotification() // initial start
    }
    return START_STICKY
  }

  private fun startForegroundWithNotification() {
    val notif = buildNotification(isPlaying)
    startForeground(1, notif)
  }

  private fun updateNotification() {
    val notif = buildNotification(isPlaying)
    val nm = getSystemService(NOTIFICATION_SERVICE) as NotificationManager
    nm.notify(1, notif)
  }

  private fun buildNotification(playing: Boolean): Notification {
    val playPauseAction = if (playing)
      Notification.Action( /* pause icon */ , "Pause", pendingIntent(ACTION_PAUSE))
    else
      Notification.Action( /* play icon */ , "Play", pendingIntent(ACTION_PLAY))

    return Notification.Builder(this, CHANNEL_ID)
      .setContentTitle("My Audio")
      .setSmallIcon(/*icon*/)
      .addAction(playPauseAction)
      .setOngoing(true)
      .build()
  }

  private fun pendingIntent(action: String) =
    PendingIntent.getService(this, 0, Intent(this, AudioService::class.java).setAction(action), PendingIntent.FLAG_UPDATE_CURRENT)

  private fun startPlayback() { /* start MediaPlayer */ isPlaying = true }
  private fun pausePlayback() { /* pause MediaPlayer */ isPlaying = false }

  private fun createNotificationChannel() {
    val ch = NotificationChannel(CHANNEL_ID, "Audio", NotificationManager.IMPORTANCE_LOW)
    (getSystemService(NOTIFICATION_SERVICE) as NotificationManager).createNotificationChannel(ch)
  }

  override fun onBind(intent: Intent?) = null
  override fun onDestroy() { /* release player */ }
}

Notes: request audio focus, use MediaSession for lockscreen controls and better integration, and call startForeground within 5s of startForegroundService.

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.