Nov 18

Take your apps on the road with Android Auto

Posted by Wayne Piekarski, Developer Advocate

Starting today, anyone can take their apps for a drive with Android Auto using Android 5.0+ devices, connected to compatible cars and aftermarket head units. Android Auto lets you easily extend your apps to the car in an efficient way for drivers, allowing them to stay connected while still keeping their hands on the wheel and their eyes on the road. When users connect their phone to a compatible vehicle, they will see an Android experience optimized for the head unit display that seamlessly integrates voice input, touch screen controls, and steering wheel buttons. Moreover, Android Auto provides consistent UX guidelines to ensure that developers are able to create great experiences across many diverse manufacturers and vehicle models, with a single application available on Google Play.

With the availability of the Pioneer AVIC-8100NEX, AVIC-7100NEX, and AVH-4100NEX aftermarket systems in the US, the AVIC-F77DAB, AVIC-F70DAB, AVH-X8700BT in the UK, and in Australia the AVIC-F70DAB, AVH-X8750BT, it is now possible to add Android Auto to many cars already on the road. As a developer, you now have a way to test your apps in a realistic environment. These are just the first Android Auto devices to launch, and vehicles from major auto manufacturers with integrated Android Auto support are coming soon.

With the increasing adoption of Android Auto by manufacturers, your users are going to be expecting more support of their apps in the car, so now is a good time to get started with development. If you are new to Android Auto, check out our DevByte video, which explains more about how this works, along with some live demos.

The SDK for Android Auto was made available to developers a few months ago, and now Google Play is ready to accept your application updates. Your existing apps can take advantage of all these cool new Android Auto features with just a few small changes. You’ll need to add Android Auto support to your application, and then agree to the Android Auto terms in the Pricing & Distribution category in the Google Play Developer Console. Once the application is approved, it will be made available as an update to your users, and shown in the cars’ display.

Adding support for Android Auto is easy. We have created an extensive set of documentation to help you add support for messaging (sample), and audio playback (sample). There are also short introduction DevByte videos for messaging and audio as well. Stay tuned for a series of posts coming up soon discussing more details of these APIs and how to work with them. We also have simulators to help you test your applications right at your desk during development.

With the launch of Android Auto, a new set of possibilities are available for you to make even more amazing experiences for your users, providing them the right information for the road ahead. Come join the discussion about Android Auto on Google+ at http://g.co/androidautodev where you can share ideas and ask questions with other developers.

Join the discussion on

+Android Developers


Android Developers Blog

Nov 18

Android Things Contest Winners







Posted by Dave Smith,
Developer Advocate for IoT

Back in September, we worked
with Hackster.io to encourage the developer community to build smart
connected devices using Android Things and post their projects to the Developer Challenge for Android
Things. The goal was to showcase the combination of turnkey hardware and a
powerful SDK for building and maintaining devices at scale.

Thank you to everyone who participated in the contest and submitted a project or
idea. We had over 1100 participants register for the contest, resulting in over
350 submissions. Out of that group, we’ve chosen three winners. Each winner will
receive support and tools from Dragon Innovation to develop their
concepts into commercial products. Join us in congratulating the following
makers!

Best Enterprise Project: Distributed
Air Quality Monitoring

Maker: James
Puderer

Monitor air quality on a street-by-street level using Android Things, Google
Cloud IoT Core, and taxis!

This project showcases how Android Things makes it easy to build devices that
integrate with the various services provided by the Google Cloud Platform for
robust data collection and analysis. It’s a clever end-to-end solution that
shows understanding of both the problem domain as well as the technology.

Best Start Up Project: BrewCentral

Maker: Trent Shumay and Steven Pridie

Brewing amazing beer is a balance of art, science, and ritual. The
BrewCentral system makes it possible for anyone to do an all-grain brew!

BrewCentral pairs a real-time PID controller with the touch-enabled UI and
decision-making compute power of Android Things. The result is a system that
accurately controls the time, temperature, and flow rates necessary to achieve
repeatable results during a brew cycle. The planned enhancements for cloud-based
brewing recipes will make this a connected experience for the entire brewing
community.

Best IoT Project: BrailleBox
- Braille News Reader

Maker: Joe Birch

BrailleBox is a small piece of hardware that empowers users who are
hard-of-sight to read the latest news articles in Braille.

This project is a great use case of using IoT to have a social impact. The
current proof of concept streams articles from a news feed to the Braille pad,
but this project has the potential to leverage machine learning on the device to
translate additional input from the physical world into a Braille result.

