Solve for the United Nations’ Sustainable Development Goals with Google technologies in this year’s Solution Challenge.


Posted by Erica Hanson, Global Program Manager, Google Developer Student Clubs

Solution Challenge image

Created by the United Nations in 2015 to be achieved by 2030, the 17 Sustainable Development Goals (SDGs) agreed upon by all 193 United Nations Member States aim to end poverty, ensure prosperity, and protect the planet.

Last year brought many challenges, but it also brought a greater spirit around helping each other and giving back to our communities. With that in mind, we invite students around the world to join the Google Developer Student Clubs 2021 Solution Challenge!

If you’re new to the Solution Challenge, it is an annual competition that invites university students to develop solutions for real world problems using one or more Google products or platforms.

This year, see how you can use Android, TensorFlow, Google Cloud, Flutter, or any of your favorite Google technologies to promote employment for all, economic growth, and climate action, by building a solution for one or more of the UN Sustainable Development Goals.

What winners of the Solution Challenge receive

Participants will receive specialized prizes at different stages:

  1. The Top 50 teams will receive mentorship from Google and other experts to further work on their projects.
  2. The Top 10 finalists will receive a 1-year subscription to Pluralsight, swag, additional customized mentoring from Google, and a feature in the Google Developers Blog and Demo Day live on YouTube.
  3. The 3 Grand Prize Winners will receive all the prizes included in the Top 10 category along with a Chromebook and a private team meeting with a Google executive.

How to get started on the Solution Challenge

There are four main steps to joining the Solution Challenge and getting started on your project:

  1. Register at goo.gle/solutionchallenge and join a Google Developer Student Club at your college or university. If there is no club at your university, you can join the closest one through the event platform.
  2. Select one or more of the United Nations 17 Sustainable Development Goals to solve for.
  3. Build a solution using Google technology.
  4. Create a demo and submit your project by March 31, 2021.

Resources from Google for Solution Challenge participants

Google will provide Solution Challenge participants with various resources to help students build strong projects for their contest submission.

  • Live online sessions with Q&As
  • Mentorship from Google, Google Developer Experts, and the Developer Student Club community
  • Curated codelabs designed by Google Developers
  • Access to Design Sprint guidelines developed by Google Ventures
  • and more!

When are winners announced?

Once all the projects are submitted after the March 31st deadline, judges will evaluate and score each submission from around the world using the criteria listed on the website. From there, winning solutions will be announced in three rounds.

Round 1 (May): The Top 50 teams will be announced.

Round 2 (July): After the top 50 teams submit their new and improved solutions, 10 finalists will be announced.

Round 3 (August): In the finale, the top 3 grand prize winners will be announced live on YouTube during the 2021 Solution Challenge Demo Day.

With a passion for building a better world, savvy coding skills, and a little help from Google, we can’t wait to see the solutions students create.

Learn more and sign up for the 2021 Solution Challenge, here.

AGP 7.0: Next major release for the Android Gradle plugin


Posted by Murat Yener, Developer Advocate

Today marks the release of the first Canary version of Android Studio Arctic Fox (2020.3.1), together with Android Gradle plugin (AGP) version 7.0.0-alpha01. With this release we are adjusting the version numbering for our Gradle plugin and decoupling it from the Android Studio versioning scheme. In this blog post we’ll explain the reasons for the change, as well as give a preview of some important changes we’re making to our new, incubating Android Gradle plugin APIs and DSL.

New versioning scheme

With AGP 7.0.0 we are adopting the principles of semantic versioning. What this means is that only major version changes will break API compatibility. We intend to release one major version each year, right after Gradle introduces its own yearly major release.

Moreover, in the case of a breaking change, we will ensure that the removed API is marked with @Deprecated about a year in advance and that its replacement is available at the same time. This will give developers roughly a year to migrate and test their plugins with the new API before the old API is removed.

Alignment with Gradle’s version is also why we’re skipping versions 5 and 6, and moving directly to AGP 7.0.0. This alignment indicates that AGP 7.x is meant to work with Gradle 7.x APIs. While it may also run on Gradle 8.x, this is not guaranteed and will depend on whether 8.x removes APIs that AGP relies on.

With this change, the AGP version number will be decoupled from the Android Studio version number. However we will keep releasing Android Studio and Android Gradle plugin together for the foreseeable future.

Compatibility between Android Studio and Android Gradle plugin remains unchanged. As a general rule, projects that use stable versions of AGP can be opened with newer versions of Android Studio.

Java 11 requirement

You can still use Java programming language version 8 with AGP 7.0.0-alpha01 but we are changing the minimum required Java programming language version to Java 11, starting with AGP 7.0.0-alpha02. We are announcing this early in the Canary schedule and many months ahead of the stable release to allow developers time to get ready.

Incubating APIs and important API changes

This release of AGP also introduces some API changes. As a reminder, a number of APIs that were introduced in AGP 4.1 were marked as incubating and were subject to change. In fact, in AGP 4.2 some of these APIs have changed. The APIs that are currently incubating do not follow the deprecation cycle that we explain above.

