The default conflict resolution strategy for @Insert is either ABORT or ROLLBACK (depending on the SQLite version). If there’s a constraint violation (like a duplicate primary key), the entire insert fails silently without throwing an exception that the app might be catching. In an offline scenario with potential retries, this could lead to perceived data loss. The correct approach is to specify a strategy like @Insert(onConflict = OnConflictStrategy.REPLACE) or .IGNORE based on the business logic.

WorkManager’s CoroutineWorker (or ListenableWorker) is designed to handle these scenarios. By defining a RetryPolicy (e.g., ExponentialBackoff) when building the OneTimeWorkRequest or PeriodicWorkRequest, WorkManager itself will automatically reschedule the work if Result.retry() is returned, respecting system battery life and doze mode restrictions. This is more robust and battery-efficient than manual retry logic inside doWork() and is the recommended pattern for deferred, resilient tasks.

While all options can impact performance, deep nesting of ViewGroups (especially multiple LinearLayouts which often cause multiple measure passes) is the most critical for rendering performance. It increases measurement and layout time exponentially in complex cases, directly causing jank. A single ConstraintLayout, even with many children, is optimized to flatten the hierarchy. Image size and RecyclerView layout structure are important, but their impact is often more specific (memory, inflation time) rather than the broad, systemic layout performance hit caused by excessive nesting.

The primary purpose of a UseCase (or Interactor) is to encapsulate reusable, specific business logic. It shines when an operation isn’t just fetching data, but orchestrating how data from different sources is combined, validated, or transformed according to business rules. This keeps the ViewModel focused on UI state and the repository focused on data access, making the complex logic independently testable and preventing it from bloating the ViewModel.

When using the Navigation component, handling deep links through the navGraph is the recommended practice. It centralizes deep link routing, automatically parses arguments defined in the destination, and ensures type safety (e.g., converting the String ‘id’ from the URI to an integer argument). This is more robust and less error-prone than manual URI parsing scattered across activities and avoids magic string keys for extras.

The android:filterTouchesWhenObscured view attribute is the most straightforward and targeted fix. When set to true, the view will not receive touch events if any part of its window is obscured by a non-trusted window (like an overlay app). This directly addresses the tapjacking threat for that specific screen. FLAG_SECURE is for preventing screenshots/screen recording. Custom motion event logic is complex and error-prone, and a translucent theme doesn’t solve the problem.

When an app targets API level 26 (Android 8.0) or higher and uses Context.startForegroundService(), the system imposes a strict time limit. The service must call startForeground() within approximately 5 seconds (the exact time can vary slightly) after startForegroundService() is called. Failure to do so results in an ANR (Application Not Responding) and the app crash. This is to prevent services from starting in the background without providing the required user-visible notification.

While all options can affect performance, creating a new Glide RequestManager per bindView() is a common anti-pattern that leads to excessive object allocation and can disrupt Glide’s internal caching and lifecycle management. The correct pattern is to initiate the load from within the ViewHolder (e.g., in its bind method), which is created once per view type. This allows Glide to properly associate the request with the ImageView’s lifecycle and reuse resources efficiently, eliminating the temporary Bitmap churn.

For activities in dynamic feature modules, they must be declared in the base APK’s manifest but with android:enabled=”false”. This allows the system to know about the activity’s existence (for things like intent filters) before the module is installed. The Android Gradle plugin automatically sets it to “true” when the module is installed. The tag goes in the feature module’s manifest, not the base. Not declaring it would make the activity undiscoverable.

The default conflict resolution strategy for @Insert is either ABORT or ROLLBACK (depending on the SQLite version). If there’s a constraint violation (like a duplicate primary key), the entire insert fails silently without throwing an exception that the app might be catching. In an offline scenario with potential retries, this could lead to perceived data loss. The correct approach is to specify a strategy like @Insert(onConflict = OnConflictStrategy.REPLACE) or .IGNORE based on the business logic.0