Context, Application & Manifest Quiz

ANDROID › System

You need to cache an object in a process-wide singleton that lives for the whole app. Which Context should it hold?

• The current Activity's context, refreshed on every onResume
• The application context from getApplicationContext()
• A new Context created with createConfigurationContext()
• Any Activity context wrapped in a static field

Answer: The application context from getApplicationContext()

The application context is scoped to the process, so a long-lived singleton can safely hold it without preventing any Activity from being garbage collected.

What is the direct consequence of a static field holding an Activity reference across a configuration change?

• The Activity is recreated twice during the configuration change
• The old Activity leaks because the static ref keeps it alive
• The app crashes right away with a BadTokenException exception
• The configuration change is ignored and the same Activity stays

Answer: The old Activity leaks because the static ref keeps it alive

On rotation the Activity is destroyed and recreated, but the static reference keeps the old instance (and its view tree) alive, leaking memory.

Why is it wrong to inflate a themed Material layout or show a Dialog using the application context?

• The application context lacks the right theme and window token
• The application context has no access to resources or string values
• Inflation requires a Service context, not an Application one
• The application context is null until the first Activity starts

Answer: The application context lacks the right theme and window token

Only an Activity context carries the activity theme and window token needed for correct styling and to attach a Dialog; the application context will mis-theme views or throw a BadTokenException.

What is the primary performance benefit of the AndroidX App Startup library?

• It moves all Application.onCreate work onto a background worker thread automatically
• It precompiles all the initializers with R8 during the build step
• It replaces many per-library ContentProviders with one InitializationProvider
• It lazily loads every Activity so the launcher appears to open faster

Answer: It replaces many per-library ContentProviders with one InitializationProvider

Each library-provided ContentProvider is costly to instantiate at launch; App Startup consolidates them into one InitializationProvider and orders initialization via dependencies.

In App Startup, how does an Initializer declare that another component must be initialized before it?

• By annotating the class with @DependsOn and naming it there
• By returning that Initializer class from dependencies()
• By calling AppInitializer.requireFirst() inside create()
• By listing it in a separate startup.xml resource file

Answer: By returning that Initializer class from dependencies()

dependencies() returns a list of Initializer classes that must run first; the library resolves this graph and creates dependencies before the dependent's create() is called.

You want to keep the App Startup InitializationProvider but stop one specific initializer from running automatically at launch. What do you do?

• Delete the initializer class entirely from the whole project source tree
• Set android:exported="false" on the shared InitializationProvider element
• Add tools:node="remove" to its <meta-data>, then init manually via AppInitializer
• Set android:enabled="false" on the <application> element in the app's merged manifest file

Answer: Add tools:node="remove" to its <meta-data>, then init manually via AppInitializer

Marking the specific <meta-data> with tools:node="remove" drops it from automatic discovery while leaving the provider intact; you then call AppInitializer.initializeComponent() when needed.

Which manifest construct makes an Activity the app's launcher entry point?

• Setting android:exported="true" on the <activity> alone
• An <intent-filter> with action MAIN and category LAUNCHER
• A <meta-data> tag like android.app.launcher in the manifest
• Setting android:priority="1000" on the activity element

Answer: An <intent-filter> with action MAIN and category LAUNCHER

An intent filter declaring action android.intent.action.MAIN and category android.intent.category.LAUNCHER tells the system this Activity is the entry point shown in the launcher.

In what order does the system call a ContentProvider's onCreate() relative to your custom Application's lifecycle methods?

• It runs after Application.onCreate() has already finished.
• They're created only when a client first queries the provider.
• It runs after attachBaseContext() and before Application.onCreate().
• They initialize on a background thread alongside Application.onCreate().

Answer: It runs after attachBaseContext() and before Application.onCreate().

Installed ContentProviders are instantiated after attachBaseContext() yet before Application.onCreate(), which is exactly why libraries and AndroidX App Startup use a provider to auto-initialize before your app's own code runs.

What is the recommended, lifecycle-aware way to detect the whole app moving between foreground and background rather than a single Activity?

• Increment and decrement a counter in onResume/onPause of every Activity by hand
• Observe the Lifecycle exposed by ProcessLifecycleOwner.get()
• Poll ActivityManager.getRunningAppProcesses() on a timer
• Register a BroadcastReceiver for ACTION_SCREEN_ON and ACTION_SCREEN_OFF

Answer: Observe the Lifecycle exposed by ProcessLifecycleOwner.get()

ProcessLifecycleOwner aggregates all Activity lifecycles into one process-level Lifecycle, emitting ON_START/ON_STOP for app foreground and background without manual bookkeeping.

Your custom Application.onCreate() performs a blocking disk and network initialization synchronously. What is the most direct consequence?

• The framework automatically shifts that work onto a background thread
• The work waits until the first Activity is fully drawn before starting
• It runs on the main thread, slowing cold start and risking an ANR
• The Application is recreated each time a later Activity is launched

Answer: It runs on the main thread, slowing cold start and risking an ANR

Application.onCreate() executes on the main thread before any component, so heavy synchronous work there directly delays cold start and can trigger an ANR before the first frame is shown.

Your app requests CAMERA at runtime through the permissions API. What else is mandatory for the request to ever be granted?

• Nothing; a runtime request entirely replaces the manifest declaration
• A matching <uses-permission android:name="android.permission.CAMERA"/> in the manifest
• Explicit approval of the permission in the Google Play Console dashboard
• A <uses-feature> entry, without which the runtime permission request is just silently dropped

Answer: A matching <uses-permission android:name="android.permission.CAMERA"/> in the manifest

A runtime request only prompts the user; the permission must still be declared with <uses-permission> in the manifest or the system denies it automatically without showing a dialog.

Your app can use the camera but should still install on devices that lack one. Which manifest entry expresses this?

• <uses-feature android:name="android.hardware.camera" android:required="false"/>
• <uses-feature android:name="android.hardware.camera" android:required="true"/>
• Removing the CAMERA <uses-permission> so Google Play stops filtering it
• <uses-library android:name="android.hardware.camera" android:required="false"/>

Answer: <uses-feature android:name="android.hardware.camera" android:required="false"/>

Declaring the feature with required="false" tells Google Play not to filter the app off camera-less devices; you then check availability at runtime with PackageManager.hasSystemFeature().

Back to Context, Application & Manifest