Google’s Android 12 brought about a major overhaul for users. Despite a complete redesign and a host of new features for both users and developers, it was still fairly problematic.
This was because Android 12 was riddled with endless bugs, and it took Google numerous updates to finally make it usable. All major OEMs have had bad Android updates in the past, but Android 12 trumped all that.
[Prefer listening to this rather than reading? Check out our podcast on Spotify: https://spoti.fi/3Hbch0H]
Irrespective of the OEM, almost all phones (including Google’s Pixel phones) that installed Android 12 degraded the user experience. There were even cases where the update bricked phones and made them unusable. Part of the problem was the nature of the Android update; Android 12 brought some massive changes to Android, and the visual overhaul was pretty noticeable. Bugs become inevitable when updates get in so many changes to the existing system, and Android 12 was no exception.
However, Google seems to have learned a lesson from its previous oversights in its latest offering, Android 13.
While Android 13 touches almost every aspect that an Android update should, aspects such as privacy, security, and design features remain its highlights. It features more elements from the Material YOU design that Android 12 brought to the table. Some vital privacy and security features will enhance the user experience and add to the system stability. Google has officially released several beta updates for select devices, and early reports indicate that Android 13 is mostly stable.
For a regular user, Android 13 might feel like a polished version of Android 12, as the two versions are not very different from a visual standpoint. Despite some subtle design elements throughout the UI, the latest version shines when it comes to its privacy-centric features. Contrary to what users get, the developers have a lot to explore with new additions like Bluetooth LE (Low Energy) Audio, Quick Settings placement API, and Color Vector fonts. Let’s take a deep dive into everything that Google offers to the developers with Android 13.
Privacy and Security Features in Android 13
Android 13 shines when it comes to privacy and security features. Some much-needed improvements to the underlying systems include more secure photo picking, APK signature scheme, and more.
The new features from the category include:
In previous versions of Android, apps that needed to select photos from a user’s device required permission to access the device’s storage. The storage permission allowed the app to view not just images but all the files stored on the device, creating a privacy threat for the users. Even if an app wanted to pick just one photo, the user had to grant access to all the files. Android 13 fixes this issue with its new photo picker, which launches whenever your app asks the users to select media. When the user is done selecting the photos and videos, the new photo picker shares only these chosen files with your app.
The new photo picker is a win-win for developers, too, as you don’t need to declare any runtime permissions for using it. Moreover, the UI remains consistent across all apps, which makes the OS feel refined.
Google recommends all app developers use its new photo picker to ask users for their photos and videos.
Until Android 12, apps that had to set exact alerts or calendar entries could do so just by accessing the user’s Calendar. However, many apps that didn’t require such specific details about the user’s schedule would also ask for permission and later use it to fill their data banks. Google has taken care of this problem in its latest Android offering by bringing up the new ‘Exact Alarm’ permission. It is fascinating how Google has handled the new permission; your alarm clock/timer app or a Calendar app automatically gets the permission without asking the user.
In case your app doesn’t fall under at least one of the above two criteria, you can still ask for the exact alarm permission from the user in the form of runtime permission. But, as a developer, you should also take into consideration a case where the user denies permission.
Google knows that with exact events and alarm permissions, developers can access the entire user schedule and learn about a user’s likes and dislikes. Apps can further use this data to show personalized ads or even use it for something worse. To stop the misuse of this permission, Google plans to perform regular audits on the Play Store and review apps that require this permission. The company may also go ahead to remove apps that misuse the permission.
Safer runtime receivers
Broadcast receivers are one of the critical components of an app that let it stay informed about all the latest changes in the system. However, they could also become a severe source of vulnerability if app developers are not careful with their creations. Any other app could also send an unprotected broadcast to a dynamically-registered receiver and hamper the app’s functioning. All previous versions of Android needed developers to use a signature permission to safeguard their dynamically-registered receivers from unprotected broadcasts.
Things have changed with Android 13 as it makes exporting context-registered receivers safer. App developers can now choose if a particular broadcast receiver should be visible to other apps and if they can send their broadcast to it. The broadcast receivers, from now on, will explicitly declare if they accept broadcasts from other apps. The new broadcast customizability feature is of great help if you want to protect your app without going through the hassle of signature permission.
Developers can now downgrade app permissions
As an app developer, you try to ask for as many runtime permissions from the system and the user as is essential for your app’s functioning. It is also true that users vary in how they interact with the app. The app, too, uses specific permissions more than the others, depending on the users. In some cases, there are also unused permissions.
As an app developer, it is a great trust-building exercise to let the user know that your app isn’t using the particular permission it initially sought and ask if they want to revoke it. However, previous versions of Android didn’t let developers downgrade runtime permissions on their own. The Android system did warn its users about unused app permissions, but only the user had the right to revoke app permissions.
Developers can now conduct their own internal audits about unused permissions and automatically revoke them without asking the user. However, showing the user a little prompt about the revoked permissions is always better.
Features Related to Developer Productivity
Android 13 brings some outstanding features that help developers increase the productivity of their apps. These include visually small yet highly effective elements from the users’ productive.
Here are some of the top productivity-enhancing features from the latest Android version:
All of us have encountered a situation when we copy some text to paste it somewhere else, only to find out that we copied it wrong. The only option left is to go through the entire process of switching between apps and finding the text to copy, then make sure you copy it entirely and paste it where you want.
Some of the earlier versions of Android show a ‘Copied to Clipboard’ toast message when you copy something, but that’s it. On the other hand, Android 13 offers users a preview of the copied text. Coming to the problem mentioned above, the clipboard preview is the one-stop solution to all such scenarios. Users can now see if the copied text is what they wanted and act accordingly.
Developers can now opt for themed icons
Enhancing the Material YOU features from Android 12, Android 13 brings further improvements to the same. One particular feature to note is the themed icons which automatically change the appearance of apps (the ones that support theme-based icons) from the library according to the device wallpaper. The entire UI gets an even feel when the user enables themed icons as all the icons subtly blend with the background.
For this, developers need to provide Google with two icons; an adaptive icon and a monochromatic icon. The best practice is to redirect to the monochromatic icon from the adaptive icon element in the app’s code. When the user switches the themed icons, Android uses the colors from the system wallpaper and applies them to the monochromatic icon the developers provide.
Please note the feature relies on the user switching it on in the first place. Secondly, Android 13 will not automatically convert all icons into adaptive themed icons unless the developer provides a monochrome version. Therefore, when a user turns on the feature, apps without themed icons could look out of place.
Developers can explore the quick settings tab
Android’s Quick Settings panel has primarily been a space to toggle system settings such as Wi-Fi, Bluetooth, Mobile Hotspot, and more. Even though the Quick Settings pane has been around in Android forever, it has primarily been limited to system settings. The newest additions to this list have been toggles for dark mode, microphone, and camera access. However, app developers can now use the Quick Settings tab as a productivity enhancer for their apps.
In Android 12, Google added the ability for developers to extend quick actions from their apps as toggles in Quick Settings. However, users had to add most of them manually. Android 13 builds on this idea to improve the quick settings tab by introducing the Quick Settings placement API. Developers can now include the API within their apps to let users add their app’s quick actions in the quick settings panel directly. The API allows apps to send prompts to users suggesting them to add toggles to the quick settings pane.
The introduction of app-oriented Quick Settings can become a gamechanger in how people use certain apps. For instance, users can directly connect or disconnect to VPN services without having to open the VPN app every time they need it. App developers can also think of unique ways of increasing their app engagements with handy toggle switches.
Support for Bluetooth LE Audio and MIDI 2.0
Bluetooth has been there for a while as the go-to technology to transfer audio and stream music on wireless devices. While there have been many updates to the Bluetooth technology, it is still a power hog in its current form. Android devices lose a hefty amount of juice while handling Bluetooth devices, especially when multiple devices like smartwatches and audio devices are connected to the system.
Bluetooth LE (Low Energy) Audio is an attempt to decrease the significant power dependence of Bluetooth devices and make them function at low power. Many industry experts believe LE audio will completely replace the classic Bluetooth technology we see around. LE audio promises some phenomenal benefits over classic Bluetooth, such as letting users broadcast their audio to nearby devices and listening to public broadcasts, all while using very low energy.
Android 13 has built-in Bluetooth LE support, and app developers can use it to develop apps that benefit from the LE audio technology. Android 13 also supports MIDI (musical instrument digital interface) 2.0 hardware through USB. Users can now connect their MIDI 2.0 supporting devices such as keyboards and other musical instruments to their Android 13 running smartphones through the USB port and enjoy benefits like better controller resolution and better performance.
There’s not much in the graphics enhancement in Android 13 over Android 12, especially in ways developers might be impacted. Android 13 only brings programmable shaders to the graphical capabilities of Android. Let’s look at programmable shaders and their benefits:
App developers can now use the Runtime Shader objects by programming functions under the Android Graphic Shading Language (AGSL) and implement complex effects like ripples, blurs, stretches, over scrolls, and more inside their application. Android has taken inspiration from OpenGL ES Shading Language, and you can see the similarities in the syntax of the two languages.
Previous versions of Android used the GLSL fragment shader to create different visual effects on the screen. On the other hand, Android 13 uses AGSL, where you can create complex shapes more effectively.
Media and Accessibility Related Features
Android 13 introduces some handy media playback and accessibility features that developers can use to enhance their app experience for users, especially those with challenging disabilities. Let’s take a look at these features:
Using a smartphone is a routine task for most of us, but some people with disabilities like visual and hearing impairment face immense problems while doing the same things. Most modern operating systems come with features that help people with disabilities to interact with the software effectively. Android has also had accessibility features for a long time, and its newest version adds some more helpful accessibility features.
Android 13 brings a new system-wide accessibility feature to enable audio narration for each app and UI element. Developers can use the narration feature inside their apps without having to develop a narrator of their own. Moreover, developers can also ask for the user’s choice whether they want to enable the narration feature.
Next up, Android 13 brings new audio route APIs in the AudioManager class. Developers can now use the getAudioDevicesForAttributes() API to get the list of all the audio devices connected to the Android device. These devices include the phone’s speakers and all the other wired or wireless audio devices like Bluetooth headphones and wired earphones. Additionally, you can also use the getDirectProfilesForAttributes() API to know if your app can directly play an audio stream. The Audio Profile API tells the app if there is an error or if playback is not possible for any reason. Developers can now integrate the information from these new APIs and decide the best audio format for their streams.
Developers can also let the users decide the output preference for the in-app audio. In the current form, Android automatically chooses the audio output device based on the system settings. So, if you have a Bluetooth audio device connected to Android, it would preferably play music or videos through the Bluetooth device. If you wanted to listen to the same audio from the device’s in-built speakers, you first had to disconnect the Bluetooth device and resume playback. After integrating the APIs mentioned above in Android 13, users can choose the playback device without constantly disconnecting and reconnecting devices.
Better Integration of Languages Other Than English
Android’s features have immensely improved the user experience for the English preferring section, but a significant number of users prefer using their devices in their native language. Older versions of Android haven’t done much about the integration of other languages, and therefore, UI elements in other languages (especially the non-Latin scripts) often appear unnatural in the previous Android versions.
Android is now recognizing the needs of multilingual users, and India has one of the largest populations of multilinguists. With more Indians joining the smartphone market, there is a constant addition of diversity to the Android ecosystem. While Google has recently looked into the matter, Indus App Bazaar has recognized the potential need to integrate more local languages into daily tech for a long time. Indus App Bazaar is currently home to more than 400,000 apps that support 12 Indian languages, and you must check out Indus App Bazaar for a better outreach if you are a developer targeting the Indian masses.
Returning to Android 13, Google has brought some fantastic language-centric features this time around. Here are some of these new additions:
Different language preferences for each app
Android users had to choose a system language while setting up the device. Android then automatically selects the system language as the preferred language for apps on the device. If a user wanted to use different languages for the system and apps, say English for the Android system and Hindi for apps on their device, they had to change the language for each app on their device manually.
Android 13 massively eases this mammoth task for multilingual users by providing a centralized location to modify app languages. If you are a developer dealing with multilingual apps, you should revise your app’s code to support the centralized language-changing feature. To do this, your app should declare Android:localeConfig in its code to let Android know that the app supports multiple languages. Android automatically includes your app in the list of multilingual apps in the library and allows users to modify the app’s language from the system settings.
Next up, Android 13 brings in new language-centric APIs that ask users for their preferred language at the runtime. These new APIs ensure the user has a seamless experience while switching languages and the app behaves consistently. Moreover, the new APIs also help developers reduce the boilerplate code from their apps. You also get the support for split APKs and Auto Backup for Apps if you want to store the user language settings.
Android 13 brings minimal user-facing features but includes numerous small and essential changes for developers, who have a lot to take from Android 13. It brings a ton of outstanding APIs that can enhance everything from app productivity to engagements.
Developers must try integrating as many of these new features as possible to make their app utilize Android’s latest offerings.
Some notable mentions of the fantastic features that developers should look forward to are quick settings placement API, language preference API, and the audio output APIs. Additionally, if you develop multilingual apps or want to target the Indian masses, you should consider offering your apps on the Indus App Bazaar.
Enjoyed this post? You can read more of our blog posts here.
You can also keep up with all that’s happening within the app world by following us on Twitter, Instagram, Linkedin, and Facebook.