Honorable Mentions

The community submitted some amazing projects for the contest, which made the
choice of picking only three winners extremely difficult. Here are a few of our
favorite projects that weren’t selected for a prize:

  • Andro
    Cart: A shopping cart device powered by Android Things. Designed to help
    decentralize point of sale (POS) billing.

  • SIGHT:
    For the Blind: A pair of smart glasses for the blind, powered by Android
    Things and TensorFlow.

  • Industrial
    IoT Gateway: A smart industrial gateway for the IoT world based on Android
    Things.

  • Sentinel: The
    first semi-autonomous home security robot based on Android Things.

  • Word
    Clock: A creative take on reading the time, powered by Android Things.
    Control it via the Nearby API or the Google Assistant.

We encourage everyone to check out all the new projects in the Google
Hackster community, and submit your own as well! You can also join Google’s IoT Developers Community on Google+, a
great resource to get updates, ask questions, and discuss ideas. We look forward
to seeing what exciting projects you build!


Android Developers Blog

Nov 17

Android Developer Story: Outfit7 — Building an entertainment company with Google

Posted by Leticia Lago, Google Play team

Outfit7, creators of My Talking Tom and My Talking Angela, recently announced they’ve achieved 2.5 billion app downloads across their portfolio. The company now offers a complete entertainment experience to users spanning mobile apps, user generated and original YouTube content, and a range of toys, clothing, and accessories. They even have a silver screen project underway.

We caught up with Iza Login, Rok Zorko and Marko Štamcar – some of the co-founders- in Ljubljana, Slovenia, to learn best practices that helped them in reaching this milestone.

To learn about some of the Google and Google Play features used by Outfit7 to create their successful business, check out these resources:

  • Monetization — explore the options available for generating revenue from your apps and games.
  • Monetization with AdMob — learn how you can maximize your ad revenue.
  • YouTube for Developers — Whether you’re building a business on YouTube or want to enhance your app with video, a rich set of YouTube APIs can bring your products to life.
Join the discussion on

+Android Developers


Android Developers Blog

Nov 17

Getting your Android app ready for Autofill







Posted by Wojtek Kalicinski, Android Developer Advocate, Akshay Kannan,
Product Manager for Android Authentication, and Felipe Leme, Software Engineer on Android Frameworks

Starting in Oreo, Autofill makes it easy for users to provide credit cards,
logins, addresses, and other information to apps. Forms in your apps can now be
filled automatically, and your users no longer have to remember complicated
passwords or type the same bits of information more than once.

Users can choose from multiple Autofill services (similar to keyboards today).
By default, we include Autofill with Google, but users can also select any third
party Autofill app of their choice. Users can manage this from
Settings->System->Languages>Advanced->Autofill service.

What’s available today

Today, Autofill with Google supports filing credit cards, addresses, logins,
names, and phone numbers. When logging in or creating an account for the first
time, Autofill also allows users to save the new credentials to their account.
If you use WebViews in your app, which many apps do for logins and other
screens, your users can now also benefit from Autofill support, as long as they
have Chrome 61 or later installed.

The Autofill API is open for anyone to implement a service. We are actively
working with 1Password,
Dashlane,
Keeper,
and LastPass
to help them with their implementations towards becoming certified on Android.
We will be certifying password managers and adding them to a curated section in
the Play Store, which the “Add service” button in settings will link to. If you
are a password manager and would like to be certified, please get
in touch.

What you need to do as a developer

As an app developer, there are a few simple things you can do to take advantage
of this new functionality and make sure that it works in your apps:

Test your app and annotate your views if needed

In many cases, Autofill may work in your app without any effort. But to ensure
consistent behavior, we recommend providing explicit hints to tell the framework
about the contents of your field. You can do this using either the android:autofillHints
attribute or the setAutofillHints()
method.

Similarly, with WebViews in your apps, you can use HTML Autocomplete
Attributes to provide hints about fields. Autofill will work in WebViews as
long as you have Chrome 61 or later installed on your device. Even if your app
is using custom views, you can also define
the metadata that allows autofill to work.

For views where Autofill does not make sense, such as a Captcha or a message
compose box, you can explicitly mark the view as IMPORTANT_FOR_AUTOFILL_NO
(or IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS
in the root of a view hierarchy). Use this field responsibly, and remember that
users can always bypass this by long pressing an EditText and selecting
“Autofill” in the overflow menu.

Affiliate your website and mobile app

