22 June 2016

Introducing the Android Basics Nanodegree

Posted by Shanea King-Roberson, Lead Program Manager Twitter: @shaneakr Instagram: @theshanea


Do you have an idea for an app but you don’t know where to start? There are over 1 billion Android devices worldwide, providing a way for you to deliver your ideas to the right people at the right time. Google, in partnership with Udacity, is making Android development accessible and understandable to everyone, so that regardless of your background, you can learn to build apps that improve the lives of people around you.

Enroll in the new Android Basics Nanodegree. This series of courses and services teaches you how to build simple Android apps--even if you have little or no programming experience. Take a look at some of the apps built by our students:

The app "ROP Tutorial" built by student Arpy Vanyan raises awareness of a potentially blinding eye disorder called Retinopathy of Prematurity that can affect newborn babies.

And user Charles Tommo created an app called “Dr Malaria” that teaches people ways to prevent malaria.

With courses designed by Google, you can learn skills that are applicable to building apps that solve real world problems. You can learn at your own pace to use Android Studio (Google’s official tool for Android app development) to design app user interfaces and implement user interactions using the Java programming language.

The courses walk you through step-by-step on how to build an order form for a coffee shop, an app to track pets in a shelter, an app that teaches vocabulary words from the Native American Miwok tribe, and an app on recent earthquakes in the world. At the end of the course, you will have an entire portfolio of apps to share with your friends and family.

Upon completing the Android Basics Nanodegree, you also have the opportunity to continue your learning with the Career-track Android Nanodegree (for intermediate developers). The first 50 participants to finish the Android Basics Nanodegree have a chance to win a scholarship for the Career-track Android Nanodegree. Please visit udacity.com/legal/scholarship for additional details and eligibility requirements. You now have a complete learning path to help you become a technology entrepreneur or most importantly, build very cool Android apps, for yourself, your communities, and even the world.

All of the individual courses that make up this Nanodegree are available online for no charge at udacity.com/google. In addition, Udacity provides paid services, including access to coaches, guidance on your project, help staying on track, career counseling, and a certificate upon completion for a fee.

You will be exposed to introductory computer science concepts in the Java programming language, as you learn the following skills.

  • Build app user interfaces
  • Implement user interactions
  • Store information in a database
  • Pull data from the internet into your app
  • Identify and fix unexpected behavior in the app
  • Localize your app to support other languages

To enroll in the Android Basics Nanodegree program, click here.

See you in class!

21 June 2016

Improving Stability with Private C/C++ Symbol Restrictions in Android N

Posted by Dimitry Ivanov & Elliott Hughes, Software Engineers

As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.

We’re making this change because it’s painful for users when their apps stop working after a platform update. Whether they blame the app developer or the platform, everybody loses. Users should have a consistent app experience across updates, and developers shouldn’t have to make emergency app updates to handle platform changes. For that reason, we recommend against using private C/C++ symbols. Private symbols aren’t tested as part of the Compatibility Test Suite (CTS) that all Android devices must pass. They may not exist, or they may behave differently. This makes apps that use them more likely to fail on specific devices, or on future releases — as many developers found when Android 6.0 Marshmallow switched from OpenSSL to BoringSSL.

You may be surprised that there’s no STL in the list of NDK libraries. The three STL implementations included in the NDK — the LLVM libc++, the GNU STL, and libstlport — are intended to be bundled with your app, either by statically linking into your library, or by inclusion as a separate shared library. In the past, some developers have assumed that they didn’t need to package the library because the OS itself had a copy. This assumption is incorrect: a particular STL implementation may disappear (as was the case with stlport, which was removed in Marshmallow), may never have been available (as is the case with the GNU STL), or it may change in ABI incompatible ways (as is the case with the LLVM libc++).

In order to reduce the user impact of this transition, we’ve identified a set of libraries that see significant use from Google Play’s most-installed apps, and that are feasible for us to support in the short term (including libandroid_runtime.so, libcutils.so, libcrypto.so, and libssl.so). For legacy code in N, we will temporarily support these libraries in order to give you more time to transition. Note that we don't intend to continue this support in any future Android platform release, so if you see a warning that means your code will not work in a future release — please fix it now!

Table 1. What to expect if your app is linking against private native libraries.

Libraries App's targetSdkVersion Runtime access via dynamic linker Impact, N Developer Preview Impact, Final N Release Impact, future platform version
NDK Public Any Accessible
Private (graylist) <=23 Temporarily accessible Warning / Toast Warning Error
>=24 Restricted Error Error Error
Private (all other)> Any Restricted Error Error Error

