Android Things makes building connected embedded devices easy by providing the same Android development tools, best-in-class Android framework, and Google APIs that make developers successful on mobile. Since the initial preview launch back in December, the community has turned some amazing ideas into exciting prototypes using the platform.
To empower these makers and developers using Android Things to share and learn from each other, we have partnered with Hackster.io to create a community where aspiring IoT developers can go to showcase their projects and get inspired by the work of others. Hackster.io is a community of 200,000 engineers and developers dedicated to building internet-connected hardware projects. They also seek to educate and challenge members through live workshops and design contests.
We are eager to see the projects that you come up with. More importantly, we're excited to see how your work can inspire other developers to create something great with Android Things. Visit our Hackster.io community to see the amazing projects others have already built and join the community today!
We will be hosting a webinar in cooperation with Hackster.io on July 7th, 2017 at 10AM PST titled Bootstrapping IoT Products with Android Things. During this time, you will learn how we have designed Android Things to address many of the pain points experienced by developers attempting to build IoT products. You will also have the opportunity to send in questions you have regarding the platform and ecosystem. Register today to join us for this exciting event!
Today we are launching a preview of the Android Things Console. This console allows developers to manage the software running on their fleet of Android Things IoT devices, including creating factory images, as well as updating the operating system and developer-provided APKs. Devices need to run a system image downloaded via the Android Things Console in order to receive future updates, such as the upcoming Developer Preview 5. Google provides all of the infrastructure for over-the-air (OTA) updates, so developers can focus on their specific application and not have to build their own implementation – getting their IoT devices to enter the market faster and more securely than before.
Let's take a tour of the console, and see the features it offers.
The developer first defines a product, which includes selecting a name and the type of System-on-Module (SoM) that the device is based on. Many developers want to use Google Play Services when building IoT devices, and this is configured here as an optional feature. The size of the OEM partition is also configured, and must be large enough to include the size of any future APK growth.
A device needs an initial base firmware to receive future updates for the correct product from your console. For starters, you can simply use "Create Build Configuration" to build a default factory image with an empty bundle that is configured for your product. This factory image can then be downloaded and flashed to your device, and you can start developing on it by sideloading an APK.
Later on, once you have prepared an application that you would like to deploy to all the devices in your product, you can upload a bundle to the console. This bundle is a ZIP file that contains a main APK file, user space drivers as a service in an APK, and any additional APKs launched by the main APK. A bootanimation.zip file is also supported, which will be displayed during boot up. The uploaded bundle ZIP file is then used to produce a complete system image that can be deployed to devices. More information about the bundle ZIP file contents is available in the documentation.
This tab allows the developer to select which system image should be pushed to the fleet of product devices. The developer selects one, and then "Push to Devices" starts the process. The update will then be securely pushed to all of the devices, installed to one of the A/B partitions, and made active when the device is rebooted. If any failures are detected, the device automatically rolls back to the previous known working version, so future updates are still possible. Developers will be able to test new releases of Android Things in advance and decide whether devices should be updated automatically.
The Android Things Console is currently a preview, and we are working on many more features and customizations. We encourage all Android Things developers to check out the Android Things Console and provide feedback. You can do this by filing bug reports and feature requests, and asking any questions on Stack Overflow. To learn more about the Android Things Console, read the detailed documentation. We also encourage everyone to join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas.
The processing of external and untrusted content is often one of the most important functions of an app. A newsreader shows the top news articles and a shopping app displays the catalog of items for sale. This comes with associated risks as the processing of untrusted content is also one of the main ways that an attacker can compromise your app, i.e. by passing you malformed content.
Many apps handle untrusted content using WebView, and we've made many improvements in Android over the years to protect it and your app against compromise. With Android Lollipop, we started delivering WebView as an independent APK, updated every six weeks from the Play store, so that we can get important fixes to users quickly. With the newest WebView, we've added a couple more important security enhancements.
Starting with Android O, WebView will have the renderer running in an isolated process separate from the host app, taking advantage of the isolation between processes provided by Android that has been available for other applications.
Similar to Chrome, WebView now provides two levels of isolation:
The newest version of WebView incorporates Google's Safe Browsing protections to detect and warn users about potentially dangerous sites.. When correctly configured, WebView checks URLs against Safe Browsing's malware and phishing database and displays a warning message before users visit a dangerous site. On Chrome, this helpful information is displayed more than 250 million times a month, and now it's available in WebView on Android.
To enable Safe Browsing for all WebViews in your app, add in a manifest tag:
<manifest> <meta-data android:name="android.webkit.WebView.EnableSafeBrowsing" android:value="true" /> . . . <application> . . . </application> </manifest>
Because WebView is distributed as a separate APK, Safe Browsing for WebView is available today for devices running Android 5.0 and above. With just one added line in your manifest, you can update your app and improve security for most of your users immediately.
On June 30, 2017, Google will be ending support for the Android Market app on Android 2.1 Eclair and older devices. When this change happens, users on these devices will no longer be able to access, or install other apps from, the Android Market. The change will happen without a notification on the device, due to technical restrictions in the original Android Market app.
It has been 7 years since Android 2.1 Eclair launched. Most app developers are no longer supporting these Android versions in their apps given these devices now account for only a small number of installs.
We will still be supporting later versions of Android Market for as long as feasible. Google Play, the replacement for Android Market, is available on Android 2.2 and above.
Last year at I/O we launched the Awareness API, a simple yet powerful API that let developers use signals such as Location, Weather, Time and User Activity to build contextually relevant app experiences.
Available via Google Play services, the Awareness API offers two ways to take advantage of context signals within your app. The Snapshot API lets your app request information about the user's current context, while the Fence API lets your app react to changes in user's context, and when it matches a certain set of conditions. For example, "tell me whenever the user is walking and their headphone is plugged in".
Until now, you could specify a time fence on the Awareness APIs but were restricted to using absolute/canonical representation of time. Based on developer feedback, we realized that the flexibility of the API in regards to building time fences did not support higher level abstractions people use when they think and talk about time. "This weekend", "on the next holiday", "after sunset", are all very common and colloquial ways of expressing time. That's why we're adding Semantic time support to these APIs starting today
For e.g., if you were building a fitness app and wanted a way to prompt users everyday morning to start their routine, or if you're a reading app that wants to turn on night mode after dusk; you would have to query a 3p API for sunrise/sunset information at the user location and then write up an Awareness fence with those canonical time values. With our latest update, you can use our TIME_INSTANT_SUNRISE and TIME_INSTANT_SUNSET constants and let the platform manage all the complexity for you.
TIME_INSTANT_SUNRISE
TIME_INSTANT_SUNSET
Let's look at an example. Suppose you're building a fitness app which prompts users on Tuesday, and Thursday around sunrise to begin their morning work out. You can set up this triggering using the following lines of code.
// A sun-state-based fence that is TRUE only on Tuesday and Thursday during Sunrise AwarenessFence.and( TimeFence.aroundTimeInstant(TimeFence.TIME_INSTANT_SUNRISE, -10 * ONE_MINUTE_MILLIS, 5 * ONE_MINUTE_MILLIS), AwarenessFence.or( TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_TUESDAY, 0, ONE_DAY_MILLIS), TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_THURSDAY, 0, ONE_DAY_MILLIS)));
One of our favorite semantic time features is public holidays. Every country and regions within it have different holidays. Assume you were a local hiking & adventure app that wants to show users activities they can indulge in on a holiday that falls on a Friday or a Monday. You can use a combination of Days and Holiday flags to identify this state for all your users around the world. You can do this with just 3 lines of code and have this work in any part of the world.
// A local-time fence that is TRUE only on public holidays in the // device locale that fall on Fridays or Mondays. AwarenessFence.and( TimeFence.inTimeInterval(TimeFence.TIME_INTERVAL_HOLIDAY), AwarenessFence.or( TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_FRIDAY, 9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS), TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_MONDAY, 9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS)));
In both example cases, Awareness does the heavy lifting of localizing time and holidays based on the device locale settings.
We're excited to see what problems you'll solve using this powerful API. Please join our mailing list to get updates about this and other Context APIs at Google.
Today, we're releasing a new Developer Preview 4.1 (DP4.1) of Android Things, with updates for new supported hardware and bug fixes to the platform. Android Things is Google's platform to enable Android Developers to create Internet of Things (IoT) devices, and seamlessly scale from prototype to production.
A new Pico i.MX6UL revision B board has been released, which supports many common external peripherals from partners such as Adafruit and Pimoroni. There were some prototype Pico i.MX6UL boards made available to some early beta testers, and these are not compatible with DP4.1.
DP4.1 also includes some performance improvements since DP4, such as boot time optimizations that improve the startup time of i.MX7D based hardware. This Developer Preview also includes a version of Google Play Services, specifically optimized for IoT devices. This new IoT variant is a lot smaller and optimized for use with Android Things, and requires the use of play-services 11.0.0 or later in your build.gradle. For more information about the supported features in the IoT variant of Google Play Services, see the information page.
Android Things had a large presence at Google I/O this year, with 7 talks covering different aspects of Android Things for developers, and these are available as videos in a playlist for those who could not attend:
Google I/O also had a codelab area, where attendees could sit down and test out Android Things development with some simple guided training guides. These codelabs are available for anyone to try at https://codelabs.developers.google.com/?cat=IoT
Thank you to all the developers who submitted feedback for the previous developer previews. Please continue sending us your feedback by filing bug reports and feature requests, and asking any questions on stackoverflow. To download images for DP4.1, visit the Android Things download page and find the changes in the release notes. You can also join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas, with over 5,600 members.
The 11.0.0 release of the Google Play services SDK includes a new way to access LocationServices. The new APIs do not require your app to manually manage a connection to Google Play services through a GoogleApiClient. This reduces boilerplate and common pitfalls in your app.
GoogleApiClient
Read more below, or head straight to the updated location samples on GitHub.
The LocationServices APIs allow you to access device location, set up geofences, prompt the user to enable location on the device and more. In order to access these services, the app must connect to Google Play services, which can involve error-prone connection logic. For example, can you spot the crash in the app below?
Note: we'll assume our app has the ACCESS_FINE_LOCATION permission, which is required to get the user's exact location using the LocationServices APIs.
ACCESS_FINE_LOCATION
public class MainActivity extends AppCompatActivity implements GoogleApiClient.OnConnectionFailedListener { @Override public void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); GoogleApiClient client = new GoogleApiClient.Builder(this) .enableAutoManage(this, this) .addApi(LocationServices.API) .build(); client.connect(); PendingResult result = LocationServices.FusedLocationApi.requestLocationUpdates( client, LocationRequest.create(), pendingIntent); result.setResultCallback(new ResultCallback() { @Override public void onResult(@NonNull Status status) { Log.d(TAG, "Result: " + status.getStatusMessage()); } }); } // ... }
If you pointed to the requestLocationUpdates() call, you're right! That call throws an IllegalStateException, since the GoogleApiClient is has not yet connected. The call to connect() is asynchronous.
requestLocationUpdates()
IllegalStateException
connect()
While the code above looks like it should work, it's missing a ConnectionCallbacks argument to the GoogleApiClient builder. The call to request location updates should only be made after the onConnected callback has fired:
onConnected
public class MainActivity extends AppCompatActivity implements GoogleApiClient.OnConnectionFailedListener, GoogleApiClient.ConnectionCallbacks { private GoogleApiClient client; @Override protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); client = new GoogleApiClient.Builder(this) .enableAutoManage(this, this) .addApi(LocationServices.API) .addConnectionCallbacks(this) .build(); client.connect(); } @Override public void onConnected(@Nullable Bundle bundle) { PendingResult result = LocationServices.FusedLocationApi.requestLocationUpdates( client, LocationRequest.create(), pendingIntent); result.setResultCallback(new ResultCallback() { @Override public void onResult(@NonNull Status status) { Log.d(TAG, "Result: " + status.getStatusMessage()); } }); } // ... }
Now the code works, but it's not ideal for a few reasons:
onCreate
The new LocationServices APIs are much simpler and will make your code less error prone. The connection logic is handled automatically, and you only need to attach a single completion listener:
LocationServices
public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); FusedLocationProviderClient client = LocationServices.getFusedLocationProviderClient(this); client.requestLocationUpdates(LocationRequest.create(), pendingIntent) .addOnCompleteListener(new OnCompleteListener() { @Override public void onComplete(@NonNull Task task) { Log.d("MainActivity", "Result: " + task.getResult()); } }); } }
The new API immediately improves the code in a few ways:
The new API will automatically resolve certain connection failures for you, so you don't need to write code that for things like prompting the user to update Google Play services. Rather than exposing connection failures globally in the onConnectionFailed method, connection problems will fail the Task with an ApiException:
client.requestLocationUpdates(LocationRequest.create(), pendingIntent) .addOnFailureListener(new OnFailureListener() { @Override public void onFailure(@NonNull Exception e) { if (e instanceof ApiException) { Log.w(TAG, ((ApiException) e).getStatusMessage()); } else { Log.w(TAG, e.getMessage()); } } });
Try the new LocationServices APIs out for yourself in your own app or head over to the android-play-location samples on GitHub and see more examples of how the new clients reduce boilerplate and simplify logic.
Every day developers around the world are hard at work creating high quality apps and games on Android. Striving to deliver amazing experiences for an ever growing diverse user base, we've seen a significant increase in the level of polish and quality of apps and games on Google Play.
As part of our efforts to recognize this content on the Play Store, today we're launching Android Excellence. The new collections will showcase apps and games that deliver incredible user experiences on Android, use many of our best practices, and have great design, technical performance, localization, and device optimization.
Android Excellence collections will refresh quarterly and can be found within the revamped Editors' Choice section of the Play Store – which includes app and game reviews curated by our editorial team.
Congrats to our first group of Android Excellence apps and games!
B&H Photo Video by B&H Photo Video
Citymapper by Citymapper Limited
Drivvo by Drivvo
drupe by drupe
Evernote by Evernote Corporation
HotelTonight by HotelTonight
Kitchen Stories by Kitchen Stories
Komoot by komoot GmbH
Lifesum by Lifesum
Memrise by Memrise
Pocket by Read It Later
Runtastic Running & Fitness by Runtastic
Skyscanner by Skyscanner Ltd
Sleep as Android by Urbandroid Team
Vivino by Vivino
CATS: Crash Arena Turbo Stars by ZeptoLab
Golf Clash by Playdemic
Hitman GO Square Enix Ltd
Horizon Chase by Aquiris Game Studio S.A
Kill Shot Bravo by Hothead Games
Lineage Red Knights by NCSOFT Corporation
Nonstop Knight by flaregames
PAC-MAN 256 - Endless Maze by Bandai Namco Entertainment Europe
Pictionary™ by Etermax
Reigns by DevolverDigital
Riptide GP: Renegade by Vector Unit
Star Wars™: Galaxy of Heroes by Electronic Arts
Titan Brawl by Omnidrone
Toca Blocks by Toca Boca
Transformers: Forged to Fight by Kabam
Stay up-to-date on best practices to succeed on Play and get the latest news and videos with the new beta version of our Playbook app for developers.
Many developers want to make money through their apps, but it's not always easy to deal with all the different types of payment methods. We launched the Google Play In-app Billing API v3 in 2013, helping developers offer in-app products and subscriptions within their apps. Year after year, we've added features to the API, like subscription renewal, upgrades and downgrades, free trials, introductory pricing, promotion codes, and more.
Based on your feedback, we’re pleased to announce the Play Billing Library - Developer Preview 1. This library aims to simplify the development process when it comes to billing, allowing you to focus your efforts on implementing logic specific to your app, such as application architecture and navigation structure. The library includes several convenient classes and features for you to use when integrating your Android apps with the In-app Billing API. The library also provides an abstraction layer on top of the Android Interface Definition Language (AIDL) service, making it easier for you to define the interface between your app and the In-app Billing API.
Starting with Play Billing Library Developer Preview release, the minimum supported API level is Android 2.2 (API level 8), and the minimum supported In-app Billing API is version 3.
In-app billing relies on the Google Play Store, which handles the communication between your app and Google's Play billing service. To use Google Play billing features, your app must request the com.android.vending.BILLING permission in your AndroidManifest.xml file.
com.android.vending.BILLING
AndroidManifest.xml
To use the library, add the following dependency in your build.gradle file:
build.gradle
dependencies { ... compile 'com.android.billingclient:billing:dp-1' }
After this quick setup process, you're ready to start using the Play Billing Library in your app and can connect to the In-app Billing API, query for available products, start the purchase flow, and more.
With a new library comes a refreshed sample! To help you to understand how to implement in-app billing in your app using the new Play Billing Library, we've rewritten the Trivial Drive sample from the ground up.
Since we released Trivial Drive back in 2013, many new features, devices, and platforms have been added to the Android ecosystem. To reflect this evolution, the Trivial Drive v2 sample now runs on Android TV and Android Wear.
Before integrating within your app, you can try the Play Billing Library with the codelab published during Google I/O 2017: Buy and Subscribe: Monetize your app on Google Play.
In this codelab, you will start with a simplified version of Trivial Drive V2 that lets users to "drive" and then you will add in-app billing to it. You'll learn how to integrate purchases and subscriptions as well as the best practices for developing reliable apps that handle purchases.
If you are looking for a step-by-step guide about how to sell in-app products from your app using the Play Billing Library, check out our new training class, explaining how to prepare your application, add products for purchase, start purchase flow and much more.
We look forward to hearing your feedback about this new library. Visit the Play Billing Library site, the library reference, and the new version of the Trivial Drive sample. If you have issues or questions, file a bug report on the Google Issue Tracker, and for issues and suggestions on the sample, contact us on the Trivial Drive issues page.
For technical questions on implementation, library usage, and best practices, you can use the tags google-play and play-billing-library on Stackoverflow or visit the community pages on our Google+ page.
When we launched reCAPTCHA ten years ago, we had a simple goal: enable users to visit the sites they love without worrying about spam and abuse. Over the years, reCAPTCHA has changed quite a bit. It evolved from the distorted text to street numbers and names, then No CAPTCHA reCAPTCHA in 2014 and Invisible reCAPTCHA in March this year.
By now, more than a billion users have benefited from reCAPTCHA and we continue to work to refine our protections.
reCAPTCHA protects users wherever they may be online. As the use of mobile devices has grown rapidly, it's important to keep the mobile applications and data safe. Today, on reCAPTCHA's tenth birthday, we're glad to announce the first reCAPTCHA Android API as part of Google Play Services.
With this API, reCAPTCHA can better tell human and bots apart to provide a streamlined user experience on mobile. It will use our newest Invisible reCAPTCHA technology, which runs risk analysis behind the scene and has enabled millions of human users to pass through with zero click everyday. Now mobile users can enjoy their apps without being interrupted, while still staying away from spam and abuse.
reCAPTCHA Android API is included with Google SafetyNet, which provides services like device attestation and safe browsing to protect mobile apps. Mobile developers can do both the device and user attestations in the same API to mitigate security risks of their apps more efficiently. This adds to the diversity of security protections on Android: Google Play Protect to monitor for potentially harmful applications, device encryption, and regular security updates. Please visit our site to learn more about how to integrate with the reCAPTCHA Android API, and keep an eye out for our iOS library.
The journey of reCAPTCHA continues: we'll make the Internet safer and easier to use for everyone (except bots).
Three weeks ago at Google I/O, we announced the second developer preview of Android O along with key themes, Fluid Experiences and Vitals, and highlighted our work towards a modular base with Project Treble. It was also an important milestone for us with the release of the first beta-quality candidate. We talked a lot about what's new in Android during the keynote and breakout sessions—if you missed the livestream, be sure to check out the full archive of talks here.
Today we're rolling out Developer Preview 3 with the final Android O APIs, the latest system images, and an update to Android Studio to help you get ready for the consumer release later in the summer. Watch for one more preview update coming in July that will bring you the near-final system images.
If you've already enrolled your device in the Android Beta Program, you'll receive an update to Developer Preview 3 shortly.
With the consumer launch approaching in the coming months, a critical first step is making your current app compatible with Android O. This will give your users a seamless transition to the new platform as it arrives on their devices.
If you haven't tested your app for compatibility yet, getting started is straightforward -- just enroll a supported device in Android Beta and get the latest update over-the-air, then install your current app from Google Play and test. The app should run and look great, and it should handle the Android O behavior changes properly -- in particular pay attention to background limits and changes in networking, security, and identifiers.
After you've made any necessary updates, we recommend publishing the compatible version of your app to Google Play right away -- without changing the app's platform targeting.
Extending your apps with Android O features can help you drive more engagement, offer new interactions, give users more control and security, and even improve your app's performance.
Notification channels and dots give you more ways to surface new content to users and bring them back into your app. Picture-in-picture keeps your app onscreen while users are multitasking, and autofill makes it simple for them to enter forms data and helps keep their data secure. Also check out adaptive icons, XML font resources, downloadable fonts and emoji, autosizing TextView, AAudio API, and many others. You'll also want plan your support for background execution limits and other important changes in vital system behavior for O apps.
Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.
Today's preview update includes the latest version of the Android O platform with the final API level 26 and hundreds of bugfixes and optimizations. You can download the final API 26 SDK from the SDK Manager in Android Studio, and Android Support Library 26.0.0 beta 2 from Google's Maven repository.
Together, these give you everything you need to develop and test your apps with the official Android O APIs. Once you've installed the final SDK, you can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to set up your environment to build with Android O.
compileSdkVersion
targetSdkVersion
APIs have changed since the second developer preview, so if you have existing code using Android O preview APIs, take a look at the diff report to see where your code might be affected.
If you're developing for Android O, we recommend updating to the latest version of Android Studio 3.0, now available in the canary channel. Aside from great new features like improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 includes build support for Instant Apps, an Adaptive Icon Wizard, and support for XML Fonts, and Downloadable Fonts.
If you don't plan to use those features, you now have the option of developing for Android O using Android Studio 2.3.3 from the stable channel. Note that the tools for working with adaptive icons and downloadable fonts, and XML fonts are not available in Android Studio 2.3.3.
Now that the APIs are final, you can publish APK updates compiling with, and optionally targeting, API 26 to your alpha, beta, or even production channels in Google Play. Publishing your O-targeted app during the preview lets you test compatibility on existing devices and push updates to devices running API 26 -- such as users who are enrolled in the Android Beta program.
To make sure that your updated app runs well on Android O 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.
Through the Android Beta program, developers and early adopters worldwide will soon be getting Developer Preview 3 on their devices. If you aren't yet enrolled, just visit android.com/beta and opt-in your eligible Android phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and Nexus Player.
Thanks so much for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. We're looking forward to seeing your apps on Android O!
Posted by Kazushi Nagayama, Ninja Spamologist and Bryan Woodward, Policy Specialist
Ensuring Google Play remains trusted and secure is one of our top priorities. We've recently announced improvements in fighting spam installs as well as fake ratings & reviews. In order to underscore these announcements and provide more clarity, we have now updated our Developer Program Policies on incentivized ratings, reviews, and installs:
Developers must not attempt to manipulate the placement of any apps in the Store. This includes, but is not limited to, inflating product ratings, reviews, or install counts by illegitimate means, such as fraudulent or incentivized installs, reviews and ratings.
We deem an action to be incentivized if a user is offered money, goods, or the equivalent in exchange for the action – be it a rating, review or install. Incentivized ratings and reviews have always been against our policies and we will continue to take action against them in order to protect the integrity of our store. Installs done with the intent to manipulate the placement of an app in Google Play will be detected and filtered.
We've observed instances where incentivized installs are utilized solely to manipulate the placement of apps in Google Play; these instances are a policy violation. However, we also recognize that incentivized installs can be a legitimate user acquisition channel for some developers. In order to recognize these two distinct use cases, we are taking the following approach:
Through this approach, we hope to further ensure that the top charts and other discovery mechanisms on Google Play reflect the reality of the popularity of an app.
As a general rule, we advise against utilizing incentivized actions. Incentivized users are a very different user base than users found through other acquisition channels. In an internal analysis, the Google Research team found that incentivized users generally have lower retention rates and make fewer in-app purchases than users found through paid or organic acquisition channels.
For more information on the Google Play policies, please visit the developer policy center. For tips and best practices to find success on Google Play, visit the Android Developers website.
How useful did you find this blogpost?
Two years ago, we launched the Android Security Rewards program. In its second year, we've seen great progress. We received over 450 qualifying vulnerability reports from researchers and the average pay per researcher jumped by 52.3%. On top of that, the total Android Security Rewards payout doubled to $1.1 million dollars. Since it launched, we've rewarded researchers over $1.5 million dollars.
Here are some of the highlights from the Android Security Rewards program's second year:
Thank you to all the amazing researchers who submitted complete vulnerability reports to us last year.
We're constantly working to improve the Android Security Rewards program and today we're making a few changes to all vulnerability reports filed after June 1, 2017.
Because every Android release includes more security protections and no researcher has claimed the top reward for an exploit chains in 2 years, we're excited to increase our top-line payouts for these exploits.
In addition to rewarding for vulnerabilities, we continue to work with the broad and diverse Android ecosystem to protect users from issues reported through our program. We collaborate with manufacturers to ensure that these issues are fixed on their devices through monthly security updates. Over 100 device models have a majority of their deployed devices running a security update from the last 90 days. This table shows the models with a majority of deployed devices running a security update from the last two months:
Thank you to everyone who helped make Android safer and stronger in the past year. Together, we made a huge investment in security research that helps Android users everywhere. If you want to get involved to make next year even better, check out our detailed Program Rules. For tips on how to submit complete reports, see Bug Hunter University.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
