Android Studio 2.2 Preview - New UI Designer & Constraint Layout

Android Studio 2.2 Preview - New UI Designer & Constraint Layout

Android Android Studio Develop Featured

By Jamal Eason, Product Manager, Android

This week at Google I/O 2016 we launched Android Studio 2.2 Preview. This release is a large update that builds upon our focus to create a fast and productive integrated development environment (IDE) for Android. Developed in sync with the Android platform, Android Studio allows you to develop with the latest Android APIs and features. Since launching Android Studio at Google I/O just 3 years ago, we received great feedback from on you on what features you want the most. Today 92% of the top 125 apps & game developers on Google Play, plus millions of developers worldwide, use Android Studio. We want to continue to build features that will continue to make you more efficient when developing for Android and more productive.

Android Studio 2.2 Preview includes a portfolio of new features along the spectrum of developments, ranging from designing user interfaces to building and debugging your app in new ways. This preview includes the following new categories of features:


Design 

• Layout Editor: A new user interface designer that helps you visually design the layouts in your app. Features like blueprint mode and the new properties panel allow you to quickly edit layouts and widgets faster.


• Constraint Layout: A new powerful and flexible Android layout that allows you to express complex UIs without nesting multiple layouts. 


• Layout Inspector: Debug a snapshot of your app layout running on the Android Emulator or device. Inspect the view hierarchy and corresponding attributes.

Develop

• Firebase Plugin: Explore and integrate the suite of services offered by Firebase inside of Android Studio. Adding services like Analytics, Authentication, Notifications, and AdMob are just a few clicks away.


• Enhanced Code Analysis: Android Studio checks the quality of your Android app code. In addition to 260 Android lint and code inspections, this release includes new code quality checks for Java 8 language usage and a new inspection infrastructure for more cross-file analysis.


• Samples Browser: Referencing Android sample code is now even easier. Within the code editor window, find occurrences of your app code snippets in Google Android sample code to help jump start your app development.


• Improved C++ Support: Android Studio 2.2 improves C++ development with the ability to edit, build, and debug pre-existing Android projects that use ndk-build or CMake rather than Gradle. Additionally, the existing lldb C++ debugger is now even better with project type auto-detection and a Java language aware C++ mode that lets you use a single debugger process to inspect both Java language and C++ runtimes.


• IntelliJ 2016.1: Android Studio 2.2 includes all the latest updates from the underlying JetBrains product platforms IntelliJ.

Build

• Jack Compiler Improvements: For those using the new Jack compiler, Android Studio 2.2 adds support for annotation processing, as well as incremental builds for reduced build times.


• Merged Manifest Viewer: Diagnose how your AndroidManifest.xml merges with your app dependences across your project build variants. 

Test

• Espresso Test Recorder: Record Espresso UI tests simply by using your app as a normal user. As you click through your app UI, reusable and editable test code is then generated for you. You can run the generated tests locally, in your Continuous Integration environment, or in Firebase Test lab. 


• APK Analyzer: Drill into your APK to help you reduce your APK size, debug 64K method limit issues, view contents of Dex files and more.

Google I/O ‘16: What’s New in Android Development Tools

Deeper Dive into the New Features 

Design

• Layout Editor: Android Studio 2.2 features a new user interface designer. There are many enhancements but some of the highlights include: 




• Drag-and-drop widgets from the palette to the design surface or the component tree view of your app.


• Design surface has a blueprint mode to inspect the spacing and arrangement of your layout. 


• Properties panel now shows a curated set of properties for quick widget edits with a full sheet of advanced properties one click away.


• UI builder can edit menu and system preference files. 

The new Layout Editor in Android Studio 2.2 Preview

Edit Menus in the new Layout Editor

• Constraint Layout: This new layout is a flexible layout manager for your app that allows you to create dynamic user interfaces without nesting multiple layouts. It is distributed as a support library that is tightly coupled with Android Studio and backwards compatible to API Level 9. 

At first glance, Constraint Layout is similar to RelativeLayout. However, the Constraint Layout was designed to be used in Studio and it can efficiently express your app design so that you rely on fewer layouts like LinearLayout, FrameLayout, TableLayout, or GridLayout. Lastly, with the built-in automatic constraints inference engine. You can freely design your UI to your liking and let Android Studio do the hard work.



To help you get started, the built-in templates in the New Project Wizard in Android Studio 2.2 Preview now generate  a Constraint Layout. Alternately, you can right click on any layout in the new Layout Editor and select the Convert to ConstraintLayout option.



This is an early preview of the UI designer and Constraint Layout, and we will rapidly add enchantments in upcoming releases. Learn more on the Android Studio tools site.