Here is a summary of some important API changes.

  • The onVariants, onProperties and onVariantProperties blocks are removed in version 4.2 beta.
  • These APIs are replaced with beforeVariants and onVariants in the new androidComponents block. Both beforeVariants and onVariants can optionally use a VariantSelector to reduce the number of variants the callback will run on, based on build type, name or flavor by using withBuildType, withName and withFlavor accordingly. The lambda onVariants and beforeVariants receives is executed after AGP computes variant combinations in afterEvaluate. Nesting properties inside onVariants is removed.
  • Similar APIs are added to androidComponents to allow separate blocks for UnitTests (beforeUnitTest and unitTest) and AndroidTests (beforeAndroidTest and androidTest) instead of nesting tests inside variants.
  • Two classes used by both the old and new way of registering actions for variants were renamed. Variant is now VariantBuilder, and it is used in the beforeVariants phase. VariantProperties is now Variant and it is passed to the new onVariants block.

Let’s take a look at some of these changes. Here is a sample onVariants block which targets the release build. The onVariants block Is changed to beforeVariants and uses a variant selector in the following example.

```
android {

//onVariants.withName("release") {
// ...
//}

}
androidComponents {
val release = selector().withBuildType("release")
beforeVariants(release) { variant ->
...
}
}

```

Similarly onVariantProperties block is changed to onVariants.

```
android {
...
//onVariantProperties {
// ...
//}

}

androidComponents.onVariants { variant ->
...
}

```

Note, this customization is typically done in a plugin and should not be located in build.gradle. We are moving away from using functions with receivers which suited the DSL syntax but are not necessary in the plugin code.

We are planning to make these APIs stable with AGP 7.0.0 and all plugin authors must migrate to the new androidComponents. If you want to avoid dealing with such changes, make sure your plugins only use stable APIs and do not depend on APIs marked as incubating.

If you want to learn more about other changes coming with this release, make sure to take a look at the release notes.

Java is a registered trademark of Oracle and/or its affiliates.

Announcing Android Studio Arctic Fox (2020.3.1) & Android Gradle plugin 7.0


Posted by Jamal Eason, Product Manager

Android Studio logo

Today marks the release of the first version of Android Studio Arctic Fox (2020.3.1) on the canary channel, together with Android Gradle plugin (AGP) version 7.0.0-alpha01. With this release, we are adjusting the version numbering of Android Studio and our Gradle plugin. This change decouples the Gradle plugin from the Android Studio versioning scheme and brings more clarity to which year and IntelliJ version Android Studio aligns with for each release.

New versioning scheme – Android Studio

With Android Studio Arctic Fox (2020.3.1) we are moving to a year-based system that is more closely aligned with IntelliJ IDEA, the IDE upon which Android Studio is built. We are changing the version numbering scheme to encode a number of important attributes: the year, the version of IntelliJ it is based on, plus feature and patch level. WIth this name change you can quickly figure out which version of the IntelliJ platform you are using in Android Studio. In addition, each major version will have a canonical codename, starting with Arctic Fox, and then proceeding alphabetically to help make it easy to see which version is newer.

We recommend that you use the latest version of Android Studio so that you have access to the latest features and quality improvements. To make it easier to stay up to date, we made the version change to clearly de-couple Android Studio from your Android Gradle Plugin version. An important detail to keep in mind is that there is no impact to the way the build system compiles and packages your app when you update the IDE. In contrast, app build process changes and APK/Bundles are dictated by your project AGP version. Therefore, it is safe to update your Android Studio version, even late in your development cycle, because your project AGP version can be updated in a different cadence than your Android Studio version. Lastly, with the new version system it is even easier than before for you or your team to run both the stable and preview versions of Android Studio at the same time on your app project as long as you keep the AGP version on a stable release.

In the previous numbering system, this release would have been Android Studio 4.3. With the new numbering system, it is now Android Studio Arctic Fox (2020.3.1) Canary 1 or just, Arctic Fox.

Going forward, here is how the Android Studio version number scheme will work:

<Year of IntelliJ Version>.<IntelliJ major version>.<Studio major version>

  • The first two number groups represent the version of the final IntellIj platform that a particular Android Studio release is based on (earlier canaries may still be on the earlier version). For this release, this is 2020.3.
  • The third number group represents the Studio major version, starting at 1 and incrementing by one for every major release.
  • To make it easier to refer to each version, we are also giving major releases a code name, incrementing from A to Z based on animal names. This initial release name is Arctic Fox.

New versioning scheme – Android Gradle plugin

With AGP 7.0.0 we are adopting the principles of semantic versioning, and aligning with the Gradle version that AGP requires. Compatibility between Android Studio and Android Gradle plugin remains unchanged. Projects that use stable versions of AGP can be opened with newer versions of Android Studio.

We will publish another post soon with more details about our AGP versioning philosophy and what is new in AGP 7.0.

What is new in Android Studio Arctic Fox

We are in early days in the feature development phase for Arctic Fox, but we have invested much of our time in addressing over 200 quality improvements and bugs across a wide range of areas in the IDE from the code editor, app inspection tools, layout editor to the embedded emulator. Check out the release notes for the specific bug fixes.

For those trying out Jetpack Compose, we have a host of new updates, like deploy @Preview composables to device/emulator:

Deploy preview composable

Also try out the new Layout Validation Tool in Arctic Fox to see how your layout responds to various screens sizes, font sizes, and Android Color Correction/Color Blind Modes. You can access this via the Layout Validation tool window when you are using the Layout Editor.

Layout Validation

Lastly, for those running MacOS (other platforms are coming soon) with the latest Android Platform tools and an Android 11 device, you can try out the IDE integration for the Wireless ADB feature by going to the Run device selection dialogue → Pair Devices Using Wi-Fi.

Menu to access Wireless ADB feature

Wireless ADB Setup Window

What’s Next

If you want to learn more about other detailed changes coming with this release for both Android Studio and the Android Gradle plugin, make sure to take a look at the release notes.