Tag Archives: Develop

Get ready for Google I/O May 20–21

Posted by the Google I/O team

Google I/O is back

Google I/O returns May 20 – 21! Join us online as we share our vision for the future of technology, along with updates across Android, AI, web, cloud, and more.

Tune in to learn how the latest AI models can help you build innovative apps and transform development workflows. We'll also share how we're making Android development even easier, and empowering you to build richer, more engaging web experiences.

Register now and tune in live

Head to the Google I/O website and register to receive updates. The livestreamed keynotes kick off on May 20th at 10 AM PT, and new this year, we’ll be streaming developer product keynotes live from Shoreline across both days!

Stay tuned for details about I/O Connect events this summer, and test your skills at solving the #GoogleIO puzzle to unlock bonus worlds and earn badges.

Making the Play Integrity API faster, more resilient, and more private

Posted by Prabhat Sharma – Director, Trust and Safety, Play, Android, and Chrome

At Google Play, we’re committed to providing a safe and secure environment for your business to thrive. That’s why we continually invest in reinforcing user trust, protecting your business, and safeguarding the ecosystem. This includes actively combating bad actors who try to deceive users or spread malware, and giving you tools to combat abuse.

Our tools like the Play Integrity API helps protect your business from revenue loss and enhance user safety. You can use the Play Integrity API to detect suspicious activity and decide how to respond to abuse, such as fraud, bots, cheating, or data theft. In fact, apps that use Play Integrity features have seen 80% less unauthorized usage on average compared to other apps. Today, we’re sharing how we’re enhancing the Play Integrity API for everyone.

Play integrity verdicts are becoming faster, less spoofable, and more privacy-friendly

Starting today, we’re changing the technology that powers the Play Integrity API on all devices running Android 13 (API level 33) and above to make it faster, more reliable, and more private for users. Developers already using Play Integrity API can opt-in to start using the new verdicts today; all API integrations will automatically transition to the new verdicts in May 2025. The improved verdicts will require, and make greater use of, hardware-backed security signals using Android Platform Key Attestation, making it significantly harder and more costly for attackers to bypass. We’ll also be adjusting verdicts when we detect security threats across Android SDK versions, such as when there is evidence of excessive activity or key compromise, without requiring any developer work. And now, Play Integrity API will have the same level of reliability and support across all Android form factors.

The transition to the new verdicts will reduce the device signals that need to be collected and evaluated on Google servers by ~90% and our testing indicates verdict latency can improve by up to ~80%.

You can now check whether a device has a recent security update

Play Integrity API offers enhanced security signals, like the optional “meets-strong-integrity” and “meets-basic-integrity” responses in the device recognition verdict, to help you decide how much you trust the environment your app is running in. Now, we’re updating the “meets-strong-integrity” response to require a security update within the last year on devices running Android 13 and above. This update gives apps with higher security needs, like banking and finance apps, governments, and enterprise apps, more ways to tailor their level of protection for sensitive features, like transferring money. When the strong label isn’t available for the user, we recommend that you have a fallback option. Learn more about our recommended API practices.

We’re also making it easier for you to adjust your app's behavior based on the user’s Android SDK version with a new device attributes field. For example, your app could respond differently to the legacy “meets-strong-integrity” definition on devices running Android 12 and lower than to the enhanced definition on devices running Android 13 and higher. The FAQ includes some example code for using the new device attributes field.

We’re standardizing all optional verdict signals so it’s consistent for you to use

We’re simplifying and standardizing all verdict content across apps, games, SDKs, and more, so that what you see will be more consistent and predictable. For apps installed by Google Play, you can get enhanced verdicts with optional signals such as the improved “meets-strong-integrity” device verdict and the recently launched app access risk verdict (which helps you detect and and respond to apps that can capture the screen or control the device, so you can protect your users from scams or malicious activity). For apps installed out of Google Play and all other API requests, you’ll receive a verdict with information about the device, account license, and app, but without the extra security signals.

Developers can start using the improved verdicts today and they’ll go live for all integrations in May 2025

Starting today, all new integrations will automatically receive the improved verdicts. Developers who already use the Play Integrity API can opt-in to the new verdicts now, or wait until it automatically updates for them in May 2025. For more information, see the Play Integrity API documentation. With these ongoing enhancements, the Play Integrity API is becoming an even more essential tool for safeguarding your apps and users.