Constraint Layout

Start Layout Inspector

• Layout Inspector: For new and existing layouts, many times you may want to debug your app UI to determine if your layout is rendering as expected. With the new Layout Inspector, you can drill into the view hierarchy of your app and analyze the attributes of each component of UI on the screen. 

To use the tool, just click on Layout Inspector Icon in the Android Monitor Window, and then Android Studio creates a snapshot of the current view hierarchy of your app for you to inspect.

Layout Inspector

Develop

• Firebase Plugin: Firebase is the new suite of developers services that can help you develop high-quality apps, grow your user base, and earn more money. Inside of Android Studio, you can add Firebase to a new or existing Android app with the new Assistant window. To access the Firebase features click on the Tools menu and then select Firebase. You will want to first setup the brand new Firebase Analytics as the foundation as you explore other Firebase services like Firebase Cloud Messaging or Firease Crash Reporting to add your application. Learn more about the Firebase integration inside Android Studio here.

Firebase Plugin for Android Studio

• Code Sample Browser: In addition to importing Android Samples, the Code Sample Browser is a menu option inside Android Studio 2.2 Preview that allows you to find high-quality, Google-provided Android code samples based on the currently highlighted symbol in your project. To use the feature, highlight a Variables, Types and Methods in your code then Right Click to show a context menu for Find Sample Code. The results are displayed in a bottom output box.   

Code Sample Browser

Build

• CMake and NDK-Build: For those of you using the Android NDK, Android Studio now supports building CMake and NDK-Build Android app projects by pointing Gradle at your existing build files. Once you’ve added your cmake or ndk-build project to Gradle, Android Studio will automatically open your relevant Android code files for editing and debugging in Studio.

For CMake users, just add the path to your CMList.txt file in the externalNativeBuild section of your Gradle file:

CMake Build in Android Studio

For NDK-Build Users, just add the path to your *.mk file in the section of your Gradle file:

NDK-Build in Android Studio

• Improved Jack Tools: The new Jack Toolchain compiles your Java language source into Android dex bytecode. The Jack compiler allows some Java 8 language features, like lambdas, to be used on all versions of Android. This release adds incremental build and full support for annotation processing, so you can explore using Java 8 language features in your existing projects.

To use incremental build with Jack add the following to your build.gradle file:

Enable Jack Incremental Compile Option

Jack will automatically apply annotations processors in your classpath. To use an annotation processor at compile-time without bundling it in your apk, use the new annotationProcessor dependency scope:

Enable Jack Annotation Processing

• Merged Manifest Viewer: Figuring out how your AndroidManifest merges with your project dependencies based on build types, flavors and variants is now easier with Android Studio. Navigate to your AndroidManifest.xml and click on the new Merged Manifest bottom tab. Explore how each node of your AndroidManifest resolves with various project dependencies.  

Merged Manifest Viewer

Test

• Espresso Test Recorder: Sometimes writing UI tests can be tedious. With the Record Espresso UI tests feature, creating tests is now as easy as just using your app. Android Studio will capture all your UI interactions  and convert them into a fully reusable Espresso Test that you can run locally or even on Firebase Test lab. To use the recorder, go to the Run menu and select Record Espresso Test.

Espresso Test Recorder

• APK Analyzer: The new APK Analyzer helps you understand the contents and the sizes of different components in your APK. You can also use it to avoid 64K referenced method limit issues with your Dex files, diagnose ProGuard configuration issues, view merged AndroidManifest.xml file, and inspect the compiled resources file (resources.arsc). This can help you reduce your APK size and ensure your APK contains exactly the things you expect.

The APK Analyzer shows you both the raw file size as well as the download size of various components in your APK. The download size is the estimated size users need to download when the APK is served from Google Play. This information should help you prioritize where to focus in your size reduction efforts.

To use this new feature, click on the Build menu and select Analyze APK… Then, select any APK that you want to analyze.

APK Analyzer

• Java-aware C++ Debugger:  When debugging C++ code on targets running N and above, you can now use a single, Java language aware lldb instance. This debugger continues to support great lldb features like fast steps and memory watchpoints while also allowing you to stop on Java language breakpoints and view your Java language memory contents.

• Auto Debugger Selection: Android Studio apps can now use debugger type “Auto.” This will automatically enable the appropriate debugger -- the Java language aware C++ debugger if enabled and otherwise the hybrid debugger for C++ projects.  Projects exclusively using the Java language will continue to use the Java language debugger.

Enable Auto Debugger for C++

What's Next 

Download