What behavior will I see?

Please test your app during the N Previews.

N Preview behavior

  • All public NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz), plus libraries that are part of your app are accessible.
  • For all other libraries you’ll see a warning in logcat and a toast on the display. This will happen only if your app’s targetSdkVersion is less than N. If you change your manifest to target N, loading will fail: Java’s System.loadLibrary will throw, and C/C++’s dlopen(3) will return NULL.

Test your apps on the Developer Preview — if you see a toast like this one, your app is accessing private native APIs. Please fix your code soon!

N Final Release behavior

  • All NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz), plus libraries that are part of your app are accessible.
  • For the temporarily accessible libraries (such as libandroid_runtime.so, libcutils.so, libcrypto.so, and libssl.so), you’ll see a warning in logcat for all API levels before N, but loading will fail if you update your app so that its targetSdkVersion is N or later.
  • Attempts to load any other libraries will fail in the final release of Android N, even if your app is targeting a pre-N platform version.

Future platform behavior

  • In O, all access to the temporarily accessible libraries will be removed. As a result, you should plan to update your app regardless of your targetSdkVersion prior to O. If you believe there is missing functionality from the NDK API that will make it impossible for you to transition off a temporarily accessible library, please file a bug here.

What do the errors look like?

Here’s some example logcat output from an app that hasn’t bumped its target SDK version (and so the restriction isn’t fully enforced because this is only the developer preview):

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

This is telling you that your library “libapplib.so” refers to the library “libandroid_runtime.so”, which is a private library.

When Android N ships, or if you set your target SDK version to N now, you’ll see something like this if you try to use System.loadLibrary from Java:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by "/system/lib/libnativeloader.so"
is not accessible for the namespace "classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

If you’re using dlopen(3) from C/C++ you’ll get a NULL return and dlerror(3) will return the same “dlopen failed...” string as shown above.

For more information about how to check if your app is using private symbols, see the FAQ on developer.android.com.

Grow your business on Google Play with help from the new Playbook for Developers app

Posted by Dom Elliott, the Google Play team

Today, the Playbook for Developers mobile app is now generally available for Android devices. The app helps you stay up-to-date with the features and best practices to grow your business on Google Play. Thanks to all our beta testers over the last six weeks whose feedback helped us tweak and refine the app in preparation for launch.

Here’s how you read and watch content in the Playbook for Developers app:

  • Choose topics relating to your business interests to personalize My Playbook with curated articles and videos from Google and experts across the web.
  • Explore the in-depth guide to Google’s developer products, with articles grouped by what you’re trying to do: develop, launch, engage, grow, and earn.
  • Take actions on items – complete, share, save, or dismiss them – and read your Saved articles later, including offline if they’re written in the app. A data connection will be needed to read articles and videos from across the web.

The app supports Android 5.0 and above. If you're on an older device, check out our ebook, The Secrets to App Success on Google Play. We will be adding and updating content in the app to help you stay up-to-date and grow your business. Get the Playbook for Developers app today and then give us your feedback. The app is also available in the following languages: Bahasa Indonesia, Deutsch, español (Latinoamérica), le français, português do Brasil, tiếng Việt, русский язы́к, 한국어, 中文 (简体), 中文 (繁體), and 日本語.

This is the second app we’ve released for Google Play developers. Get the Google Play Developer Console app to review your app's performance statistics and financial data, get notified about your app's status and publishing changes, and read and reply to user reviews on the go.

16 June 2016

One Year of Android Security Rewards



A year ago, we added Android Security Rewards to the long standing Google Vulnerability Rewards Program. We offered up to $38,000 per report that we used to fix vulnerabilities and protect Android users.

Since then, we have received over 250 qualifying vulnerability reports from researchers that have helped make Android and mobile security stronger. More than a third of them were reported in Media Server which has been hardened in Android N to make it more resistant to vulnerabilities.

While the program is focused on Nexus devices and has a primary goal of improving Android security, more than a quarter of the issues were reported in code that is developed and used outside of the Android Open Source Project. Fixing these kernel and device driver bugs helps improve security of the broader mobile industry (and even some non-mobile platforms).

By the Numbers

Here’s a quick rundown of the Android VRP’s first year:

  • We paid over $550,000 to 82 individuals. That’s an average of $2,200 per reward and $6,700 per researcher.
  • We paid our top researcher, @heisecode, $75,750 for 26 vulnerability reports.
  • We paid 15 researchers $10,000 or more.
  • There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise.