How useful did you find this blog post?

★ ★ ★ ★ ★

Increasing trust for embedded media

Posted by the Android team

Android WebView is a powerful and flexible API that Android developers can use to embed media in their apps, and continually improving its security and privacy protections is a top priority for our team. For example, embedded media providers should be able to verify that their media is playing in a trusted and safe environment. Android app developers and SDK providers already have solutions for this, including attestation services like the Play Integrity API and Firebase App Check, which preserve user privacy while enabling developers to verify their apps’ server requests. Today, app developers are able to pass information from these attestation services to embedded content providers; however, the current process is neither simple nor scalable. That’s why we’re piloting an experimental Android WebView Media Integrity API with select embedded media providers early next year.

How does this relate to the Web Environment Integrity API proposal?

We’ve heard your feedback, and the Web Environment Integrity proposal is no longer being considered by the Chrome team. In contrast, the Android WebView Media Integrity API is narrowly scoped, and only targets WebViews embedded in apps. It simply extends existing functionality on Android devices that have Google Mobile Services (GMS) and there are no plans to offer it beyond embedded media, such as streaming video and audio, or beyond Android WebViews.

What is the challenge with Android WebViews?

The Android WebView API lets app developers display web pages which embed media, with increased control over the UI and advanced configuration options to allow a seamless integration in the app. This brings a lot of flexibility, but it can be used as a means for fraud and abuse, because it allows app developers to access web content, and intercept or modify user interactions with it. While this has its benefits when apps embed their own web content, it does not prohibit bad actors from modifying content and, by proxy, misrepresenting its source.

What functionality are we bringing to embedded Android WebView media?

This sequence diagram shows a user requesting media in an Android app and the Android app returning the media in a manipulated WebView that could be used to alter the media and defraud the user.

The new Android WebView Media Integrity API will give embedded media providers access to a tailored integrity response that contains a device and app integrity verdict so that they can ensure their streams are running in a safe and trusted environment, regardless of which app store the embedding app was installed from. These verdicts are simple, low entropy metadata about the app and device and don’t contain any user or device identifiers. Unlike apps and games using Play Integrity API, media providers will not obtain the app’s Play licensing status and apps will also be able to exclude their package name from the verdict if they choose. Our goal for the API is to help sustain a thriving and diverse ecosystem of media content in Android apps, and we’re inviting media content providers to express interest in joining an early access program early next year.

Automatic Update Prompts for Crashing Apps

Posted by Kurt Williams, Product Manager, Google Play

We are excited to announce a new feature that will help you to increase the rollout velocity of app updates and meet Play’s quality bar. On phones and tablets running Android 7.0 (SDK level 24) and above, the Play Store will prompt users to update your app if it crashes in the foreground and a more stable version is available. This will reduce your user-perceived crash rate.

Update the app to fix crashes dialog
The Play Store can now automatically prompt users to update your app after a user visible crash.


What you need to do: nothing!

These new prompts don’t require any integration by you and are enabled automatically when Play determines that a newer version of your app has a statistically relevant, lower crash rate. Furthermore, since the dialog is shown by the Play Store and not your app, the update prompt can be shown even if your app crashes on startup.

Data driven improvement over time

There are a few thresholds we take into account, which we will tune over time to achieve the best outcome. These include:

  1. User activity level of an app version according to Vitals to ensure we have statistical relevance
  2. Foreground crash rate of an app version and of its newer version
  3. Number of times a prompt can be shown for each version of your app on a device, if the user doesn’t choose to update

We believe that this new feature will help your users update to the best available version of your app, and help you deliver the best experience to your users.



Google Play Logo

Improving user privacy by requiring opt-in to send X-Requested-With header from WebView

Posted by Peter Birk Pakkenberg, Software Engineer

X-Requested-With (XRW) is a nonstandard header.

When a user installs and runs an application that uses a WebView to embed web content, the WebView will add the X-Requested-With header on every request sent to servers, with a value of the application APK name. It is then left to the receiving web server to determine if and how to use this information.

We want to protect the user's privacy by only sending this header on requests if the app developer explicitly opts-in to share with services embedded within the WebView. We are introducing new and purpose-built methods of client attestation that solve important safety use cases in a privacy-sensitive manner.

To let current online services that depend on this header migrate away from using it, we will run a Deprecation Origin Trial, while removing the header for general traffic.