If you are using a previous version of Android Studio, you can check for updates on the Canary channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). This update will download a new version, and not patch your existing copy of Android Studio. You can also download Android Studio 2.2 Preview from canary release site.



For the Android Studio 2.2 Preview, we recommend you run a stable version alongside the new canary. Check out the tools site on how to run two versions at the same time.



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. 

Bring Your Android App to Chromebooks

Bring Your Android App to Chromebooks

Android Android Developer chrome Develop Featured

Posted by Dylan Reid and Elijah Taylor, Software Engineers, Chrome OS



Users love Chromebooks for their speed, security and simplicity. According to IDC¹, in Q1 of this year Chromebook shipments overtook Macs in the U.S. That means, thanks to your support, in the U.S. Chrome OS is now the second most popular PC operating system.  As we continue to increase our focus on mobility, we want to make sure your apps are easily available on this new form factor, reaching the many Chrome devices while maintaining a great experience.

Today we announced that we’re adding Android apps to Chromebooks, which means users will be able to install the apps they know and love. Later this year you can expand your app’s reach to a new hardware platform and wider audience while maximizing the Google Play ecosystem. With expanded app availability, new use cases and improved workflows can be achieved for all Chromebook users, whether for personal use, for work or for education.  As a developer we encourage you to test your app as described here.

Developers can start to optimize their app for the Chromebook form factor in advance of launch later in 2016. Here are some of the benefits:

• Android Apps can be shown in 3 different window sizes to allow the best experience


• Users can multi-task with multiple Android apps in moveable windows along with a full desktop browser, all within the familiar Chrome OS interface.


• Keyboard, mouse, and touch input will seamlessly work together


• Users will get Android notifications on their Chromebooks


• Android apps benefit from the Wifi or Bluetooth connectivity setup by the user or the administrator


• File sharing is seamless between Chrome and Android apps through the Files app


• Performance of demanding apps such as games or design apps is excellent

In addition to being a great personal device, one of the reasons Chromebooks are popular in schools and businesses is that you can centrally manage and configure them with 200+ policies. Administrators can manage Android apps on Chromebooks using the same Admin Console. In addition to whitelisting or push installing specific apps to users, admins can selectively enable them for parts of their organization while disabling in others.



Please come to our Google I/O session on May 19th at 4 pm. You will hear directly  from our friendly engineers on how to optimize your Android app for Chromebooks. We are making the feature available in early June on Asus Chromebook Flip, Chromebook Pixel (2015) and Acer Chromebook R11 specifically for developers to have sufficient time to test their apps. For the actual launch and thereafter we will keep adding support for the following list of devices. Please see detailed instructions on how to get started with testing your apps.



1 - IDC’s Worldwide Quarterly PC Tracker, May 2016

Enhancing Android Pay APIs

Enhancing Android Pay APIs

Android Android Developer Android Pay API Develop Featured

Posted by Pali Bhat, Senior Director, Product Management

Today, we’re enhancing our APIs, making it easier than ever for the developer community to integrate with Android Pay. With just a few lines of code, you can enable quick and seamless checkout to help increase purchase conversions and ongoing engagement.

Improve conversions within apps



We’ve been working with popular apps such as Airbnb, Yelp Eat24, Kickstarter, TicketMaster, Uber and many others to bring the ease of speedy checkouts to apps. We also want to make the same great in-app experience available to all developers, big or small. So we’re taking a few steps:

• Earlier today, we announced Android Instant Apps, which gives users the ability to pay using Android Pay with a single tap, without the friction of getting a user to install the app to complete their transaction. 

Example of Android Pay in Android Instant Apps

• We’re opening the Android Pay API to all developers selling physical goods and services in markets where Android Pay is available—just sign up at developers.google.com/android-pay/


• We’ve teamed up with payment processors globally so developers can integrate Android Pay with their Android apps in just a few hours.

Enhance mobile web payments



Many users continue to make purchases on mobile sites. But buying something from a website on your phone can be clumsy and cumbersome, which results in much lower conversion rates on mobile sites than on desktop sites.



To make painful web checkout forms a thing of the past, we will be launching PaymentRequest, a brand new web API that we are developing together with Chrome and standardizing across browsers through W3C. Android Pay will be part of this API to allow users to pay on mobile websites as they do in-store and in-app.

Example of Android Pay in PaymentRequest

Drive deeper engagement



Thanks for all the great feedback on our Save to Android Pay API since launch. You spoke and we’ve listened: We think you’ll be thrilled with the latest improvements to the Save to Android Pay API. The following enhancements help developers build stronger loyalty and engagement with new and existing customers:

• Enable users to add offers, loyalty cards and gift cards in the Android Pay app with the tap of a button. Simply add a deep link to an email, SMS message, push notification or within an app and you’re all set.


