Tag Archives: latest

Concepts users spend 70% more time using the app on tablets than on phones

Posted by the Android team

Concepts is a digital illustration app created by TopHatch that helps creative thinkers bring their visions to life. The app uses an infinitely-large canvas format, so its users can sketch, plan, and edit all of their big ideas without limitation, while its vector-based ink provides the precision needed to refine and reorganize their ideas as they go.

For Concepts, having more on-screen real estate means more comfort, more creative space, and a better user experience overall. That’s why the app was specifically designed with large screens in mind. Concepts’ designers and engineers are always exploring new ways to expand the app’s large screen capabilities on Android. Thanks to Android’s suite of developer tools and resources, that’s easier than ever.

Evaluating an expanding market of devices

Large screens are the fastest growing segment of Android users, with more than 270 million users on tablets, foldables, and ChromeOS devices. It’s no surprise then that Concepts, an app that benefits users by providing them with more screen space, was attracted to the format. The Concepts team was also excited about innovation with foldables because having the large screen experience with greater portability gives users more opportunities to use the app in the ways that are best for them.

The team at Concepts spends a lot of time evaluating new large screen technologies and experiences, trying to find what hardware or software features might benefit the app the most. The team imagines and storyboards several scenarios, shares the best ones with a close-knit beta group, and quickly builds prototypes to determine whether these updates improve the UX for its larger user base.

For instance, Concepts’ designers recently tested the Samsung Galaxy Fold and found that users benefited from having more screen space when the device was folded. With help from the Jetpack WindowManager library, Concepts’ developers implemented a feature to automatically collapse the UI when the Galaxy’s large screen was folded, allowing for more on-screen space than if the UI were expanded.

Concepts’ first release for Android was optimized for ChromeOS and, because of this, supporting resizable windows was important to their user experience from the very beginning. Initially, they needed to use a physical device to test for various screen sizes. Now, the Concepts team can use Android’s resizeable emulator, which makes testing for different screen sizes much easier.

Android’s APIs and toolkit carry the workload

The developers’ goal with Concepts is to make the illustration experience feel as natural as putting pen to paper. For the Concepts team, this meant achieving as close to zero lag as possible between the stylus tip and the lines drawn on the Concepts canvas.

When Concepts’ engineers first created the app, they put a lot of effort into creating low-latency drawing themselves. Now, Android’s graphical APIs eliminate the complexity of creating efficient inking.

“The hardware to support low-latency inking with higher refresh rate screens and more accurate stylus data keeps getting better,” said David Brittain, co-founder and CEO of TopHatch, parent company of Concepts. “Android’s mature set of APIs make it easy.”

Concepts engineers also found that the core Android View APIs take care of most of the workload for supporting tablets and foldables and make heavy use of custom Views and ViewGroups in Concepts. The app’s color wheel, for example, is a custom View drawing to a Canvas, which uses Animators for the reveal animation. View, Canvas, and Animator are all classes from the Android SDK.

“Android’s tools and platform are making it easier to address the variety of screen sizes and input methods, with well-structured APIs for developing and increasing the number of choices for testing. Plus, Kotlin allows us to create concise, readable code,” said David.

Concepts’ users prefer large screens

Tablets and foldables represent the bulk of Concepts’ investments and user base, and the company doesn’t see that changing any time soon. Currently, tablets deliver 50% higher revenue per user than smartphone users. Tablets also account for eight of the top 10 most frequently used devices among Concepts’ users, with the other two being ChromeOS devices.

Additionally, Concepts’ monthly users spend 70% more time engaging with the app on tablets than on traditional smartphones. The application’s rating is also 0.3 stars higher on tablets.

“We’re looking forward to future improvements in platform usability and customization while increasing experimentation with portable form factors. Continued efforts in this area will ensure high user adoption well into the future,” said David.

Start developing for large screens today

Learn how you can reach a growing audience of users by increasing development for large screens and foldables today.

Source: Android Developers Blog

What’s new in the Jetpack Compose March ’23 release

Posted by Jolanda Verhoef, Android Developer Relations Engineer

Today, as part of the Compose March ‘23 Bill of Materials, we’re releasing version 1.4 of Jetpack Compose, Android's modern, native UI toolkit that is used by apps such as Booking.com, Pinterest, and Airbnb. This release contains new features like Pager and Flow Layouts, and new ways to style your text, such as hyphenation and line-break behavior. It also improves the performance of modifiers and fixes a number of bugs.

Swipe through content with the new Pager composable

Compose now includes out-of-the-box support for vertical and horizontal paging between different content. Using VerticalPager or HorizontalPager enables similar functionality to the ViewPager in the view system. However, just like the benefits of using LazyRow and LazyColumn, you no longer need to create an adapter or fragments! You can simply embed a composable inside the Pager:

