Upgrading to Android 14: Our Journey at Halodoc

Android Development • Apr 5, 2024

With each release of Android, we introduce new features as well as behaviour changes aimed at making Android more helpful, more secure, and more performant. In many cases, your app will work exactly as expected out of the box, while in other cases you might need to update your app to adapt to the platform changes.

We planned this migration to leverage the new capabilities offered by Android 14 and we've shared our experience through this blog to highlight the journey and the pitfalls to watch for, during the migration journey at Halodoc.

Benefits of Android 14 migration

Enhanced Security: Android 14 comes with improved security features and protocols, providing a safer environment for both users and developers. This includes updated encryption standards, secure app sandboxing, and enhanced protection against malware and vulnerabilities.
Performance Improvements: Android 14 introduces optimizations and performance enhancements, resulting in faster app loading times, smoother animations, and better overall responsiveness. This can lead to improved user satisfaction and retention.
New APIs and Features: Migrating to Android 14 allows developers to leverage the latest APIs and features offered by the platform. This includes access to new UI components, improved notification handling, advanced camera capabilities, and more, enabling developers to create richer and more immersive experiences for users.
Compatibility and Future-Proofing: By migrating to Android 14, developers ensure compatibility with the latest devices and operating system versions, as well as future-proofing their apps against upcoming changes and updates. This helps maintain app relevance and longevity in the ever-evolving Android ecosystem.
Access to Developer Tools and Resources: Android 14 provides access to a comprehensive set of developer tools, documentation, and resources that facilitate app development, debugging, testing, and optimization. This can streamline the development process and improve developer productivity.

Overall, migrating to Android 14 offers developers numerous benefits, including enhanced security, performance improvements, access to new APIs and features, compatibility, and access to developer tools and resources, ultimately resulting in better apps and user experiences.

Ensure compatibility with Android 14

It's important to test the functionality of your existing app against Android 14 to ensure a great experience for users updating to the latest version of Android. Some platform changes can affect the way your app behaves, so it's important to test early and thoroughly and make any needed adjustments to your app.

Before you start testing, be sure to familiarize yourself with the behaviour changes for all apps. These changes might affect your app, even if you don't change its targetSdkVersion.

Migration Journey

1. Update Target API Level:

The first step in the process of migrating your app to the new target API level is to update your build.gradle parameters.

If your app already complies with the annual target API level update policy, your app is on target SDK 33 (Android 13)

To support Android 14, you just need to go to your app-level build.gradle and set the targetSdkVersion as well as the compileSdkVersion to the new target SDK version 34.

2. SCHEDULE_EXACT_ALARM is disabled by default

In Android 12 a new SCHEDULE_EXACT_ALARM permission was introduced for using the API AlarmManager, associated with the exact time of alarm going off. In Android 13 appeared the new USE_EXACT_ALARMS permission. In Android 14 no new permission was added, the behavior of SCHEDULE_EXACT_ALARM was changed. Now, it will not be an issue to applications with targetSdk 33 and higher. Permissions will be granted during device updates or backup restorations, but not for new installations. Exceptions include applications signed with a system certificate, apps with special privileges, and those where battery optimization is disabled.

3. Foreground Service type is required

In Android 10, for all Foreground services, appeared the possibility to announce the type of service that specifies the purpose of its launch. In Android 14, it becomes mandatory to specify the type for all Services that can be launched as Foreground, and in modern Android, this is almost all cases. To cover all the options of using Foreground Service they added new types of services, and each of them has a special permission.

This new feature will make it clear whether operations performed in the Service fall under the permitted categories. The system will be able to have a better understanding of what the application does and whether it is something suspicious. Google strongly recommends using WorkManager and other special APIs and, in case they don’t suit you, implementing ForegroundService.

Google Play will also check the Foreground Service during the build uploading phase. Any application with Android 14 support (targetSdk>= 34) must confirm that the Service with the announced task type is needed to run the application. Otherwise, you won’t be allowed to publish in the store.

To launch the Foreground Service in addition to adding the permission to launch the Foreground Service you will also need to add the permission to launch a specific type of service. All these permissions are of the normal type, i.e., the permissions are issued automatically when you install the application, and you don’t have to request them separately.

4. Limitations on Implicit Intent

Android 14 continues to push best practices to prevent malware from exploiting internal application components. Now Implicit Intents will only be delivered to exported application components; for not exported ones, Explicit Intents should be used.