• Enroll new customers into a loyalty program in a variety of ways with the new simplified sign-up feature. Customers can sign-up either in store via a NFC tap or through a sign-up page linked from an Android Pay transaction notification.

Example sign-up feature for Walgreens Balance Reward®  
via Save to Android Pay from transaction notification

We believe that mobile payments can make for a better, more secure shopping experience - so we're in this together for the long haul. We’re building a robust Android Pay ecosystem, one that’s open and scalable, to enable developers to drive mobile payments - and their businesses - forward. We're very excited for the road ahead and we hope you are too.



To learn more about Android Pay and share your feedback, visit our developer pages.

What’s new in Android: the N-Release, Virtual Reality, Android Studio 2.2 and more

What’s new in Android: the N-Release, Virtual Reality, Android Studio 2.2 and more

Android Android N Android Studio Develop Featured Virtual Reality

Posted by Dave Burke, VP of Engineering



In the past year, Android users around the globe have installed apps–built by developers like you–over 65 billion times on Google Play. To help developers continue to build amazing experiences on top of Android, today at Google I/O, we announced a number of new things we’re doing with the platform, including the next Developer Preview of Android N, an extension of Android into virtual reality, an update to Android Studio, and much more!

Android N Developer Preview is available to try on a range of devices

Android N: Performance, Productivity and Security

With Android N, we want to achieve a new level of product excellence for Android, so we’ve carried out some pretty deep surgery to the platform, rewriting and redesigning some fundamental aspects of how the system works. For Android N, we are focused on three key themes: performance, productivity and security. The first Developer Preview introduced a brand new JIT compiler to improve software performance, make app installs faster, and take up less storage. The second N Developer Preview included Vulkan, a new 3D rendering API to help game developers deliver high performance graphics on mobile devices. Both previews also brought useful productivity improvements to Android, including Multi-Window support and Direct Reply.

Multi-Window mode on Android N

Android N also adds some important new features to help keep users safer and more secure. Inspired by how Chromebooks apply updates, we’re introducing seamless updates, so that new Android devices built on N can install system updates in the background. This means that the next time a user powers up their device, new devices can automatically and seamlessly switch into the new updated system image.



Today’s release of Android N Developer Preview 3 is our first beta-quality candidate, available to test on your primary phone or tablet. You can opt in to the Android Beta Program at android.com/beta and run Android N on your Nexus 6, 9, 5X, 6P, Nexus Player, Pixel C, and Android One (General Mobile 4G). By inviting more people to try this beta release, developers can expect to see an uptick in usage of your apps on N; if you’ve got an Android app, you should be testing how it works on N, and be watching for feedback from users.



VR Mode in Android  

Android was built for today’s multi-screen world; in fact, Android powers your phone, your tablet, the watch on your wrist, it even works in your car and in your living room, all the while helping you move seamlessly between each device. As we look to what’s next, we believe your phone can be a really powerful new way to see the world and experience new content virtually, in a more immersive way; but, until this point, high quality mobile VR wasn’t possible across the Android ecosystem. That’s why we’ve worked at all levels of the Android stack in N–from how the operating system reads sensor data to how it sends pixels to the display–to make it especially built to provide high quality mobile VR experiences, with VR Mode in Android. There are a number of performance enhancements designed for developers, including single buffer rendering and access to an exclusive CPU core for VR apps. Within your apps, you can take advantage of smooth head-tracking and stereo notifications that work for VR. Most importantly, Android N provides for very low latency graphics; in fact, motion-to-photon latency on Nexus 6P running Developer Preview 3 is <20 ms, the speed necessary to establish immersion for the user to feel like they are actually in another place. We’ll be covering all of the new VR updates tomorrow at 9AM PT in the VR at Google session, livestreamed from Google I/O.



Android Instant Apps: real apps, without the installation 

We want to make it easier for users to discover and use your apps. So what if your app was just a tap away? What if users didn't have to install it at all? Today, we're introducing Android Instant Apps as part of our effort to evolve the way we think about apps. Whether someone discovers your app from search, social media, messaging or other deep links, they’ll be able to experience a fast and powerful native Android app without needing to stop and install your app first or reauthenticate. Best of all, Android Instant Apps is compatible with all Android devices running Jellybean or higher (4.1+) with Google Play services. Android Instant Apps functionality is an upgrade to your existing Android app, not a new, separate app; you can sign-up to request early access to the documentation.



Android Wear 2.0: UI changes and standalone apps  