// Display 10 items
HorizontalPager(pageCount = 10) { page ->
    // Your specific page content, as a composable:
    Text(
        text = "Page: $page",
        modifier = Modifier.fillMaxWidth()
    )
}

These composables replace the implementation in the Accompanist library. If you already use the Accompanist implementation, check out the migration guide. See the Pager documentation for more information.

Get your content flowing with the new Flow Layouts

FlowRow and FlowColumn provide an efficient and compact way to lay out items in a container when the size of the items or the container are unknown or dynamic. These containers allow the items to flow to the next row in the FlowRow or next column in the FlowColumn when they run out of space. These flow layouts also allow for dynamic sizing using weights to distribute the items across the container.

Here’s an example that implements a list of filters for a real estate app:

@Composable
fun Filters() {
  val filters = listOf(
    "Washer/Dryer", "Ramp access", "Garden", "Cats OK", "Dogs OK", "Smoke-free"
  )
  FlowRow(
    horizontalArrangement = Arrangement.spacedBy(8.dp)
  ) {
    filters.forEach { title ->
      var selected by remember { mutableStateOf(false) }
      val leadingIcon: @Composable () -> Unit = { Icon(Icons.Default.Check, null) }
      FilterChip(
        selected,
        onClick = { selected = !selected },
        label = { Text(title) },
        leadingIcon = if (selected) leadingIcon else null
      )
    }
  }
}

Performance improvements in Modifiers

The major internal Modifier refactor we started in the October release has continued, with the migration of multiple foundational modifiers to the new Modifier.Node architecture. This includes graphicsLayer, lower level focus modifiers, padding, offset, and more. This refactoring should bring performance improvements to these APIs, and you don't have to change your code to receive these benefits. Work on this continues, and we expect even more gains in future releases as we migrate Modifiers outside of the ui module. Learn more about the rationale behind the changes in the ADS talk Compose Modifiers deep dive.

Increased flexibility of Text and TextField

Along with various performance improvements, API stabilizations, and bug fixes, the compose-text 1.4 release brings support for the latest emoji version, including backwards compatibility with older Android versions 🎉🙌. Supporting this requires no changes to your application. If you’re using a custom emoji solution, make sure to check out PlatformTextStyle(emojiSupportMatch).

In addition, we’ve addressed one of the main pain points of using TextField. In some scenarios, a text field inside a scrollable Column or LazyColumn would be obscured by the on-screen keyboard after being focused. We re-worked core parts of scroll and focus logic, and added key APIs like PinnableContainer to fix this bug.

Finally, we added a lot of new customization options to Text and its TextStyle:

Draw outlined text using TextStyle.drawStyle.
Improve text transition and legibility during animations using TextStyle.textMotion.
Configure line breaking behavior using TextStyle.lineBreak. Use built-in semantic configurations like Heading, Paragraph, or Simple, or construct your own LineBreak configuration with the desired Strategy, Strictness, and WordBreak values.
Add hyphenation support using TextStyle.hyphens.
Define a minimum number of visible lines using the minLines parameter of the Text and TextField composables.
Make your text move by applying the basicMarquee modifier. As a bonus, because this is a Modifier, you can apply it to any arbitrary composable to make it move in a similar marquee-like fashion!

Marquee text using outline with shapes stamped on it using the drawStyle API.

Improvements and fixes for core features

In response to developer feedback, we have shipped some particularly in-demand features & bug fixes in our core libraries:

Test waitUntil now accepts a matcher! You can use this API to easily synchronize your test with your UI, with specific conditions that you define.
animatedContent now correctly supports getting interrupted and returning to its previous state.
Accessibility services focus order has been improved: the sequence is now more logical in common situations, such as with top/bottom bars.
AndroidView is now reusable in LazyList if you provide an optional onReset lambda. This improvement lets you use complex non-Compose-based Views inside LazyLists.
Color.lerp performance has been improved and now does zero allocations: since this method is called at high frequency during fade animations, this should reduce the amount of garbage collection pauses, especially on older Android versions.
Many other minor APIs and bug fixes as part of a general cleanup. For more information, see the release notes.

Get started!

We’re grateful for all of the bug reports and feature requests submitted to our issue tracker - they help us to improve Compose and build the APIs you need. Continue providing your feedback, and help us make Compose better!

Wondering what’s next? Check out our updated roadmap to see the features we’re currently thinking about and working on. We can’t wait to see what you build next!

Happy composing!

Source: Android Developers Blog

Android 14 Developer Preview 2