Autofill with Google can seamlessly share logins across websites and mobile apps
‒ passwords saved through Chrome can also be provided to native apps. But in
order for this to work, as an app developer, you must explicitly declare the
association between your website with your mobile app. This involves 2 steps:

Step 1: Host a JSON file at
yourdomain.com/.well-known/assetlinks.json

If you’ve used technologies like App Links or Google Smart Lock before, you
might have heard about the Digital Asset Links (DAL) file. It’s a JSON file
placed under a well known location in your website that lets you make public,
verifiable statements about other apps or websites.

You should follow the Smart
Lock for Passwords guide for information about how to create and host the
DAL file correctly on your server. Even though Smart Lock is a more advanced way
of signing users into your app, our Autofill service uses the same
infrastructure to verify app-website associations. What’s more, because DAL
files are public, third-party Autofill service developers can also use the
association information to secure their implementations.

Step 2: Update your App’s Manifest with the same
information

Once again, follow the Smart
Lock for Passwords guide to do this, under “Declare the association in the
Android app.”

You’ll need to update your app’s manifest file with an asset_statements
resource, which links to the URL where your assetlinks.json file is hosted. Once
that’s done, you’ll need to submit your updated app to the Play Store, and fill
out the Affiliation
Submission Form for the association to go live.

When using Android Studio 3.0, the App Links Assistant can generate all of this
for you. When you open the DAL generator tool (Tools -> App Links Assistant ->
Open Digital Asset Links File Generator), simply make sure you enable the new
checkbox labeled “Support sharing credentials between the app and website”.

Then, click on “Generate Digital Asset Links file”, and copy the preview content
to the DAL file hosted on your server and in your app. Please remember to verify
that the selected domain names and certificates are correct.

Future work

It’s still very early days for Autofill in Android. We are continuing to make
some major investments going forward to improve the experience, whether you use
Autofill with Google or a third party password manager.

Some of our key areas of investment include:

  1. Autofill with Google: We want to provide a great experience
    out of the box, so we include Autofill with Google with all Oreo devices. We’re
    constantly improving our field detection and data quality, as well as expanding
    our support for saving more types of data.

  2. WebView support: We introduced initial support for filling
    WebViews in Chrome 61, and we’ll be continuing to test, harden, and make
    improvements to this integration over time, so if your app uses WebViews you’ll
    still be able to benefit from this functionality.

  3. Third party app support: We are working with the ecosystem
    to make sure that apps work as intended with the Autofill framework. We urge you
    as developers to give your app a spin on Android Oreo and make sure that things
    work as expected with Autofill enabled. For more info, see our full
    documentation on the Autofill
    Framework.

If you encounter any issues or have any suggestions for how we can make this
better for you, please send
us feedback.


Android Developers Blog

Nov 11

Haystack TV Doubles Engagement with Android TV

Posted by Joshua Gordon, Developer Advocate

Haystack TV is a small six person startup with an ambitious goal: personalize the news. Traditionally, watching news on TV means viewing a list of stories curated by the network. Wouldn’t it be better if you could watch a personalized news channel, based on interesting YouTube stories?

Haystack already had a mobile app, but entering the living room space seemed daunting. Although “Smart TVs” have been on the market for a while, they remain challenging for developers to work with. Many hardware OEMs have proprietary platforms, but Android TV is different. It’s an open ecosystem with great developer resources. Developers can reach millions of users with familiar Android APIs. If you have an existing Android app, it’s easy to bring it to the living room.

Two weeks was all it took for Haystack TV to bring their mobile app to Android TV. That includes building an immersive, cinematic UI (a task greatly simplified by the Android framework). Since launching on Android TV, Haystack TV’s viewership is growing at 40% per month. Previously, users were spending about 40 minutes watching content on mobile per week. Now that’s up to 80 minutes in the living room. Their longest engagements are through Chromecast and Android TV.

Hear from Daniel Barreto, CEO of Haystack TV, on developing for Android TV

Haystack TV’s success on Android TV is a great example of how the Android multi-form factor developer experience shines. Once you’ve learned the ropes of writing Android apps, developing for another form factor (Wear, Auto, TV) is simple.

Android TV helps you create cinematic UIs

Haystack TV’s UI is smooth and cinematic. How were they able to build a great one so quickly? Developing an immersive UI/UX with Android TV is surprisingly easy. The Leanback support library provides fragments for browsing content, showing a details screen, and search. You can use these to get transitions and animations almost for free. To learn more about building UIs for Android TV, watch the Using the Leanback Library DevByte and check out the code samples.

Browsing recommended stories