This morning at Google I/O, we also announced the most significant Android Wear update since its launch two years ago: Android Wear 2.0. Based on what we’ve learned from users and developers, we're evolving the platform to improve key watch experiences: watch faces, messaging, and fitness. We’re also making a number of UI changes and updating our design guidelines to make your apps more consistent, intuitive, and beautiful.  With Android Wear 2.0, apps can be standalone and have direct network access to the cloud via a Bluetooth, Wi-Fi, or cellular connection.  Since your app won’t have to rely on the Data Layer APIs, it can continue to offer full functionality even if the paired phone is far away or turned off. You can read about all of the new features available in today’s preview here.

Android Studio 2.2 Preview: a new layout designer, constraint layout, and much more

Android Studio is the quickest way to get up and running with Android N and all our new platform features. Today at Google I/O, we previewed Android Studio 2.2 - another big update to the IDE designed to help you code faster with smart new tooling features built in. One of the headline features is our rewritten layout designer with the new constraint layout. In addition to helping you get out of XML to do your layouts visually, the new tools help you easily design for Android’s many great devices. Once you’re happy with a layout, we do all the hard work to automatically calculate constraints for you, so your UIs will resize automatically on different screen sizes . Here’s an overview of more of what’s new in 2.2 Preview (we’ll be diving into more detail this update at 10AM PT tomorrow in “What’s new in Android Development Tools”, livestreamed from Google I/O):

• Speed: New layout designer and constraint layout, Espresso test recording and even faster builds


• Smarts: APK analyzer, Layout inspector, expanded Android code analysis and IntelliJ 2016.1


• Platform Support: Enhanced Jack compiler / Java 8 support, Expanded C++ support with CMake and NDK-Build, Firebase support and enhanced accessibility

New Layout Editor and Constraint Layout in Android Studio 2.2 Preview

This is just a small taste of some of the new updates for Android, announced today at Google I/O. There are more than 50 Android-related sessions over the next three days; if you’re not able to join us in person, many of them will be livestreamed, and all of them will be posted to YouTube after we’re done. We can’t wait to see what you build!

Improving the Security and User Experience of your Google Sign In Implementation

Improving the Security and User Experience of your Google Sign In Implementation

Develop

Posted by Isabella Chen, Software Engineer



We launched a fully revamped Sign-In API with Google Play services 8.3 providing a much more streamlined user
experience and enabling easy server authentication and authorization. We’ve heard from many developers that they’ve found these APIs simple and
less error prone to use. But when we look at applications in the Play Store, we
see many that are still using legacy Plus.API / GoogleAuthUtil.getToken and do
not follow best practices for authentication and authorization. Not following best practices can make your apps easily vulnerable to attack.

It’s also worth noting that developers who don’t want to worry about managing the security implications of different API flows or keeping up to date with the latest  APIs can use Firebase Authentication to manage the entire authentication lifecycle.

Ensuring your apps are secure

Developers should ensure that their apps are not open to the following
vulnerabilities:

• Email or user ID substitution attack
  After signing in with Google on Android, some apps directly send email or
  user ID in plain text to their backend server as the identity credential. These
  server endpoints enable a malicious attacker to easily forge a request and gain
  access to any user’s account by guessing their email / user ID.
  
  
  
  
  
  Figure 1. Email / User ID Substitution Attack
  
  
  
  
  We see a number of developers implement this anti-pattern by using getAccountName or getId from the Plus.API and sending it to their backend.
  
  
  
  
  
  
  Problematic implementations, DO NOT COPY
  
  
  
  
  

• Access token substitution attack
  After signing in with Google on Android, many apps send an access token
  obtained via GoogleAuthUtil.getToken to their backend server as the identity
  assertion. Access tokens are bearer tokens and backend servers cannot easily
  check if the token is issued to them. A malicious attacker can phish the user
  to sign-in on another application and use that different access token to forge
  a request to your backend.
  
  
  
  
  
  Figure 2. Access Token Substitution Attack
  
  
  
  
  Many developers implement this anti-pattern by using GoogleAuthUtil to retrieve
  an access token and sending it to their server to authenticate like in the
  following example:
  
  
  
  
  Problematic implementation, DO NOT COPY
  

Solution

1. Many developers who have built the above anti-patterns into their apps simply
   call our tokenInfo (www.googleapis.com/oauth2/v3/tokeninfo) which is debug-only or unnecessarily call the G+ (www.googleapis.com/plus/v1/people/me) endpoint for user’s profile information. These apps should instead implement
   our recommended ID token flow explained in this blog post. Check out migration guide to move to a both secure and efficient pattern.
   