Why are we making this change?

In early use cases, the X-Requested-With header was used to detect click fraud from malicious apps. It was also used to let a server know it's interacting with AJAX requests and needn't reply with HTML. The header was quickly adopted by common frameworks (jQuery, Dojo, Django) as a defense against CSRF attacks. However, several vulnerabilities (such as browser extensions impersonating websites) appeared around its use.

Android WebView adopted the X-Requested-Header with the application name as the value, as a way to allow online services to detect deceptive apps that were using hidden webviews to generate fake traffic. While this problem still exists today, the header as it is currently implemented does not fully solve the problem, as apps can easily change the value being sent on some requests in later Android versions.

The header, as currently implemented by default in Android WebView, does not follow the principle of meaningful consent of all parties exchanging the information and the Android Platform Security Model’s definition of multi-party consent.

APK name also contains specific information about the context in which the user is consuming the web content, and can leak the identity of the app to the online service.

How does this proposal affect the header?

It's important to note that the non-WebView use cases will not change because of this proposal, as clients and servers still can and will set the header in normal JavaScript environments.

Even today, WebView will not overwrite the header if the header has already been set on an AJAX request by a JavaScript framework.

This removal only targets the WebView use case, which adds the header to every HTTP request made by the browser (that is, not the XMLHttpRequest use case).

What is the impact of removing this feature?

Today content owners may decide to rely on X-Requested-With to attribute traffic and control access without employing their own authentication. Other services use it for reporting of aggregate patterns about their user base.

All of these use cases will be affected by the removal of the header on requests, and in the majority of cases where the header is not modified by dishonest apps, it provides useful information to online services.

Given this, we plan to limit disruption during the deprecation and transition to purpose-built replacement signals by offering a Deprecation Origin Trial to maintain the existing behavior.

We ask for feedback on existing use cases that currently rely on and may be impacted by these changes.

Next steps and the future of XRW

As we gradually roll out the removal, origins participating in the trial will be exempted (that is, WebView will continue to send the header to these origins for as long as the trial lasts). The deprecation trial is expected to remain active for at least a year to give partners time to adjust for the change.

Further, during the deprecation origin trial, we will be developing new privacy-preserving APIs to match the use cases where the XRW header is being used today, such as client attestation APIs.

Separately from the deprecation trial, we will provide an opt-in API for application developers. This API will allow individual apps to selectively send the header to chosen origins, which can be used to maintain functionality of legacy sites that are not migrating, and the API will remain after the deprecation trial has finished.

Helpful resources

Key areas where we are seeking feedback

  • Key use cases for the XRW header today (e.g., payment authentication, account takeover fraud)
  • How important the XRW header is for each of these use cases
  • Desired capabilities that any new privacy-preserving alternatives would ideally have

Announcing Cross device SDK Developer Preview for building rich multi-device experiences on Android

Posted by Alex Rocha - Developer Relations Engineer Manager, Ryan Ausanka-Crues - Eng Manager, Multi-device development, Stella Loh - Product Manager, Multi-device development

Today we’re launching our Developer Preview of the new Cross device SDK for Android. First announced during the Google I/O ‘22 Multi-device development session, our Cross device SDK allows developers to build rich multi-device experiences with a simple and intuitive set of APIs. This SDK abstracts away the intricacies involved with working with device discovery, authentication, and connection protocols, allowing you to focus on what matters most—building delightful user experiences and connecting these experiences across a variety of form factors and platforms.

What’s in Developer Preview

This initial release contains a set of rich APIs centered around the core functionality of Device discovery, Secure connections, and Multi-device Sessions.

  1. Device discovery: Easily find nearby devices, authorize peer-to-peer communication, and start the target application on receiving devices.
  2. Secure connections: Enable encrypted, low-latency bi-directional data sharing between authorized devices.
  3. Multi-device Sessions: Enable transferring or extending an application’s user experience across multiple devices.

In turn, this will allow you to build compelling cross-device experiences by enabling and simplifying the following use cases:

  • Discovering and authorizing communication with nearby devices.
  • Sharing an app’s current state with the same app on another device.
  • Starting the app on a secondary device without having to keep the app running in background.
  • Establishing secure connections for devices to communicate with each other.
  • Enabling task handoff where the user starts a task on one device, and can easily continue on another device.