Your content, front and center

The recommendations row is a central feature of the Android TV home screen. It’s the first thing users see when they turn on their TVs. You can surface content to appear on the recommendations row by implementing the recommendation service. For example, your app can suggest videos your users will want to watch next (say, the next episode in a series, or a related news story). This is great for getting noticed and increasing engagements.

Haystack’s content on the recommendations row

Make your content searchable

How can users find their favorite movie or show from a library of thousands? On Android TV, they can search for it using their voice. This is much faster and more relaxing than typing on the screen with a remote control! In addition to providing in-app search, your app can surface content to appear on the global search results page. The framework takes care of speech recognition for you and delivers the result to your app as a plain text string.

Next Steps

Android TV makes it possible for small startups to create apps for the living room. There are extensive developer resources. For an overview, watch the Introduction to Android TV DevByte. For details, see the developer training docs. Watch this episode of Coffee with a Googler to learn more about the vision for the platform. To get started on your app, visit developer.android.com/tv.

Join the discussion on

+Android Developers


Android Developers Blog

Nov 09

Android Studio 2.1 supports Android N Developer Preview

Posted by Jamal Eason, Product Manager, Android

With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.

Android Studio 2.1 includes the following new features:

  • N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.
  • Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.

Deeper Dive into the New Features

N Developer Preview

On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.

Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.

N Developer Preview on the new Android Emulator

Instant Run & General Build Performance Improvements

Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.

In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.

We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.

We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.

What’s Next

Update

If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.

Test and Validate Apps with N Developer Preview

After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.

We appreciate any feedback on things you like, issues or features you would like to see. Connect with us — the Android Studio development team — on our Google+ page or on Twitter.


Android Developers Blog

Nov 07

Protecting against unintentional regressions to cleartext traffic in your Android apps

Posted by Alex Klyubin, Android Security team

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.

New protection mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com.
HTTPS, Android-Security


Android Developers Blog

Nov 06

An Outsourcing Playbook for Android development

Posted by Rupert Whitehead, Developer Relations

We recently updated The Secrets to App Success on Google Play with tools and tips to help app and game developers grow successful businesses on Google Play. However, many great apps are created by agencies and freelancers on behalf of companies. Today, we’re releasing a new playbook to help companies of any size who are considering outsourcing their Android app development.

How do you choose an agency? What are the pitfalls you should avoid? What can you do to make your app successful? These are some of the questions tackled by the new Outsourcing Playbook that you can read on Google Play.

Let us know your feedback

Once you’ve checked out the guide, we’d love to hear your feedback so we can continue to improve our developer resources and support. Let us know what you think.


Android Developers Blog

Nov 04

Android 5.1 Lollipop SDK

style="border-radius: 6px;padding:0;margin:0;" />

By Jamal Eason, Product Manager, Android

Yesterday we announced Android 5.1, an updated version of the Android Lollipop platform that improves stability, provides better control of notifications, and increases performance. As a part of the Lollipop update, we are releasing the Android 5.1 SDK (API Level 22) which supports the new platform and lets you get started with developing and testing.

What’s new in Android 5.1?

For developers, Android 5.1 introduces a small set of new APIs. A key API addition is support for multiple SIM cards, which is important for many regions where Android One phones are being adopted. Consumers of Android One devices will have more flexibility to switch between carriers and manage their network activities in the way that works best for them. Therefore you, as a developer, can create new app experiences that take advantage of this new feature.

In addition to the new consumer features, Android 5.1 also enhances enterprise features to better support the launch of Android for Work.


Android 5.1 supports multiple SIM cards on compatible devices like Android One.

Updates for the Android SDK

To get you started with Android 5.1, we have updated the Android SDK tools to support the new platform and its new APIs. The SDK now includes Android 5.1 emulator system images that you can use to test your apps and develop using the latest capabilities and APIs. You can update your SDK through the Android SDK Manager in Android Studio.

For details on the new developer APIs, take a look at the API Overview.

Coming to Nexus devices soon

Over the next few weeks, we’ll be rolling out updates for Android 5.1 to the following Nexus devices: Nexus 4, Nexus 5, Nexus 6, Nexus 7 [2012], Nexus 7 [2012] (3G), Nexus 7 (2013), Nexus 7 [2013] (3G/LTE), Nexus 9, Nexus 9 (LTE), Nexus 10, and Nexus Player.

Next Steps

As with all Android releases, it’s a good idea to test your apps on the new platform as soon as possible. You can get started today using Android 5.1 system images with the emulator that’s included in the SDK, or you can download an Android 5.1 Nexus image and flash the system image to your Nexus device.