Posted by Dave Burke, VP of Engineering

Today, we're releasing the second Developer Preview of Android 14, building on the work of the first developer preview of Android 14 from last month with additional enhancements to privacy, security, performance, developer productivity, and user customization while continuing to refine the large-screen device experience on tablets, foldables, and more.

Android delivers enhancements and new features year-round, and your feedback on the Android 14 developer preview and Quarterly Platform Release (QPR) beta program plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.

Working across form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. See get started with building for large screens and learn about foldables for a quick jumpstart on how to get your apps ready. Our app quality guidance for large screens contains detailed checklists to review your app. We've also recently released libraries supporting low latency stylus and motion prediction.

The large screen gallery contains design inspiration for social and communications, media, productivity, shopping, and reading app experiences.

Privacy and security

Privacy and security have always been a core part of Android's mission, built on the foundation of app sandboxing, open source code, and open app development. In Android 14, we’re building the highest quality platform for all by providing a safer device environment and giving users more controls to protect their information.

Selected photos access

We recommend that you use the Photo Picker if your app needs to access media that the user selects; it provides a permissionless experience on devices running Android 4.4 onwards, using a combination of core platform features, Google Play system updates, and Google Play services.

If you cannot use Photo Picker, when your app requests any of the visual media permissions (READ_MEDIA_IMAGES / READ_MEDIA_VIDEO) introduced in SDK 33, Android 14 users can now grant your app access to only selected photos and videos.

In the new dialog, the permission choices will be:

Allow access to all photos: the full library of all on-device photos & videos is available
Select photos: only the user's selection of photos & videos will be temporarily available via MediaStore
Don’t allow: access to all photos and videos is denied

Apps can prompt users to select media again by requesting the media permissions again and having the READ_MEDIA_VISUAL_USER_SELECTED permission declared in their app manifest.

Please test this new behavior with your apps and adapt your UX to handle the new permission and the media file reselection flow.

Credential manager

Android 14 adds Credential Manager as a platform API, and we're supporting it back to Android 4.4 (API level 19) devices through a Jetpack Library with a Google Play services implementation. It aims to make sign-in easier for users with APIs that retrieve and store credentials with user-configured credential providers. In addition to supporting passwords, the API allows your app to sign-in using passkeys, the new industry standard for passwordless sign-in. Passkeys are built on industry standards, can work across different operating systems and browser ecosystems, and can be used with both websites and apps. Developer Preview 2 features improvements in the UI styling for the account selector, along with changes to the API based upon feedback from Developer Preview 1. Learn more here.

Safer implicit intents

For apps targeting Android 14, creating a mutable pending intent with an implicit intent will throw an exception, preventing them from being able to be used to trigger unexpected code paths. Apps need to either make the pending intent immutable or make the intent explicit. Learn more here.

Background activity launching

Android 10 (API level 29) and higher place restrictions on when apps can start activities when the app is running in the background. These restrictions help minimize interruptions for the user and keep them more in control of what's shown on their screen. To further reduce instances of unexpected interruptions, Android 14 gives foreground apps more control over the ability of apps they interact with to start activities. Specifically, apps targeting Android 14 need to grant privileges to start activities in the background when sending a PendingIntent or when binding a Service.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Background optimizations

Developer Preview 2 includes optimizations to Android’s memory management system to improve resource usage while applications are running in the background. Several seconds after an app goes into the cached state, background work is disallowed outside of conventional Android app lifecycle APIs such as foreground services, JobScheduler, or WorkManager. Background work is disallowed an order of magnitude faster than on Android 13.

Fewer non-dismissible notifications

Notifications on Android 14 containing FLAG_ONGOING_EVENT will be user dismissible on unlocked handheld devices. Notifications will stay non-dismissible when the device is locked, and notification listeners will not be able to dismiss these notifications. Notifications that are important to device functionality, like system and device policy notifications, will remain fully non-dismissible.

Improved App Store Experiences

Android 14 introduces several new PackageInstaller APIs which allow app stores to improve their user experience, including the requestUserPreapproval() method that allows the download of APKs to be deferred until after the installation has been approved, the setRequestUpdateOwnership() method that allows an installer to indicate that it is responsible for future updates to an app it is installing, and the setDontKillApp() method that can seamlessly install optional features of an app through split APKs while the app is in use. Also, the InstallConstraints API gives installers a way to ensure that app updates happen at an opportune moment, such as when an app is no longer in use.

If you develop an app store, please give these APIs a try and let us know what you think!

Personalization

Regional Preferences

Regional preferences enable users to personalize temperature units, the first day of the week, and numbering systems. A European living in the United States might prefer temperature units to be in Celsius rather than Fahrenheit and for apps to treat Monday as the beginning of the week instead of the US default of Sunday.