2. If your server needs access to other Google services, e.g. Drive, you should
   use server auth code flow. You can also check out this blogpost. Worth mentioning, you can also get an ID token using server auth code flow,
   from which you can retrieve user id / email / name / profile url without
   additional network call. Check out the migration guide.
   

Improving the user experience and performance of your apps

There are still many apps using GoogleAuthUtil for server auth and their users
are losing out the improved user experience while the developers of those apps
need to maintain a significantly more complicated implementation.

Here are some of the common problems that we see:

Requesting unnecessary permissions and displaying redundant user experience

Many apps request GET_ACCOUNTS permission and draw their own customized picker
with all email addresses. After getting the email address, the app calls either
GoogleAuthUtil or Plus.API to do OAuth consent for basic sign in. For those
apps, users will see redundant user experience like:

Figure 3. GET_ACCOUNTS runtime permission and redundant user experience



The worst thing is the GET_ACCOUNTS permission. On Marshmallow and above, this
permission is displayed to the user as ‘Contacts’. Many users are unwilling to
grant access to this runtime permission.



Solution



Switch to our new Auth.GOOGLE_SIGN_IN_API for a streamlined user consent experience by providing an intuitive one-tap
interface to provide your app with the user’s name, email address and profile
picture. Your app receives an OAuth grant when the user selects an account,
making it easier to sign the user in on other devices. Learn more

Figure 4. New streamlined, one-tap sign-in experience

Getting ID Token from GoogleAuthUtil for your backend

Before we released revamped Sign-In API, GoogleAuthUtil.getToken was the previously recommended way to retrieve an ID
token via a “magic string.”




Wrong pattern, DO NOT COPY

GoogleAuthUtil.getToken needs to take an email address, which usually leads to
the undesirable user experience in Figure 3. Also, user’s profile information
like name, profile picture url is valuable information to store in your server.
The ID token obtained via Auth.GOOGLE_SIGN_IN_API will contain profile information and your server won’t need additional network
calls to retrieve them.



Solution
Switch to the ID token flow using the new Auth.GOOGLE_SIGN_IN_API and get the one-tap experience. You can also check out this blogpost and the migration guide for more details.

Getting auth code from GoogleAuthUtil for your backend

We once recommended using GoogleAuthUtil.getToken to retrieve a server auth
code via another “magic string.”




Wrong pattern, DO NOT COPY

In addition to the possible redundant user experience in Figure 3, another
problem with this implementation was that if a user had signed in to your
application in the past and then switched to a new device, they would likely
see this confusing dialog:





Figure 5. Confusing consent dialog for returned user if using
GoogleAuthUtil.getToken for auth code

Solution



To easily avoid this “Have offline access” consent dialog, you should switch to server auth code flow using the new Auth.GOOGLE_SIGN_IN_API . We will issue you an auth code silently for a previously signed-in user. You
can also check out this blogpost and migration guide for more info.

Should I ever use GoogleAuthUtil.getToken?

In general, you should NOT use GoogleAuthUtil.getToken, unless you are making
REST API call on Android client. Use Auth.GOOGLE_SIGN_IN_API instead. Whenever possible, use native Android API in Google Play services
SDK. You can check out those APIs at Google APIs for Android.

And starting from Google Play services SDK 9.0, you will need to include -auth SDK split to use GoogleAuthUtil.getToken and related classes

AccountChangeEvent/AccountChangeEventsRequest/AccountChangeEventsResponse.

dependencies {
compile 'com.google.android.gms:play-services-auth:9.0.0'
}

Designing for Multi-Window

Designing for Multi-Window

Android Android N Develop Featured Multiwindow

Posted by Ian Lake, Developer Advocate

As a developer, there’s a wide range of features added in Android N to take advantage of, but when it comes to designing and building your UI, having strong multi-window support should be at the forefront.

The primary mode that users will be interacting with multi-window is through split-screen mode, which is available on both handheld devices and larger tablets. In this mode,
two apps split the available screen space and the user can drag the divider
between the two split screens to resize the apps. As you might imagine, this
mode offers some unique design challenges beyond what was needed previously.

An even more responsive UI

The lessons learned from previous versions of Android, the mobile web, and
desktop environments still apply to Android N. Designing a responsive UI is still an important first step towards an amazing multi-window experience.

A responsive UI is one that adapts to the size provided, picking the best
representation of the content and the appropriate navigation patterns to make a great user experience on any device. Check out the Building a Responsive UI blog post for details on how to design and build an effective responsive UI.

Adapting your layout

As you’re designing layouts for the largest and smallest screens and everything
in between, it is important to make resizing a smooth and seamless transition
as mentioned in the split screen layout guidelines. If you already have a similar layout between mobile and tablet, you’ll find
much of your work taken care of for you.