Starting today with a Developer Preview for Android phones and tablets, the Cross device SDK will be available later for other Android surfaces and non-Android OSs.

Under The Hood

The Cross device SDK provides a software abstraction layer that handles all aspects of cross-device connectivity, leveraging wireless technologies such as Bluetooth, Wi-Fi, and Ultra-wide band; our SDK does all the heavy-lifting under the hood, offering you a modular,connectivity-agnostic API that supports bi-directional communication between devices and is backward compatible to Android 8. In addition, apps will not have to declare or request Runtime Permissions for any of the underlying connectivity protocols used (such as BLUETOOTH_CONNECT, BLUETOOTH_SCAN, ACCESS_FINE_LOCATION, etc.), and the user can allow apps to connect to only the device(s) they selected.

Getting started with Developer Preview

Head over to our developer guide to get started and try out the Developer Preview of the Cross device SDK for Android. Make sure to check out our Rock Paper Scissor sample app (Kotlin and Java) on GitHub for a demonstration on how to work with the various APIs and our Google I/O ‘22 Multi-device development session for a general overview of the SDK.

Feedback

We’d love to hear from you during this initial Developer Preview launch to help us shape the SDK and influence future roadmapping, so please share your feedback and let us know your experience with the SDK!

Now in Android – a new, open source, real-world sample app

Posted by Paris Hsu, Product & Design, Android and Don Turner, Developer Relations Engineer, Android

Now in Android Splash logo

The Now in Android app is now on GitHub!

For two years, 'Now in Android' has been a popular blog and YouTube series, providing you with the latest and greatest developer news from the Android team. Starting today, you can check out the alpha version of the Now in Android app on GitHub! ?

The app has two goals:

Firstly, it showcases best practices, opinionated designs, and solutions to complex real-world problems which other sample apps don’t handle. It does so with an open source implementation of a real world app.

Secondly, it helps you (the developer) keep up to date with the areas of Android development which interest you most. It is a working app planned for publication on the Play Store.

image of Now in Android app screen designs on three phones

Now in Android app screen designs

For this first alpha release, the Now in Android app includes:

As well as these features, we are also documenting the learning journeys we took to certain decisions with the app's design and implementation. Check out our first journey on the app's Architecture here.

image showing how the Now in Android app adapts based on device screen size

The Now in Android screens adapt based on device screen size

Since this is an alpha release, we expect that there will be bugs and missing features, and we would greatly appreciate your feedback. We have some exciting features planned, such as user authentication and loading data from a real backend. We can’t wait for you to check out the app and let us know what you think!

Finally, if you want to learn about the tools we used to build the app and how we target multiple screen sizes, check out these talks from this year's Google I/O:

Improving App Performance with Baseline Profiles

Or how to improve startup time by up to 40%

Posted by Kateryna Semenova, DevRel Engineer; Rahul Ravikumar, Software Engineer; Chris Craik, Software Engineer

ALT TEXT GOES HERE


Why is startup time important?

A lot of apps find correlation between app performance and user engagement. People expect apps to be responsive and fast to load. Startup time is one of the major metrics for app performance and quality.

Some of our partners have already invested a lot of time and resources for app startup optimizations. For example, check out the Facebook story.

In this blog post we’ll discuss Baseline Profiles and how they improve app and library performance, including startup time by up to 40%. While this blogpost focuses on startup, baseline profiles also significantly improve jank as well.


History

Android 9 (API level 28) introduced ART optimizing profiles in Play Cloud to improve app startup time. On average, we’ve seen that apps' cold starts are at least 15% faster across a variety of devices when Cloud Profiles are available.


How do Profiles work?

When the app is first launched after install or update, its code runs in an interpreted mode until it is JITted. In an APK, Java and Kotlin code is compiled as dex bytecode, but not fully compiled to machine code (since Android 6), due to the cost of storing and loading fully compiled apps. Classes and methods that are frequently used in the app, as well as those used for app startup, are recorded into a profile file. Once the device enters idle mode, ART compiles the apps based on these profiles. This speeds up subsequent app launches.

Starting with Android 9 (API level 28), Google Play also provides Cloud Profiles. When an app runs on a device, the profiles generated by ART are uploaded by the Play Store app and aggregated in the cloud. Once there are enough profiles uploaded for an application, the Play app uses the aggregated profile for subsequent installs.


Problem