New Android Settings menus for these preferences provide users with a discoverable and centralized location to change app preferences. These preferences also persist through backup and restore. Several APIs and intents grant you read access to user preferences for adjusting app information display (getTemperatureUnit, getFirstDayOfWeek). You can also register a BroadcastReceiver on ACTION_LOCALE_CHANGED to handle locale configuration changes when regional preferences change.

App compatibility

We’re working to make updates faster and smoother with each platform release by prioritizing app compatibility. In Android 14 we’ve made most app-facing changes opt-in to give you more time to make any necessary app changes, and we’ve updated our tools and processes to help you get ready sooner.

Developer Preview 2 is in the period where we're looking for input on our APIs, along with details on how platform changes affect your apps, so now is the time to try new features and give us your feedback.

It’s also a good time to start your compatibility testing and identify any work you’ll need to do. You can test some of them without changing your app's targetSdkVersion using the behavior change toggles in Developer Options. This will help you get a preliminary idea of how your app might be affected by opt-in changes in Android 14.

App compatibility toggles in Developer Options.

Platform Stability is when we’ll deliver final SDK/NDK APIs and app-facing system behaviors. We’re expecting to reach Platform Stability in June 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

The Developer Preview has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, the easiest way to get started is using the Android Emulator in a tablet or foldable configuration in the latest preview of the Android Studio SDK Manager. For phones, you can get started today by flashing a system image onto a Pixel 7 Pro, Pixel 7, Pixel 6a, Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5, or Pixel 4a (5G) device. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio.

For the best development experience with Android 14, we recommend that you use the latest preview of Android Studio Giraffe (or more recent Giraffe+ versions). Once you’re set up, here are some of the things you should do:

Try the new features and APIs - your feedback is critical during the early part of the developer preview. Report issues in our tracker on the feedback page.
Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14; install your app onto a device or emulator running Android 14 and extensively test it.
Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview system images and SDK regularly throughout the Android 14 release cycle. This preview release is for developers only and not intended for daily or consumer use, so it will only available by manual download for new Android 14 developer preview users. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 2 now. Otherwise, you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android 14 Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Source: Android Developers Blog

Policy Updates: New Wear OS App Quality Requirements

Posted by Ishaan Aggarwal, Product Manager

Today we are announcing upcoming policy changes intended to improve the quality of apps for Wear OS and their presentation in the Google Play Store. We are introducing these changes to ensure app users get a basic consistent experience across all apps in accordance with our latest Wear OS design and development principles. In addition, updates to the publishing requirements will improve the discovery and presentation of your Wear OS apps in the Google Play Store.

The new requirements will come into effect from August 31, 2023. Until then, we will continue to use the existing policies to review and maintain the quality of Wear OS apps. The overall Wear OS app review process will continue to be mandatory and remains unchanged.

Alongside the above policy changes, all Wear OS apps must target Android 11 (API level 30). Apps that target lower levels will stop being discoverable to all Google Play users whose devices run Android OS versions newer than the app’s target API level from August 31, 2023. This is to ensure that the app is built to meet the safety and quality standard that users expect from newer Wear OS versions.

The following list highlights examples of upcoming quality changes. See a comprehensive list of review criteria here:

Black Background – Use a black background for all apps and tiles.

images of watch faces side by side showing Do: Use black Background on the left and Don't use any other color for background on right

Ongoing Activity – When a user has an ongoing activity, you must do the following:
- Show the ongoing activity indicator on the watch face.
- Update recent apps with the appropriate app launcher chip for the ongoing activity.
- Reference the ongoing activity from the tile, if the tile is present in the user’s tile carousel.

Images of two watch faces displaying ongoing activity indicator at the bottom of the watch face on the left and Ongoing activity on an app launcher chip in recent apps on the right

Show Time – Display the time of day clearly at the top of the app home screen and any ongoing activity screens. We recommend that you display the time of day at the top of all activities except dialogs and confirmation screens.

Images of two watch faces with showing time display at the top of the app on the left and Don’t display the time in a dialog, confirmation screen, or picker on the right

These quality updates span visual experience, functionality, performance, and Google Play listings; they are designed to help you provide a consistent, intuitive and enjoyable experience for Wear OS users. With careful consideration of app design, optimal functional behavior, and Google Play experiences, we are aiming to improve app quality and discoverability of quality apps across the Wear OS ecosystem.

As you design and develop, keep in mind the following recommendations to ensure a modern, successful, and discoverable app:

Build a modern app that targets API Level 30.
Test your app on devices running Wear OS 3 and above to make sure it works well on the latest Wear OS versions.
Consider the new Wear OS quality requirements early when designing and developing your app to create quality experience.

Thank you for your continued support of Wear OS by Google. We look forward to seeing what you create.

Source: Android Developers Blog

The first developer preview of Android 14

Posted by Dave Burke, VP of Engineering

Making Android work well for each and every one of the billions of Android users is a collaborative process between us, Android hardware manufacturers, and you, our developer community.

Today we're releasing the first Developer Preview of Android 14, and your feedback in these previews is a critical part of making Android better for everyone. Android 14 continues our work to improve your productivity as developers, along with enhancements to performance, privacy, security, and user customization. This preview is just the beginning, and we’ll have lots more to share as we move through the release cycle.

Android continues to deliver enhancements and new features year-round, and your Android 14 developer preview and Quarterly Platform Release (QPR) beta program feedback plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.

Working across devices and form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. To help you build apps that adapt to different screen sizes, we've created window size classes, sliding pane layout, Activity embedding, and box with constraints and more, all supported in Jetpack Compose. With every release, our goal is to make it easier for you to optimize your app across all Android surfaces.

To help streamline getting your apps ready we have updated our app quality guidance for large screens, and provided additional learning opportunities around building for large screens and foldables. The large screen gallery contains proven design patterns along with design inspiration around the markets that your app supports such as social and communications, media, productivity, shopping, and reading apps.

Multi-device experiences are a big part of the future of Android. You can get started today with the Cross device SDK preview, allowing you to build rich experiences that intuitively work across different devices and form factors, and there's more to come.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Updates and additions to JobScheduler and Foreground Services

It's more complicated than necessary to perform some background work, such as downloading large files when WiFi is available. We're creating a standard path for this work to simplify your app development and potentially improve the user experience. We're also being more opinionated about how foreground services should be used, reserving them for only the highest priority user-facing tasks so that Android can improve resource consumption and battery life.

In Android 14, we are making changes to existing Android APIs (Foreground Services and JobScheduler) including adding new functionality for user-initiated data transfers, along with an updated requirement to declare foreground service types. The user-initiated data transfer job will make managing user initiated downloads and uploads easier, particularly when they require constraints such as downloading on Wi-Fi only. The requirement to declare foreground service types allows you to clearly define the intent of the background work of your app while making it clear which use-cases are appropriate for foreground services. In addition, Google Play will be rolling out new policies to ensure the appropriate use of these APIs, with more details coming soon.

Optimized broadcasts

We’ve made several optimizations to the internal broadcast system to improve battery life and responsiveness. While most of the optimizations are internal to Android and should not impact your apps, we have adjusted how apps receive context-registered broadcasts once the app goes into a cached state. Broadcasts to context-registered receivers may be queued and only delivered to the app once it comes out of the cached state. Furthermore, some repeating context-registered broadcasts, such as BATTERY_CHANGED, may be merged into one final broadcast before it is delivered once the app comes out of the cached state.

Exact alarms

The invocation of exact alarms can significantly affect the device's resources, such as battery life. So in Android 14, newly installed apps targeting Android 13+ (SDK 33+) that are not clocks or calendars must request the user to grant them the SCHEDULE_EXACT_ALARM special permission before setting exact alarms. Apps can direct users to the settings page via an intent to toggle this permission, but we encourage you to evaluate your use cases and choose more flexibly scheduled alternatives when possible.

Clock and calendar apps targeting Android 13+ (SDK 33+) that rely on exact alarms as part of their core app workflow will be able to declare the USE_EXACT_ALARM normal permission instead (granted on install). Apps will not be able to publish a version of their app to the Play store with this permission in the manifest unless they qualify based on the policy language.

Customization

We're continuing to make sure that Android users can tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling

Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%.

To mitigate issues where text gets too large, starting in Android 14, a non-linear font scaling curve is automatically applied. This ensures that text that is already large enough doesn’t increase at the same rate as smaller text.

Examples of text scaling showing the differences between the sizing of standard font at 100% (no scaling)on the left, standard scaling (200%) in the middle, and non-linear scaling (200%)on the right

In Android 14, you should test your app UI with the maximum font size using the Font size option within the Accessibility > Display size and text settings. Ensure that the adjusted large text size setting is reflected in the UI, and that it doesn’t cause text to be cut off. Our documentation has more on best practices.

Per-app language preferences

You can dynamically update your app's localeConfig with LocaleManager.setOverrideLocaleConfig to customize the set of languages displayed in the per-app language list in Android Settings. This allows you to customize the language list per region, run A/B experiments, and provide updated locales if your app utilizes server-side localization pushes.

IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language.

Grammatical Inflection API

The Grammatical Infection API allows you to more easily add support for users who speak languages which have grammatical gender. For example,

Masculine: “Vous êtes abonné à...”

Feminine: “Vous êtes abonnée à…”

Neutral: “Abonnement à…activé”

Grammatical gender is inherent to the language and cannot be easily worked around in some non-English languages. This new API lowers the effort to support viewer gender (who’s viewing the UI; not who’s being talked about) as compared to using the SelectFormat in ICU which must be applied on a per string basis.

To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

Privacy and Security

Runtime receivers

Apps targeting Android 14 must indicate if dynamic Context.registerReceiver() usage should be treated as "exported" or "unexported", a continuation of the manifest-level work from previous releases. Learn more here.

Safer implicit intents

To prevent malicious apps from intercepting intents, apps targeting Android 14 are restricted from sending intents internally that don't specify a package. Learn more here.

Safer dynamic code loading

Dynamic code loading (DCL) introduces outlets for malware and exploits, since dynamically downloaded executables can be unexpectedly manipulated, causing code injection. Apps targeting Android 14 require dynamically loaded files to be marked as read-only. Learn more here.

Block installation of apps

Malware often targets older API levels to bypass security and privacy protections that have been introduced in newer Android versions. To protect against this, starting with Android 14, apps with a targetSdkVersion lower than 23 cannot be installed. This specific version was chosen because some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 (API level 23).

On devices that upgrade to Android 14, any apps with a targetSdkVersion lower than 23 will remain installed.

You can test apps targeting an older API level using the following ADB command:

adb install --bypass-low-target-sdk-block FILENAME.apk

Credential Manager and Passkeys support

We recently announced the alpha release of Credential Manager, a new Jetpack API that allows you to simplify your users' authentication journey, while also increasing security with support of passkeys. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors and more convenient for users (they require just a biometric swipe to securely sign in on any device). Read more here.

App compatibility

OpenJDK 17 Support - This preview includes access to 300 OpenJDK 17 classes. We are working hard to fully enable Java 17 language features in upcoming developer previews. These include record classes, multi-line strings and pattern matching instanceof. Thanks to Google Play system updates (Project Mainline), over 600M devices are enabled to receive the latest Android Runtime (ART) updates that include these changes. This is part of our commitment to give apps a more consistent, secure environment across devices, and to deliver new features and capabilities to users independent of platform releases.

Easier testing and debugging of changes - To make it easier for you to test the opt-in changes that can affect your app, we’ll make many of them toggleable again this year. With the toggles, you can force-enable or disable the changes individually from Developer options or adb. Check out the details here.

App compatibility toggles in Developer Options

Platform stability milestone - Like last year, we’re letting you know our Platform Stability milestone well in advance, to give you more time to plan for app compatibility work. At this milestone we’ll deliver final SDK/NDK APIs and also final internal APIs and app-facing system behaviors. We’re expecting to reach Platform Stability in June 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

Try the new features and APIs - your feedback is critical during the early part of the developer preview. Report issues in our tracker on the feedback page.
Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14; install your app onto a device or emulator running Android 14 and extensively test it.
Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview system images and SDK regularly throughout the Android 14 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download only. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 1 now. Otherwise you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Source: Android Developers Blog

The first developer preview of Android 14

Posted by Dave Burke, VP of Engineering

Making Android work well for each and every one of the billions of Android users is a collaborative process between us, Android hardware manufacturers, and you, our developer community.

Working across devices and form factors

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Updates and additions to JobScheduler and Foreground Services

Optimized broadcasts

Exact alarms

Customization

We're continuing to make sure that Android users can tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling

Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%.

Per-app language preferences

IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language.

Grammatical Inflection API

The Grammatical Infection API allows you to more easily add support for users who speak languages which have grammatical gender. For example,

Masculine: “Vous êtes abonné à...”

Feminine: “Vous êtes abonnée à…”

Neutral: “Abonnement à…activé”

To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

Privacy and Security

Runtime receivers

Safer implicit intents

To prevent malicious apps from intercepting intents, apps targeting Android 14 are restricted from sending intents internally that don't specify a package. Learn more here.

Safer dynamic code loading

Block installation of apps

On devices that upgrade to Android 14, any apps with a targetSdkVersion lower than 23 will remain installed.

You can test apps targeting an older API level using the following ADB command:

adb install --bypass-low-target-sdk-block FILENAME.apk

Credential Manager and Passkeys support

App compatibility

App compatibility toggles in Developer Options

Get started with Android 14