Thank you to those who submitted high quality vulnerability reports to us last year.

Improvements to Android VRP

We’re constantly working to improve the program and today we’re making a few changes to all vulnerability reports filed after June 1, 2016.

We’re paying more!
  • We will now pay 33% more for a high-quality vulnerability report with proof of concept. For example, the reward for a Critical vulnerability report with a proof of concept increased from $3000 to $4000.
  • A high quality vulnerability report with a proof of concept, a CTS Test, or a patch will receive an additional 50% more.
  • We’re raising our rewards for a remote or proximal kernel exploit from $20,000 to $30,000.
  • A remote exploit chain or exploits leading to TrustZone or Verified Boot compromise increase from $30,000 to $50,000.
All of the changes, as well as the additional terms of the program, are explained in more detail in our Program Rules. If you’re interested in helping us find security vulnerabilities, take a look at Bug Hunter University and learn how to submit high quality vulnerability reports. Remember, the better the report, the more you’ll get paid. We also recently updated our severity ratings, so make sure to check those out, too.

Thank you to everyone who helped us make Android safer. Together, we made a huge investment in security research that has made Android stronger. We’re just getting started and are looking forward to doing even more in the future.

15 June 2016

Android N APIs are now final, get your apps ready for Android N!

Posted by Dave Burke, VP of Engineering

As we put the finishing touches on the next release of Android, which will begin to roll out to consumers later this summer, we’re releasing the 4th Developer Preview of Android N, including the Android N final SDK. And thanks to your continued feedback over the last three releases, all of the APIs are now final as well. If you’ve already enrolled your device in the Android Beta Program, (available at android.com/beta) you will receive an update to this Developer Preview shortly.

Get your apps ready for Android N

The final SDK for Android N is now available for download through the SDK Manager in Android Studio. It gives you everything you need to develop and test against the official APIs in the Android N platform. Once you’ve installed the final SDK, you can update your project’s compileSdkVersion to API 24 to develop with the Android N APIs and build and test on the new platform, for new features such as Multi-window support, direct-reply notifications, and others. We also recommend updating your app’s targetSdkVersion to API 24 to opt-in and test your app with Android N specific behavior changes. For details on how to setup your app with the final SDK, see Set up the Preview. For details on API level 24 check out the API diffs and the updated API reference, now hosted online.

Along with the Android N final SDK, we’ve also updated the Android Support Library to 24.0.0. This allows you to use multi-window and picture-in-picture callbacks, new notification features, methods for supporting Direct Boot, and new MediaBrowser APIs in a backward compatible manner.

Publish your apps to alpha, beta or production channels in Google Play

Now that you have a final set of APIs, you can publish updates compiling with, and optionally targeting, API 24 to Google Play. You can now publish app updates that use API 24 to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, you can test your app’s backward-compatibility and push updates to users whose devices are running Developer Preview 4.

To make sure that your updated app runs well on Android N, as well as older versions, a common strategy is to use Google Play’s beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to Get Developer Preview 4

Developer Preview 4 includes updated system images for all supported Preview devices as well as for the Android emulator. If you are already enrolled in the Android Beta program, your devices will get the Developer Preview 4 update right away, no action is needed on your part. If you aren’t yet enrolled in Android Beta, the easiest way to get started is by visiting android.com/beta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. As always, you can also download and flash this update manually. The N Developer Preview is available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices and the Sony Xperia Z3.

Thanks so much for all of your feedback so far. Please continue to share feedback or requests either in the N Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the consumer release later this summer. We’re looking forward to seeing your apps on Android N!

Android Developer Story: Sendy uses Google Play features to build for the next billion users

Posted by Lily Sheringham, Google Play team

Sendy is a door to door on-demand couriering platform founded in Nairobi, Kenya. It connects customers and logistics providers, providing two unique apps, one for the driver and one for the customer. Watch CEO & Co-founder, Meshack Alloys, and Android Developer, Jason Rogena, explain how they use Developer Console features, such as alpha and beta testing, as well as other tips and best practices, to build for the next billion users.

Learn more about building for billions and get more tips to grow your games business by opting-in to the Playbook app beta and download the Playbook app in the Google Play Store.

09 June 2016

Security "Crypto" provider deprecated in Android N

Posted by Sergio Giro, software engineer

random_droid

