Updating an Android application to target a newer SDK is an important part of maintaining compatibility, security, and Google Play compliance. Android 14, also known as API level 34, introduced additional requirements for foreground services and changes that affect how applications access photos and videos.
For developers maintaining older Android projects, simply changing targetSdkVersion to 34 may not be enough. The application must also declare appropriate permissions, use foreground services for valid purposes, and handle media access correctly.
This guide explains the key migration tasks, common implementation problems, and testing steps developers should complete before releasing an updated build.
1. Understand the Target SDK 34 Changes
Android’s target SDK determines which platform behaviors and compatibility requirements apply to an application. When an app targets Android 14, additional enforcement applies to several background operations.
Two areas that deserve special attention are:
- Foreground services, which perform noticeable ongoing tasks.
- Photo and video selection, which may not require broad media-library permissions when the system Photo Picker is suitable.
Review your app’s actual features before modifying the manifest. Removing permissions without understanding their purpose can break functionality, while retaining unnecessary permissions can create avoidable compliance problems.
2. Declare the Correct Foreground Service Types
Android 14 requires applications targeting API 34 or higher to specify an appropriate foreground service type for each foreground service.
For example, a music application that continues playing audio in the background may use the mediaPlayback type.
A corresponding manifest declaration can look like this:
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<uses-permission
android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission
android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />
<application>
<service
android:name=".MusicPlaybackService"
android:exported="false"
android:foregroundServiceType="mediaPlayback" />
</application>
</manifest>This is an illustrative example for a media playback service. Your application should declare only the permissions and service types required by its real functionality.
Common Foreground Service Types
Different tasks require different types and permissions.
Media playback: For ongoing audio or video playback.
Location: For eligible location-related tasks that must continue while the user is not actively interacting with the app.
Camera: For supported camera operations that continue in the foreground service context.
Data synchronization: For appropriate data transfer and synchronization tasks.
Connected device: For eligible interactions with external devices.
Microphone: For supported ongoing microphone use.
Not every application needs a foreground service. If a task can be completed with a standard background-work API, consider whether a foreground service is necessary.
3. Update Foreground Service Permissions
For Android 14-targeting apps, declaring the general FOREGROUND_SERVICE permission is not always sufficient. The service must also declare the permission associated with its type.
For example, a location service may require:
<uses-permission
android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />The application may also need location runtime permissions and must satisfy Android’s requirements for starting and using a location foreground service.
Review each service against the official Android documentation because the requirements vary by type. Some services have additional runtime prerequisites, while others have restrictions on starting from the background.
4. Start the Service With the Correct Type
When calling startForeground(), ensure that the service uses a type consistent with the manifest declaration and the operation being performed.
For example, in a Java-based service:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
startForeground(
NOTIFICATION_ID,
notification,
ServiceInfo.FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK
);
} else {
startForeground(NOTIFICATION_ID, notification);
}This example demonstrates the version-aware API call for media playback. It is not a complete service implementation. Your app must create a valid notification and meet the relevant runtime requirements.
For applications that use multiple service types, the selected type should match the active work and declared permissions. Do not label a service as media playback or location merely to avoid a system exception.
5. Use the Android Photo Picker Where Appropriate
Applications that let users select profile pictures, documents, product images, or videos often do not need unrestricted access to the entire media library.
The Android Photo Picker allows users to select specific media items without granting broad access to all photos and videos.
For supported applications, this can simplify permission handling and reduce unnecessary access to user data.
A basic Android example using the Activity Result API is:
private val pickMedia = registerForActivityResult(
ActivityResultContracts.PickVisualMedia()
) { uri ->
if (uri != null) {
// Load or process the selected media URI.
}
}
private fun openPhotoPicker() {
pickMedia.launch(
PickVisualMediaRequest(
ActivityResultContracts.PickVisualMedia.ImageAndVideo
)
)
}The example opens the picker for images and videos. Use ImageOnly or VideoOnly if your feature supports just one media type.
The URI should be processed using an appropriate content resolver or image-loading library. If your app needs to access the selected media later, review the applicable URI permission persistence rules.
6. Review Photo and Video Permissions
Legacy applications may declare permissions such as:
READ_EXTERNAL_STORAGEREAD_MEDIA_IMAGESREAD_MEDIA_VIDEOREAD_MEDIA_AUDIO
Whether these permissions are necessary depends on the app’s functionality, target SDK, and Android versions supported.
If users only need to select individual images or videos, the Photo Picker may eliminate the need for broad image or video access. However, an app that genuinely requires library-wide access may have different requirements.
Do not remove permissions blindly. Review every feature that reads media, including gallery browsing, media indexing, audio playback, uploads, and file-management functions.
7. Test the Migration Across Android Versions
After updating the manifest and application code, test the application on an Android 14 device or emulator and on older supported Android versions.
Your testing checklist should include:
- Starting and stopping each foreground service.
- Confirming the correct persistent notification appears.
- Verifying the service type and permissions.
- Testing behavior when permissions are denied.
- Starting eligible operations from the background.
- Selecting images and videos through the Photo Picker.
- Handling cancellation and invalid media URIs.
- Uploading selected media successfully.
- Checking crash reports and Logcat output.
- Verifying that existing features still work after migration.
Pay particular attention to errors such as MissingForegroundServiceTypeException, SecurityException, and failures caused by inappropriate background service starts.
8. Prepare the Release for Google Play
Before submitting the updated application, review the target SDK requirement currently applicable to your app category and release date. API level 34 is a historical migration target, so it may not satisfy Google’s latest submission requirements for every app.
Also verify that your store listing, Data safety declarations, permissions, and privacy policy accurately describe the application.
Conclusion
Migrating to target SDK 34 requires more than changing a configuration value. Developers must review foreground service declarations, type-specific permissions, runtime behavior, and media-access workflows.
Using the Photo Picker where appropriate can simplify permission handling, while correct foreground service configuration helps prevent runtime failures. A careful migration and regression-testing process can reduce crashes and improve the reliability of your Google Play release.
Official reference: Android Developers, Foreground service types are required and the Android Photo Picker documentation.