Try the new features and APIs - your feedback is critical during the early part of the developer preview. Report issues in our tracker on the feedback page.
Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14; install your app onto a device or emulator running Android 14 and extensively test it.
Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 1 now. Otherwise you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

For complete information, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Source: Android Developers Blog

Compose for Wear OS 1.1 is now stable: check out new features!

Posted by Kseniia Shumelchyk, Android Developer Relations Engineer

Today we’re releasing version 1.1 of Compose for Wear OS, our modern declarative UI toolkit to help developers build beautiful, responsive apps for Wear OS.

Since the first stable release earlier this year, we have seen many developers taking advantage of the powerful tools and intuitive APIs to make building their app simpler and more efficient. Todoist and Outdooractive are some of the developers that rebuilt their Wear apps with Compose and accelerated the delivery of a new, functional user experience.

Todoist increased its growth rate by 50% since rebuilding their app for Wear 3 and Outdooractive reduced development time by 30% and saw a significant boost in developer productivity and better design/developer collaboration:

“Compose makes the UI code more intuitive to write and read, allowing us to prototype faster in the design phase and also collaborate better on the code. What would have taken us days now takes us hours.”

The Compose for Wear OS 1.1 release contains new features and brings improvements to existing components, focusing on UX and accessibility. We’ve already updated our samples, codelab, and Horologist libraries to work with Compose for Wear OS 1.1.

New features and APIs

The Compose for Wear OS 1.1 release includes the following new functionality (baseline profiles already added for new components):

Outlined style for Chips and Buttons

To give you additional ability to customize the user interface, we added outlined styles for Chips and Buttons. New OutlinedChip and OutlinedButton composables provide a transparent component with a thin border that can be used for medium-emphasis actions. Also available for compact versions: OutlinedCompactChip and OutlinedCompactButton.

OutlinedChip and OutlinedButton composables

Modifying Chip and Button shapes

Starting from version 1.1, you can also modify shapes for Chip/ToggleChip and Button/ToggleButton components using new functions overloads.

Different Chip and Button shapes

Placeholder API

A new experimental API has been added to implement placeholder support. This can be used to achieve three distinct visual effects separately or all together:

A placeholder background brush effect used in containers such as Chip and Cards to draw over the normal background when waiting for content to load.
A Modifier.placeholder() to draw a stadium shaped placeholder widget over the top of content that is being loaded.
A Modifier.placeholderShimmer() for gradient/shimmer effect that is drawn over the top of the other effects to indicate to users that the current state is waiting for data to load.

These effects are designed to be coordinated and shimmer and wipe-off in an orchestrated fashion.

Placeholder API usage examples

Check out the reference docs and sample in Horologist to see how to apply the placeholder to common use cases, such as a Chip with icon and a label that puts placeholder over individual content slots and draws a placeholder shimmer on top while waiting for data to load.

Modifier.scrollAway

Horologist’s fadeAway modifier has been graduated to scrollAway modifier in version 1.1. Modifier.scrollAway scrolls an item vertically in and out of view, based on the scroll state, and already has overloads to work with Column, LazyColumn and ScalingLazyColumn.

Use this modifier to make TimeText fade out of the view as the user starts to scroll a list of items upwards.

ScrollAway modifier usage with TimeText

Additional parameters in CurvedTextStyle

CurvedTextStyle now supports additional parameters (fontFamily, fontWeight, fontStyle, fontSynthesis) to specify font details when creating a curved text style. Extended curved text style can be used on both curvedText and basicCurvedText.

Applying different font to curved text

UX and accessibility improvements

The 1.1 release also focuses on bringing a refined user experience, improvements for TalkBack support and overall better accessibility:

ToggleChip and SplitToggleChip support usage of animated toggle controls (Checkbox, Switch and RadioButton) that can be used instead of the static icons provided by ToggleChipDefaults.
Default gradient colors for Chip/ToggleChip and Cards were adjusted to match the latest UX specification.
Updated a number of the default colors in the MaterialTheme to improve accessibility as the original colors did not have sufficient contrast.
Accessibility improvements to Picker so that multi-picker screens are navigable with screen readers and the content description is accessible.
InlineSlider and Stepper now have button roles, so that TalkBack can recognize them as buttons.
The PositionIndicator in Scaffold is now positioned and sized so that it only takes the space needed. This is useful when semantic information is added to it, so TalkBack gets the correct bounds of the PositionIndicator on screen.

It’s time ⌚ to bring your app to the wrist!

Get started

To begin developing with Compose for Wear OS, get started with hands-on experience trying our codelab, and make sure to check out the documentation and samples. Visit Compose for Wear OS release notes for full list of changes available in version 1.1.