If you have not had a chance to update your app to material design, or explore how your app might work on Android Wear, Android TV, or even Android Auto, now is a good time to get started with the Android 5.1 SDK update.

Join the discussion on

+Android Developers


Android Developers Blog

Nov 03

Update on Kotlin for Android

Posted by James Lau, Product Manager (twitter.com/jmslau)

Today is the beginning of KotlinConf.
It’s been almost 6 months since we announced Kotlin as a first-class language
for Android at Google I/O. During this period, the number of apps on Google Play
using Kotlin has more than doubled. More than 17% of the projects in Android
Studio 3.0 are now using Kotlin. We are really excited about the strong
momentum, and we are thrilled that Android developers all over the world are
discovering the joy of Kotlin programming.

Kotlin for Android is production-ready. From startups to Fortune 500 companies,
developers are already using Kotlin to build their apps. Developers from
Pinterest, to Expedia, to Basecamp — and many others — are finding their use
of Kotlin is increasing productivity and their overall developer happiness
levels. Take a look at some of their experiences with Kotlin below.

With the recent release of Android Studio 3.0,
there is now a stable version of our IDE that has Kotlin support built-in. With
Support
Library 27, we have started adding nullability annotations to make the APIs
friendlier to use in Kotlin. We recently published the Android Kotlin Guides on
GitHub to provide some guidance for Android Kotlin style and interop. We
have also been porting some of our Android
samples to Kotlin, and we are adding Kotlin to our official documentation.

Android Studio 3.0

Last week, we released
Android Studio 3.0 on the stable channel. This is the first stable release
of Android Studio that has Kotlin support built-in. Building on the strength of
IntelliJ’s Kotlin support, many critical IDE features like code completion and
syntax highlighting work well for Kotlin. You can choose to convert Java code to
Kotlin by using CodeConvert Java File to Kotlin
File
, or you can convert snippets of code just by pasting Java code
into a Kotlin file.

Project and code templates have also been updated with Kotlin support. When you
create a new project or add a new code file, you can choose Kotlin as one of the
language options.

The tooling experience with Kotlin is by no means perfect yet. We are aware of
several known
issues, and we will continue to improve the IDE support for Kotlin in future
releases.

Android Kotlin Guides

There are two separate Android Kotlin Guides:

  1. Style guide
    - details a set of rules and coding standards that Google recommends when
    writing Kotlin for Android. The guide addresses naming conventions, formatting,
    structure of the source contents, and much more.
  2. Interop
    guide – provides a set of rules for creating APIs in the Java and Kotlin
    programming languages, so that the consuming code in the other language will
    feel idiomatic.

We intend these guides to be living documents and will evolve them over time.
They are hosted on GitHub and we welcome your contributions.

Nullability Annotations

Null-safety is an important feature of the Kotlin language. It helps developers
avoid NullPointerExceptions and improves the quality of their apps. Null-safety
is a bit more complicated when using Java code from Kotlin. Since any reference
in Java may be null, Kotlin’s requirement for strict null-safety becomes
impractical for Java objects. Types declared in Java that do not contain
nullability annotations are called platform types – this means the Kotlin
compiler does not know whether it is nullable or not. When calling methods with
variables of platform types, the Kotlin compiler relaxes null-safety checks.
That means the overall null-safety of your app is weakened.

To let developers take more advantage of Kotlin’s strict null-safety, we have
started adding nullability annotations in Support
Library 27. The Support Library contains a huge API surface area, and we
will continue to expand the nullability annotation coverage in the next several
releases. In addition, we will also be adding nullability annotations to other
Android APIs over time.

While the Kotlin adoption growth is fantastic, our commitment to the Java and
C++ programming languages remains unchanged. We’ve added Java 8
language features support in Android Studio 3.0, and we’ve added more Java
8 language APIs in Android Oreo. We are also continuing to improve our
support for C++17 in the NDK. So even if you are not using Kotlin, your language
support will continue to improve.

It’s an exciting time to be an Android developer. If you haven’t had a chance to
try Kotlin, you can get started by learning the basic syntax
and by playing with the excellent Kotlin
Koans. When you are ready to use Kotlin in your Android app, you can jump to
the Android Kotlin page for
more resources. With Kotlin’s Java interoperability and Android Studio’s Java to
Kotlin converter, it’s easy to start using Kotlin in your project.

Happy Kotlin-ing!


Android Developers Blog