While Cloud Profiles are great when they are available, they aren't always ready to be used when an app is installed. Collecting and aggregating the profiles usually takes several days, which is a problem when many apps update on a weekly basis. Many users will install an update before the Cloud Profile is available. The Google Android team started looking for other ways to improve the latency of profiles.


Solution

Baseline Profiles are a new mechanism to provide profiles which can be used on Android 7 (API level 24) and higher. A baseline profile is an ART profile generated by the Android Gradle plugin using a human readable profile format that can be provided by apps and libraries. An example might look like this: 

HSPLandroidx/compose/runtime/ComposerImpl;->updateValue(Ljava/lang/Object;)V
HSPLandroidx/compose/runtime/ComposerImpl;->updatedNodeCount(I)I
HLandroidx/compose/runtime/ComposerImpl;->validateNodeExpected()V
PLandroidx/compose/runtime/CompositionImpl;->applyChanges()V
HLandroidx/compose/runtime/ComposerKt;->findLocation(Ljava/util/List;I)I

Example for Compose library.


The binary profile is stored in a specific location in the APK assets directory (assets/dexopt/baseline.prof).

Baseline Profiles are created during build time, shipped as part of the APK to Play, and then sent from Play to users when an app is downloaded. They fill the gap in the ART Cloud Profile pipeline, when Cloud Profiles are not yet available, and automatically merge with Cloud Profiles when they are.


This diagram displays the baseline profile workflow from creation through end-user delivery.

This diagram displays the baseline profile workflow from creation through end-user delivery.


One of the biggest benefits of Baseline Profiles is that they can be developed and evaluated locally so developers can see realistic end-user performance improvements. They are also supported on a lower version of Android(7 and higher) than Cloud Profiles, which are only available starting in Android 9.


Impact


App devs

In early 2021, Google Maps switched from a two-week to a one-week release cycle. More frequent updates meant more frequently discarding local pre-compilation, and more users experiencing slow launches without Play Cloud Profiles. By using Baseline Profiles, Google Maps improved their average startup time by 30% and saw a corresponding increase in searches by 2.4%, an immense gain for such an established app.


Library devs

Code in a library is just like that of an app - it's not fully compiled by default, which can be a problem if it does significant work on the critical path of startup.

Jetpack Compose is a UI library that is not a part of the Android system image and thus not fully compiled when installed, unlike much of the Android View toolkit code. This was causing performance problems, especially for the first few cold launches of the app.

To solve this problem, Compose uses profile installer. It ships baseline profile rules which reduce startup time and jank in Compose apps.

Google PlayStore’s search results page has been re-written with Compose. After incorporating the Baseline Profile rules from Compose, time to render the initial search results page with images improved by ~40%.

The Android team has also added Baseline Profiles to relevant AndroidX libraries. This benefits all Android apps using these libraries. Constraint Layout has found shipping profile rules reduces animation frame times by more than one millisecond.


How to use Baseline Profiles


Create a custom Baseline Profile

All apps and library developers can benefit from including Baseline Profiles. Ideally, developers create profiles for their most critical user journeys to ensure that those journeys have consistently fast performance regardless of whether cloud profiles are available. Check out the detailed guide on how to set up Baseline Profiles for both app and library developers.


Update dependencies

If you are not ready to generate Baseline Profiles for your app right now, you can still benefit from them by updating your dependencies. If you build with Android Gradle Plugin 7.1.0-alpha05 or newer, you'll get Baseline Profiles included in your APK that are already provided by libraries (such as Jetpack). Google Play compiles your app with these profiles at install time. You can supplement these profiles as part of building your application.


Measure Improvements

Don’t forget to measure improvements. Follow the steps on how to measure startup with the generated profile locally.


Provide feedback

Please share your feedback and let us know your experience!

Low-Power Sleep Tracking on Android

Posted by Nick Grayson, Product Manager

Illustration of phone with moon and Android logo on screen

Android works best when it helps developers create apps that people love. That’s why we are dedicated to providing useful APIs like Activity Recognition which, with the user’s permission, can detect user’s activities (such as whether a user is biking or walking) to help apps provide contextually aware experiences.

So much of what we do relies on a good night's rest. Our phones have become great tools for making more informed decisions about our sleep. And by being informed about sleep habits, people can make better decisions throughout the day about sleep, which affects things like concentration and mental health.

