Advanced Android in Kotlin, developed by Google together with Udacity, is our newly-released, free, self-paced online course. In this course expert instructors from the Android team at Google will introduce you to some of the advanced features you can build into your Android apps.
This course is intended for developers who have mastered the basics of building an Android app in Kotlin, and want to dive deeper into advanced functionality. To benefit most from this course, you need skills equivalent to what's taught in our Android Fundamentals Udacity or codelab courses.
Advanced Android in Kotlin teaches you about notifications, graphics and animations on Android, using third-party authentication for login, and how to add maps to your apps. Learn how to create custom views that can look like anything you want, draw to a canvas, and have eye-catching animations. And, most importantly, you will learn how to properly test your apps!
Here is a sample of apps you will build:
Check out the YouTube course trailer below for additional information about the course and apps:
Different people like to learn in different ways, so we are offering this course as both a Udacity video-based course and as a series of codelabs with topics that you can explore in any order. Whether you prefer to work on your own with just the text and code, or to have an instructor help walk through the code with you on video, we’ve got you covered; just choose your path and get learning!
Developers often use the Android Emulator during their day-to-day development to quickly test the latest changes before they are being committed. In addition, developers are increasingly using the emulator in their continuous integration (CI) systems to run a larger suite of automated tests. To better support this use-case, we are open sourcing the Android Emulator Container Scripts and improving the developer experiences around two pain points:
Android supports a wide variety of hardware and software configurations, and the Android Emulator is no different. However, this wide variety can create confusion over environment configurations. How should developers obtain emulators and system images? What drivers are required? How do you run with or without CPU or GPU acceleration? (etc. etc.)
To address this we have launched:
To increase reproducibility, the underlying Dockerfile template makes the required command line flags and system dependencies more explicit (and reproducible via building Docker images from them). For hardware acceleration, note the --privileged flag that is passed to run.sh; we assume CPU acceleration is available when running the emulator, and --privileged is needed to run the containers with CPU acceleration (KVM) enabled.
For more details on how to create and deploy the Android Emulator image, go to the README.
When the emulator is running and a test or the emulator fails, it can be difficult to dive into the running environment and diagnose the error. Often, diagnosis requires direct interaction with the virtual device. We provide two mechanisms for direct interaction:
In the case of ADB, we allow all commands, such as logcat and shell, by forwarding a particular port from the Docker guest to the host. Because the current port is 5555, we'll need to collect more feedback and do more research on how best to separate ports across different containers.
Security note: With remote streaming, keep in mind that once the service is started, anyone who can connect to your computer on port 80/443 can interact with the emulator. So be careful with running this on a public server!
With remote streaming, you can run the emulator in a container, which is as interactive as running locally. Running the emulator in a container makes it easier to debug issues that can be hard to discover using ADB commands. You can access the emulator using a browser with WebRTC, which is used to stream the video, and gRPC, which is used to send mouse and keyboard events to the emulator. Remote streaming requires three containers:
You can compose the Docker containers together using docker-compose, as described in the README. The containers bind to port 80 and 443, so make sure you do not have a web server running. A self-signed certificate will be offered if you point the browser to the host. If you point your browser to the host you should see something like the image below:
Again, keep in mind that anyone who can connect to your host can interact with the emulator. So be careful with running this on a public server!
Testing can seem to be a tax on development time. However, as many seasoned developers have seen, proper automated testing can increase development velocity as the code base becomes bigger and more complex. Continuous testing should give you confidence that the change you make won’t break your app.
With billions of Android devices in use around the world and millions of apps available on the Play Store, it might seem difficult to drive change across the entire ecosystem, but the Accessibility Developer Infrastructure team is doing just that.
Every time a developer uploads an APK or app bundle to the open or closed tracks, Play tests this upload on various device models running different versions of Android and generates a pre-launch report to inform the developer of issues.
One year ago, the team added accessibility suggestions to the report based on industry best practices and Google’s own experience. These tests check for common issues that can make an app harder to use by people with disabilities. For example, they check that buttons are large enough to be comfortable for people to press, and that text has enough contrast with the background to be easier to read.
Since launching in July 2018, more than 3.8 million apps have been tested and over 171 million suggestions have been made to improve accessibility. Along with each suggestion, the developer gets detailed information about how to implement it. Every developer, from a one-person startup to a large enterprise, can benefit from the accessibility suggestions in the pre-launch report.
We are already seeing the real-world impact of these efforts. This year at Google I/O, the number of developers signing up for in-person accessibility consultations was four times the number from 2018. Googlers staffing these sessions reported that the developers had specific questions that were often based on the suggestions from the pre-launch report. The focused questions allowed the Googlers to give more actionable recommendations. These developers found that improving accessibility isn't just the right thing to do, it also makes good business sense by increasing the potential market for their apps.
Accessibility tests in the pre-launch report are just one way Google is raising awareness about accessibility in the global developer community. We partnered with Udacity to create a free online course about web accessibility, released our Accessibility Scanner for Android on the Play Store, and published iOS Accessibility Scanner on GitHub, allowing iOS developers to easily instrument apps to accessibility tests. Together, these efforts support Google's mission to organize the world's information and make it universally accessible and useful.
Learn more about developing with accessibility in mind by visiting the Android Developer Guidelines and the Google Developer Documentation Style Guide.
Posted by Leo Sei, Product Manager on Android Studio and R8
Android developers know that APK size is an important factor in user engagement. Code shrinking helps reduce the size of your APK by getting rid of unused code and resources as well as making your actual code take less space (also known as minification or obfuscation).
That's why we're investing in improving code shrinking to make it faster and more efficient. We're excited to announce that the next generation code shrinker, R8, is available for preview as part of Android Studio 3.3 beta.
R8 does all of shrinking, desugaring and dexing in one step. When comparing to the current code shrinking solution, Proguard, R8 shrinks the code faster while improving the output size.
The following data comes from benchmark on the Santa Tracker app, you can find the project with benchmark details on this GitHub repository.
R8 is available with Android Studio 3.3 beta and works with Proguard rules. To try it, set the following in your project's gradle.properties file:
android.enableR8=true
For the more adventurous, R8 also has full mode that is not directly compatible with Proguard. In order to try that out you can additionally set the following in your gradle.properties file:
android.enableR8.fullMode=true
This turns on more optimizations, that can further reduce app size. However, you might need a few extra keep rules to make it work.
We have tested R8 correctness and performances on a number of apps and the results are promising so we plan to switch R8 as the default shrinker in Android studio soon.
Please give R8 a try and we would love to hear your feedback. You can file a bug report using this link.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