If your Android app derives keys using the SHA1PRNG algorithm from the Crypto provider, you must start using a real key derivation function and possibly re-encrypt your data.

The Java Cryptography Architecture allows developers to create an instance of a class like a cipher, or a pseudo-random number generator, using calls like:

SomeClass.getInstance("SomeAlgorithm", "SomeProvider");

Or simply:

SomeClass.getInstance("SomeAlgorithm");

For instance,

Cipher.getInstance(“AES/CBC/PKCS5PADDING”);
SecureRandom.getInstance(“SHA1PRNG”);

On Android, we don’t recommend specifying the provider. In general, any call to the Java Cryptography Extension (JCE) APIs specifying a provider should only be done if the provider is included in the application or if the application is able to deal with a possible ProviderNotFoundException.

Unfortunately, many apps depend on the now removed “Crypto” provider for an anti-pattern of key derivation.

This provider only provided an implementation of the algorithm “SHA1PRNG” for instances of SecureRandom. The problem is that the SHA1PRNG algorithm is not cryptographically strong. For readers interested in the details, On statistical distance based testing of pseudo random sequences and experiments with PHP and Debian OpenSSL,Section 8.1, by Yongge Want and Tony Nicol, states that the “random” sequence, considered in binary form, is biased towards returning 0s, and that the bias worsens depending on the seed.

As a result, in Android N we are deprecating the implementation of the SHA1PRNG algorithm and the Crypto provider altogether. We’d previously covered the issues with using SecureRandom for key derivation a few years ago in Using Cryptography to Store Credentials Safely. However, given its continued use, we will revisit it here.

A common but incorrect usage of this provider was to derive keys for encryption by using a password as a seed. The implementation of SHA1PRNG had a bug that made it deterministic if setSeed() was called before obtaining output. This bug was used to derive a key by supplying a password as a seed, and then using the "random" output bytes for the key (where “random” in this sentence means “predictable and cryptographically weak”). Such a key could then be used to encrypt and decrypt data.

In the following, we explain how to derive keys correctly, and how to decrypt data that has been encrypted using an insecure key. There’s also a full example, including a helper class to use the deprecated SHA1PRNG functionality, with the sole purpose of decrypting data that would be otherwise unavailable.

Keys can be derived in the following way:

  • If you're reading an AES key from disk, just store the actual key and don't go through this weird dance. You can get a SecretKey for AES usage from the bytes by doing:

    SecretKey key = new SecretKeySpec(keyBytes, "AES");

  • If you're using a password to derive a key, follow Nikolay Elenkov's excellent tutorial with the caveat that a good rule of thumb is the salt size should be the same size as the key output. It looks like this:
   /* User types in their password: */  
   String password = "password";  

   /* Store these things on disk used to derive key later: */  
   int iterationCount = 1000;  
   int saltLength = 32; // bytes; should be the same size
              as the output (256 / 8 = 32)  
   int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc  
   byte[] salt; // Should be of saltLength  

   /* When first creating the key, obtain a salt with this: */  
   SecureRandom random = new SecureRandom();  
   byte[] salt = new byte[saltLength];  
   random.nextBytes(salt);  

   /* Use this to derive the key from the password: */  
   KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,  
              iterationCount, keyLength);  
   SecretKeyFactory keyFactory = SecretKeyFactory  
              .getInstance("PBKDF2WithHmacSHA1");  
   byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();  
   SecretKey key = new SecretKeySpec(keyBytes, "AES");  

That's it. You should not need anything else.

To make transitioning data easier, we covered the case of developers that have data encrypted with an insecure key, which is derived from a password every time. You can use the helper class InsecureSHA1PRNGKeyDerivator in the example app to derive the key.

 private static SecretKey deriveKeyInsecurely(String password, int
 keySizeInBytes) {  
    byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);  
    return new SecretKeySpec(  
            InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(  
                     passwordBytes, keySizeInBytes),  
            "AES");  
 }  

You can then re-encrypt your data with a securely derived key as explained above, and live a happy life ever after.

Note 1: as a temporary measure to keep apps working, we decided to still create the instance for apps targeting SDK version 23, the SDK version for Marshmallow, or less. Please don't rely on the presence of the Crypto provider in the Android SDK, our plan is to delete it completely in the future.

Note 2: Because many parts of the system assume the existence of a SHA1PRNG algorithm, when an instance of SHA1PRNG is requested and the provider is not specified we return an instance of OpenSSLRandom, which is a strong source of random numbers derived from OpenSSL.