The second change to the Intent mechanism is that any mutable PendingIntent that uses Implicit Intent will now result in an exception being thrown.

Implicit intent - When we want to call the system components through intent to perform a particular task and we don't really know the name of the components to be used, the android system will show the desired list of applications to perform the task.

Explicit intent - When we want to call the another activity with the full qualified name of the activity and of course we know the name of the activity.

5. BroadcastReceiver changes

In addition, the behavior for Intent that is delivered to context-registered (registered in code) BroadcastReceiver is changed for all applications, regardless of targetSdk. All Intents they may receive will NOT be delivered when the application is in a cached state, i.e., minimized and the user hasn’t used it for some time. Intent delivery will happen when the application becomes active again. In addition, when sending multiple identical Intentents, only one of them can be delivered. The BroadcastReceivers registered in AndroidManifest will continue to work as before.

Also BroadcastReceiver registration from the code has become stricter. Now it is necessary to specify whether or not they are exported by analogy, as is done for all components in the AndroidManifest. When registering you will need to specify the RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED flag. The change only works for applications with support for Android 14.

To receive all system broadcasts, including broadcasts from highly privileged apps, flag your receiver with RECEIVER_EXPORTED.

If you flag your receiver with RECEIVER_NOT_EXPORTED, the receiver is able to receive some system broadcasts and broadcasts from your app, but not broadcasts from the highly privileged apps.

6. JobScheduler updates

JobScheduler got the ability to launch long tasks for data transfers between the device and the server. This type of task is called a user-initiated data transfer job. This type of Job can only be launched when the application is visible to the user or when the application can launch an Activity from the background.

To launch a user-initiated data transfer job, you must specify the RUN_USER_INITIATED_JOBS permission in AndroidManifest and add a Service that extends the JobService class. When creating JobInfo you need to call setUserInitiated() method with true as an argument. A pre-requirement for launching JobInfo is to display a system notification. You should do it when calling onStartJob().

7. Partial access to photos and videos

Similar to iOS, Android 14 provides partial access to photos and videos. Now, when you request media, the user will see a dialog that asks to select either to provide access to all media or to provide access only to individual photos/videos. This new feature will work for all applications, regardless of their target Sdk OS.

Android 13 already introduced separate permissions for photo access and video access. Now there will be another additional permission READ_MEDIA_VISUAL_USER_SELECTED that allows you to repeatedly re-request a selection for individual photos/videos. The new permission should be used in addition to the existing READ_MEDIA_IMAGES and READ_MEDIA_VIDEO to support the new behavior. Declaring it means that your application supports this reselection.

Access to individual media will be granted temporarily, but the documentation doesn’t describe for how long. If the new permission isn’t declared, the partial access will be revoked immediately when the application goes into the background or the user kills the application. Something similar to how a temporary one-time permission works. Therefore, you cannot store the states of obtaining READ_MEDIA_VISUAL_USER_SELECTED permission, and you need to check them every time.

Conclusion

In this article, we've shared our key experiences and lessons learned from the migration process of Halodoc apps to Android 14.

We as Android developers once again have to react to the changes and adapt our apps according to the new limitations and functions to ensure the best possible user experience across all Android versions.

There are some good new features like the Partial access to photos, the Screenshot detection and Data Safety from Google Play on Android system.

If you want to have a look at other changes that might affect your app, check out the official documentation on the behaviour changes regarding Android 14.

References

Join us

Scalability, reliability and maintainability are the three pillars that govern what we build at Halodoc Tech. We are actively looking for engineers at all levels and if solving hard problems with challenging requirements is your forte, please reach out to us with your resumé at careers.india@halodoc.com.

About Halodoc

Halodoc is the number 1 Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke. We connect 20,000+ doctors with patients in need through our Tele-consultation service. We partner with 3500+ pharmacies in 100+ cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services, and to top it off we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application. We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, GoJek, Astra, Temasek, and many more. We recently closed our Series D round and in total have raised around USD$100+ million for our mission. Our team works tirelessly to make sure that we create the best healthcare solution personalized for all of our patient's needs, and are continuously on a path to simplify healthcare for Indonesia.

Pawan kushwaha

I am an Android developer with almost 8+ years of experience whose goal is to work in a dynamic professional environment with a solid organization and utilize my creative skills.