However, if your mobile and tablet layouts are vastly different and there’s no
way to smoothly transition between the two, you should not transition between them when resizing. Instead, focus on making your tablet UI scale down using the
same responsive UI patterns. This ensures that users do not have to relearn
their UI when resizing your app.

Note that the minimalHeight and minimalWidth layout attributes allow you to set a minimum size you want reported to your Activity, but they
do not mean the user cannot resize your activity smaller - it actually means that
your activity will be cropped to the size the user requests, potentially
forcing elements of your UI off the screen. Strive to support down to the
minimum size of 220x220dp.

Design configurations to consider

While many of the sizes and aspect ratios possible in multi-window are similar
to existing devices (1/3rd of a landscape tablet is similar to existing mobile
devices in screen size), there are a few configurations that are much more
common when considering multi-window.

The first is a 16x9 layout on mobile devices in portrait. In this case, the
vertical space is extremely limited. If you have a number of fixed elements
stacked on top of one another (a toolbar, scrolling content, and a bottom
navigation bar), you might find there’s not actually any room for the scrolling
content - the most important part!

The second case to consider is the 34.15% layout on tablets. The very wide
aspect ratio in device portrait or very tall aspect ratio in device landscape
orientation are more extreme than what is found on existing devices. Consider
using your mobile layouts as a starting point for this configuration.

Patterns to avoid

When it comes to multi-window, there are a few patterns you want to avoid
entirely.

The first is UI interactions that rely on swiping from the edge of the screen.
This has already been somewhat of an issue when it comes to the on screen
navigation bar prominent on many devices (such as Nexus devices), but is even
more so in split-screen mode. Since there is (purposefully) no way to determine
if your activity is on the top or bottom or the left or the right, don’t make edge swipes the only way to access functionality in your app. That doesn’t mean you have to avoid them entirely - just make sure there is
an alternative. A good example of this is the temporary navigation drawer - an edge swipe opens the drawer, but it is also accessible by pressing the
hamburger icon in the toolbar.

The second is disabling multi-window entirely. While there are certainly cases
where this makes sense (i.e., it is fundamentally an immersive experience such
as a game), there are also cases where your activity and any Activities
launched from that Activity are forced to support multi-window. As mentioned in the Preparing for Multi-Window blog post, when you support external apps launching your activity, your activity inherits the multi-window properties of the calling Activity.

Designing for Multi-Window is designing for every device

Building a responsive UI that reacts to the space available is critical to a
great multi-window experience, but it is an exercise that can benefit all of
your users across the wide variety of Android devices.

So use this as an opportunity to #BuildBetterApps

Follow the Android Development Patterns Collection for more!

Hardening the media stack

Hardening the media stack

Android Android N Develop Featured Security

Posted by Dan Austin and Jeff Vander Stoep, Android Security team

To help make Android more secure, we encourage and reward researchers who discover vulnerabilities. In 2015, a series of bugs in
mediaserver’s libstagefright were disclosed to Google. We released updates for
these issues with our August and September 2015 security bulletins.

In addition to addressing issues on a monthly basis, we’ve also been working on
new security features designed to enhance the existing security model and
provide additional defense in-depth. These defense measures attempt to achieve
two goals:

• Prevention: Stop bugs from becoming vulnerabilities
  
• Containment: Protect the system by de-privileging and isolating components that handle
  untrusted content
  

Prevention

Most of the vulnerabilities found in libstagefright were heap overflows
resulting from unsigned integer overflows. A number of integer overflows in libstagefright allowed an attacker to
allocate a buffer with less space than necessary for the incoming data,
resulting in a buffer overflow in the heap.

The result of an unsigned integer overflow is well defined, but the ensuing
behavior could be unexpected or unsafe. In contrast, signed integer overflows
are considered undefined behavior in C/C++, which means the result of an
overflow is not guaranteed, and the compiler author may choose the resulting
behavior—typically what is fastest or simplest. We have added compiler changes
that are designed to provide safer defaults for both signed and unsigned
integer overflows.

The UndefinedBehaviorSanitizer (UBSan) is part of the LLVM/Clang compiler toolchain that detects undefined or
unintended behavior. UBSan can check for multiple types of undefined and unsafe
behavior, including signed and unsigned integer overflow. These checks add code
to the resulting executable, testing for integer overflow conditions during
runtime. For example, figure 1 shows source code for the parseChunk function in the MPEG4Extractor component of libstagefright after the original researcher-supplied patch was
applied. The modification, which is contained in the black box below, appears
to prevent integer overflows from occurring. Unfortunately, while SIZE_MAX and size are 32-bit values, chunk_size is a 64-bit value, resulting in an incomplete check and the potential for
integer overflow. In the line within the red box, the addition of size and chunk_size may result in an integer overflow and creation of buffer smaller than size elements. The subsequent memcpy could then lead to exploitable memory corruption, as size + chunk_size could be less than size, which is highlighted in the blue box. The mechanics of a potential exploit
vector for this vulnerability are explained in more detail by Project Zero.