Note that using version 1.1 of Compose for Wear OS requires using the version 1.3 of androidx.compose libraries and therefore Kotlin 1.7.10. Check out the Compose to Kotlin Compatibility Map for more information.

Provide feedback

Compose for Wear OS continues to evolve with the features you’ve been asking for. Please do continue providing us feedback on the issue tracker and join Kotlin Slack #compose-wear channel to connect with the Google team and dev community.

We’re excited to see a growing number of apps using Compose for Wear OS in production, and we’re grateful for all issues and requests that help us to make the toolkit better!

Start building for Wear OS now

Discover even more with technical sessions from the Android Dev Summit providing guidance on app architecture, testing, handling rotary input, and verticalized sessions for media and fitness.

Source: Android Developers Blog

Android 13 for TV is now available

Posted by Wolfram Klein, Product Manager, Android TV OSToday we’re releasing the newest version of Android TV OS, Android 13 for TV! This latest release brings further improvements in performance and accessibility to help our developers build engaging apps for the next generation of TVs.

Here’s a look at some of what’s new in Android 13 for TV.

Performance and Quality

Android 13 brings new APIs to the big screen that help developers deliver high quality experiences to users across different device types.

Improvements to the AudioManager API allow developers to anticipate audio attribute support for the active audio device and select the optimal format without starting playback.
Users can now change the default resolution and refresh rate on supported HDMI source devices for a more reliable playback experience.
HDMI state changes are now surfaced to the MediaSession lifecycle, allowing TV dongles and other HDMI source devices to save power and pause content in reaction to HDMI state changes.

Accessibility and Input Controls

Android 13 brings new features to make interacting with TV more adaptable.

The InputDevice API now supports different keyboard layouts. Game developers can also reference keys by their physical location to support different layouts of physical keyboards.
A newly created audio descriptions API in AccessibilityManager allows your app to query the new system-wide audio description preference setting, helping developers provide audio descriptions in line with a user’s preference automatically.

Check out the Android TV OS developer site for details on even more features that come with Android 13 on TVs. The new release is now available for both ADT-3 and the Android TV emulator, and developers can choose to test on either the Google TV interface or the standard Android TV interface. As always, we are thankful to our developers for the continued support of Android TV OS. We can’t wait to see what amazing and innovative experiences you’ll continue to build for the big screen.

Source: Android Developers Blog

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Over the course of 2022, we've published design proposals and released a number of Developer Previews. We appreciate all of the feedback we've received which has helped us refine and improve these proposals.

Beginning early next year we plan to rollout the initial Privacy Sandbox Beta to Android 13 mobile devices, so that developers can take the next steps in testing these new solutions. We'll start with a small percentage of devices and increase over time. Note that Developer Previews will continue to be released and this is where we’ll first deliver the latest features for early feedback before being released on production devices.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.

Enroll to access the Privacy-Preserving APIs

Starting with the Beta release, as well as future Developer Previews, developers will need to complete an enrollment process in order to utilize the ads-related APIs (including Topics, FLEDGE, and Attribution Reporting). The enrollment process will verify developer identity and gather developer-specific data needed by the APIs. You can learn more about how to enroll here.

How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

During the initial rollout stages, enrolled developers will also need to join the early testers program. This program will allow developers to test the APIs on a limited number of their own Android 13 devices for internal apps and requested published apps.

For the SDK Runtime, we’ll have a closed beta for developers to test Runtime-enabled SDK distribution to select apps. Because of the coordination required to test the SDK Runtime on production devices, we expect this beta to involve a limited number of partners who can dedicate resources to support this testing. If you’re interested in participating, please register your interest.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.

Advice For Advertisers & Publishers

We’ve heard from many advertisers and publishers about the role they can play in testing these new technologies. For companies that rely on third party solutions for ad serving or ad measurement, we recommend working with your providers to understand their testing roadmaps and how you can participate in early testing of Privacy Sandbox.

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."

Source: Android Developers Blog

Preparing for the Android Privacy Sandbox Beta

Posted by Anthony Chavez, VP Product ManagementIn February we announced the Privacy Sandbox on Android, with the goal of bringing new, more private advertising solutions to mobile.

Today, we're sharing more details about the Privacy Sandbox Beta so that developers can get prepared.

Enroll to access the Privacy-Preserving APIs

How to participate

The Privacy Sandbox Beta will be available for ad tech and app developers who wish to test the ads-related APIs as part of their solutions.

To utilize the Beta release, developers will need to compile their solutions with an API level 33 SDK extension update that is coming soon.

Advice For Advertisers & Publishers

We want to thank everyone who has engaged on the Android Privacy Sandbox, and look forward to continued feedback as we enter this next phase of testing."