In an effort to help our users stay informed about their sleep, we are making our Sleep API publicly available.

What is the Sleep API?

The Sleep API is an Android Activity Recognition API that surfaces information about the user’s sleep. It can be used to power features like the Bedtime mode in Clock.

This sleeping information is reported in two ways:

  1. A ‘sleep confidence’, which is reported at a regular interval (up to 10 minutes)
  2. A daily sleep segment which is reported after a wakeup is detected

The API uses an on-device artificial intelligence model that uses the device’s light and motion sensors as inputs.

As with all of our Activity Recognition APIs, the app must be granted the Physical Activity Recognition runtime permission from the user to detect sleep.

Why is this important for developers?

Developers spend valuable engineering time to combine sensor signals to determine when the user has started or ended activities like sleep. These detection algorithms are inconsistent between apps and when multiple apps independently and continuously check for changes in user activity, battery life suffers.

The Sleep API is a simple API that centralizes sleep detection processing in a battery-efficient manner. For this launch, we are proud to collaborate with Urbandroid, the developer of the popular alarm app, Sleep As Android

Android logo sleeping
Sleep as Android is a swiss army knife for getting a better night’s rest. It tracks sleep duration, regularity, phases, snoring, and more. Sleep Duration is one of the most important parameters to watch for ensuring a good night’s rest. The new Sleep API gives us a fantastic opportunity to track it automatically in the most battery efficient way imaginable.

- Sleep as Android Team



When can I start using this API?

The Sleep API is available for developers to use now as part of the latest version of Google Play Services.

This API is one step of our efforts to help our users get a better night's rest. We look forward to working more on this API and in this area in the future.

If you are interested in exploring or using this API, check out our API Documentation.

Learn Android and Kotlin with no programming experience

Posted by Kat Kuan, Developer Advocate, Android

Many people today are considering career paths that enable them to work remotely. App development allows for that style of work. For people who want a new opportunity, it’s possible to start learning Android today, even without prior programming experience.

In 2016, we released our Android Basics curriculum, which assumes no programming experience, and the response has been tremendous. Hundreds of thousands of students have been learning Android development and programming concepts simultaneously as they build apps. Since then, there have been big platform changes with four major releases of Android and support added for the Kotlin programming language. We also introduced Jetpack, a suite of libraries that make it easier to build better apps with less code. With all these new updates, it’s time to release the next generation of training content for beginners.

Today we’re announcing the launch of Android Basics in Kotlin, a new online course for people without programming experience to learn how to build Android apps. The course teaches Kotlin, a modern programming language that developers love because of its conciseness and how it increases productivity. Kotlin is quickly gaining momentum in industry. Over a single year from 2018 - 2019, Indeed Hiring Lab found a 76% increase in Kotlin jobs.*

Google announced that Android development is Kotlin-first, and 60% of professional Android developers have already adopted the language. In the Play Store, 70% of the top 1,000 apps use Kotlin. To keep pace and prepare for the future, there has never been a more opportune time to learn Android with Kotlin.

Learning to code for the first time can feel intimidating, but it is possible to learn without a technical background. From a recent Stack Overflow Developer Survey, nearly 40% of the professional developers who studied at university did not receive a formal computer science or software engineering degree.

To build your confidence, the Android Basics in Kotlin course offers step-by-step instructions on how to use Android Studio to build apps, as well as how to run them on an Android device (or virtual device). The goal is to expose you to the tools and resources that professional Android developers use. With hands-on practice, you learn the fundamentals of programming. By the end of the course, you will have completed a collection of Android apps to start building a portfolio.

Object detection & tracking gif Text recognition + Language ID + Translate gif

App screenshots from the course

This course is split up into units, where each unit is made up of a series of pathways. At the end of each pathway, there is a quiz to assess what you’ve learned so far. If you pass the quiz, you earn a badge that can be saved to your Google Developer Profile.
Object detection & tracking gif Text recognition + Language ID + Translate gif

Badges you can earn

The course is free for anyone to take. Basic computer literacy and basic math skills are recommended prerequisites. Unit 1 of the course is available today, with more units being released as they become available. If you’ve never built an app before but want to learn how, check out the Android Basics in Kotlin course.

If you already have programming experience, check out the other free training courses we offer in Kotlin:

We can’t wait to see what you build!

*from US tech job postings on Indeed.com