Figure 1. Source code demonstrating a subtle unsigned integer overflow.

Figure 2 compares assembly generated from the code segment above with a second
version compiled with integer sanitization enabled. The add operation that
results in the integer overflow is contained in the red box.

In the unsanitized version, size (r6) and chunk_size (r7) are added together, potentially resulting in r0 overflowing and being less than size. Then, buffer is allocated with the size specified in r0, and size bytes are copied to it. If r0 is less than r6, this results in memory corruption.

In the sanitized version, size (r7) and chunk_size (r5) are added together with the result stored in r0. Later, r0 is checked against r7, if r0 is less than r7, as indicated by the CC condition code, r3 is set to 1. If r3 is 1, and the carry bit was set, then an integer overflow occurred, and an
abort is triggered, preventing memory corruption.

Note that the incomplete check provided in the patch was not included in figure
2. The overflow occurs in the buffer allocation’s add operation. This addition triggers an integer sanitization check, which turns
this exploitable flaw into a harmless abort.

Figure 2. Comparing unsanitized and sanitized compiler output.

While the integer sanitizers were originally intended as code hygiene tools,
they effectively prevent the majority of reported libstagefright
vulnerabilities. Turning on the integer overflow checks was just the first
step. Preventing the runtime abort by finding and fixing integer overflows,
most of which are not exploitable, represented a large effort by Android's
media team. Most of the discovered overflows were fixed and those that remain
(mostly for performance reasons) were verified and marked as safe to prevent
the runtime abort.

In Android N, signed and unsigned integer overflow detection is enabled on the
entire media stack, including libstagefright. This makes it harder to exploit
integer overflows, and also helps to prevent future additions to Android from
introducing new integer overflow bugs.

Containment

For Android M and earlier, the mediaserver process in Android was responsible
for most media-related tasks. This meant that it required access to all
permissions needed by those responsibilities and, although mediaserver ran in
its own sandbox, it still had access to a lot of resources and capabilities.
This is why the libstagefright bugs from 2015 were significant—mediaserver
could access several important resources on an Android device including camera,
microphone, graphics, phone, Bluetooth, and internet.

A root cause analysis showed that the libstagefright bugs primarily occurred in
code responsible for parsing file formats and media codecs. This is not
surprising—parsing complex file formats and codecs while trying to optimize for
speed is hard, and the large number of edge cases makes such code susceptible
to both accidental and malicious malformed inputs.

However, media parsers do not require access to most of the privileged
permissions held by mediaserver. Because of this, the media team re-architected
mediaserver in Android N to better adhere to the principle of least privilege.
Figure 3 illustrates how the monolithic mediaserver and its permissions have
been divided, using the following heuristics:

• parsing code moved into unprivileged sandboxes that have few or no permissions
  
• components that require sensitive permissions moved into separate sandboxes
  that only grant access to the specific resources the component needs. For
  example, only the cameraserver may access the camera, only the audioserver may
  access Bluetooth, and only the drmserver may access DRM resources.
  

Figure 3. How mediaserver and its permissions have been divided in Android N.

Comparing the potential impact of the libstagefright bugs on Android N and
older versions demonstrates the value of this strategy. Gaining code execution
in libstagefright previously granted access to all the permissions and
resources available to the monolithic mediaserver process including graphics
driver, camera driver, or sockets, which present a rich kernel attack surface.

In Android N, libstagefright runs within the mediacodec sandbox with access to
very few permissions. Access to camera, microphone, photos, phone, Bluetooth,
and internet as well as dynamic code loading are disallowed by SELinux. Interaction with the kernel is further restricted by seccomp. This means that compromising libstagefright would grant the attacker access
to significantly fewer permissions and also mitigates privilege escalation by
reducing the attack surface exposed by the kernel.

Conclusion

The media hardening project is an ongoing effort focused on moving
functionality into less privileged sandboxes and further reducing the
permissions granted to those sandboxes. While the techniques discussed here
were applied to the Android media framework, they are suitable across the
Android codebase. These hardening techniques—and others—are being actively
applied to additional components within Android. As always, we appreciate
feedback on our work and welcome suggestions for how we can improve Android.
Contact us at security@android.com.