Tag Archives: Android Developer

Google Play security metadata and offline app distribution

Posted by James Bender, Product Manager, Google Play

In December last year we announced that we would be making updates to app security to help verify product authenticity from Google Play. We are now adding a small amount of security metadata on top of APKs to verify that the APK was distributed by Google Play.

One of the reasons we're doing this is to help developers reach a wider audience, particularly in countries where peer-to-peer app sharing is common because of costly data plans and limited connectivity.

In the future, for apps obtained through Play-approved distribution channels, we'll be able to determine app authenticity while a device is offline, add those shared apps to a user's Play Library, and manage app updates when the device comes back online. This will give people more confidence when using Play-approved peer-to-peer sharing apps.

This also benefits you as a developer as it provides a Play-authorized offline distribution channel and, since the peer-to-peer shared app is added to your user's Play library, your app will now be eligible for app updates from Play.

No action is needed by developers or by those who use your app or game. We're adjusting Google Play's maximum APK size to take into account the small metadata addition, which is inserted into the APK Signing Block. In addition to improving the integrity of Google Play's mobile app ecosystem, this metadata will also present new distribution opportunities for developers and help more people keep their apps up to date.

How useful did you find this blogpost?

#IMakeApps – Celebrating app makers worldwide

Posted by Patricia Correa, Director, Developer Marketing, Platforms & Ecosystems

The Android developer ecosystem is made up of exceptional individuals with different backgrounds, interests, and dreams. To celebrate the people who make up our community, starting today, and over the coming months, we'll be meeting with developers, founders, product managers, designers, and others from around the world to hear more about their passions and discover what they do when they step away from their computers.

Watch stories featuring adventurer Niek Bokkers from Polarsteps (Netherlands), artist Faith Ringgold from Quiltuduko (USA) and chair restorer Hans Jørgen Wiberg from Be My Eyes (Denmark). You can also read more about them and their apps on g.co/play/imakeapps.

Share your story

We'd love to hear from you too. Use the hashtag #IMakeApps on your social channels, sharing the app or game you work on, your role in its creation, and an image that best depicts who you are outside of work. We will regularly select and share some of our favorites on our channels.

If you also want to get featured in an upcoming #IMakeApps film, tell us more about yourself and your app or game, by completing this self-nomination form.

Stay tuned for more #IMakeApps stories by following us on Twitter, YouTube and LinkedIn.

How useful did you find this blogpost?

Time to celebrate the 2018 Google Play Award nominees

Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play

This year's Google Play Awards will take place on Monday, May 7th, kicking off the week of Google I/O. Celebrating our third year, we're excited to highlight nine categories; some you may recognize from previous years, along with new additions highlighting growth areas and trends we're focused on, such as building for emerging markets.

Each year, the Google Play Awards recognize top apps and games on Google Play. They represent some of the best experiences available on Android, with an emphasis on overall quality, strong design, technical performance, and innovation. The nominees were selected by various teams across Google, and all meet criteria thresholds covering high star rating, Android vitals, and have had a launch or major update since April 2017.

Congratulations to this year's nominees below and don't forget to check them out on the Google Play store at g.co/play/gpa2018.

Standout Well-Being App

Apps empowering people to live the best version of their lives, while demonstrating responsible design and engagement strategies

Best Accessibility Experience

Apps or games enabling device interaction in an innovative way that serves people with disabilities or special needs

Best Social Impact

Apps or games that create a positive impact in communities around the world (focused on health, education, crisis response, refugees, financial health & fundraising functions)

Standout Indie

Games from indie developers that focus on artistic design, gameplay mechanics, and overall polish

Best Community Building Game

Games built to connect gamers, encouraging social interaction and community building

Best AR or VR Experience

Apps or games offering highly engaging and immersive experiences with optimal use of ARCore or Daydream UI

Standout Build for Billions Experience

Apps or games with optimized performance, localization, and culturalization for emerging markets

Standout Startup

Apps from new developers that offer a unique experience while achieving strong organic install growth.

Best Breakthrough Hit

New apps or games with excellent overall design, user experience, engagement and retention, and strong organic install growth

Come back on Monday, May 7th when we announce the winners, and until then, make sure to try out some of these great apps and games on Google Play at g.co/play/gpa2018.

How useful did you find this blogpost?

Introducing new Android Excellence apps and games on Google Play

Kacey Fahey, Developer Marketing, Google Play

Congratulations to the latest apps and games featured in the Android Excellence program on Google Play. As a reminder, these collections are refreshed every three months and recognize apps and games that set the bar for high quality, great user experience, and strong technical performance.

If you're looking for some new apps, here are a few highlights.

  • Adobe Photoshop Lightroom CC: Capture, edit, and share your photos with the power of Lightroom on your mobile device. Use presets for quick and easy edits, or dive in with the advanced editing tools.
  • Seven - 7 Minute Workout Training Challenge: Use this app to fit seven minute workouts into your busy lifestyle. Grab your phone, or even your Wear OS device to work out anywhere and anytime. Keep it up to earn achievements and join the 7 Club for even more support.
  • SoloLearn: Learn to Code for Free: Learn one of many new coding languages by joining a community of millions. Tap in to the 24/7 peer support, or create your own lessons to become a community influencer.

Here are a few of our favorite new games joining the collection.

  • CodyCross: Crossword Puzzles: Try this game for a fun new style of crossword puzzles. Play for free on adventure mode or subscribe for special themed packs, varying difficulty levels and fresh content added weekly.
  • MARVEL Contest of Champions: Play with your favorite Marvel Super Heroes and Super Villians in iconic locations from the Marvel Universe. Assemble your team of champions to play through the exciting storyline and even build alliances with your friends.
  • Orbital 1: Test your skills in this real-time multiplayer game with beautiful 3D graphics. Collect and upgrade fighters and weapons to build out your perfect squad for quick battles and new daily quests.

See the full list of Android Excellence apps and games.

New Android Excellence apps New Android Excellence games
Adobe Photoshop Lightroom CC

Dashlane

Holstelworld

iCook

Keeper Password Manager

Keepsafe Photo Vault

Mobisystems OfficeSuite

PhotoGrid

Runtastic Results

Seven - 7 Minute Workout Training Challenge

SoloLearn: Learn to Code for Free

Tube Map

WPS Office

Angry Birds 2

Azur Lane アズールレーン

CodyCross

Into the Dead 2

Little Panda Restaurant

MARVEL Contest of Champions

Orbital 1

Rooms of Doom

Sky Dancer Run

Sling Kong

Soul Knight

Explore other great apps and games in the Editors' Choice section on Google Play and discover best practices to help you build quality apps and games.

How useful did you find this blogpost?

Double Stuffed Security in Android Oreo

Posted by Gian G Spicuzza, Android Security team

Android Oreo is stuffed full of security enhancements. Over the past few months, we've covered how we've improved the security of the Android platform and its applications: from making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, making Android easier to update, all the way to doubling the Android Security Rewards payouts. Now that Oreo is out the door, let's take a look at all the goodness inside.

Expanding support for hardware security

Android already supports Verified Boot, which is designed to prevent devices from booting up with software that has been tampered with. In Android Oreo, we added a reference implementation for Verified Boot running with Project Treble, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool features to make updates easier and more secure, such as a common footer format and rollback protection. Rollback protection is designed to prevent a device to boot if downgraded to an older OS version, which could be vulnerable to an exploit. To do this, the devices save the OS version using either special hardware or by having the Trusted Execution Environment (TEE) sign the data. Pixel 2 and Pixel 2 XL come with this protection and we recommend all device manufacturers add this feature to their new devices.

Oreo also includes the new OEM Lock Hardware Abstraction Layer (HAL) that gives device manufacturers more flexibility for how they protect whether a device is locked, unlocked, or unlockable. For example, the new Pixel phones use this HAL to pass commands to the bootloader. The bootloader analyzes these commands the next time the device boots and determines if changes to the locks, which are securely stored in Replay Protected Memory Block (RPMB), should happen. If your device is stolen, these safeguards are designed to prevent your device from being reset and to keep your data secure. This new HAL even supports moving the lock state to dedicated hardware.

Speaking of hardware, we've invested support in tamper-resistant hardware, such as the security module found in every Pixel 2 and Pixel 2 XL. This physical chip prevents many software and hardware attacks and is also resistant to physical penetration attacks. The security module prevents deriving the encryption key without the device's passcode and limits the rate of unlock attempts, which makes many attacks infeasible due to time restrictions.

While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo are required to implement key attestation. This provides a mechanism for strongly attesting IDs such as hardware identifiers.

We added new features for enterprise-managed devices as well. In work profiles, encryption keys are now ejected from RAM when the profile is off or when your company's admin remotely locks the profile. This helps secure enterprise data at rest.

Platform hardening and process isolation

As part of Project Treble, the Android framework was re-architected to make updates easier and less costly for device manufacturers. This separation of platform and vendor-code was also designed to improve security. Following the principle of least privilege, these HALs run in their own sandbox and only have access to the drivers and permissions that are absolutely necessary.

Continuing with the media stack hardening in Android Nougat, most direct hardware access has been removed from the media frameworks in Oreo resulting in better isolation. Furthermore, we've enabled Control Flow Integrity (CFI) across all media components. Most vulnerabilities today are exploited by subverting the normal control flow of an application, instead changing them to perform arbitrary malicious activities with all the privileges of the exploited application. CFI is a robust security mechanism that disallows arbitrary changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.

In addition to these architecture changes and CFI, Android Oreo comes with a feast of other tasty platform security enhancements:

  • Seccomp filtering: makes some unused syscalls unavailable to apps so that they can't be exploited by potentially harmful apps.
  • Hardened usercopy: A recent survey of security bugs on Android revealed that invalid or missing bounds checking was seen in approximately 45% of kernel vulnerabilities. We've backported a bounds checking feature to Android kernels 3.18 and above, which makes exploitation harder while also helping developers spot issues and fix bugs in their code.
  • Privileged Access Never (PAN) emulation: Also backported to 3.18 kernels and above, this feature prohibits the kernel from accessing user space directly and ensures developers utilize the hardened functions to access user space.
  • Kernel Address Space Layout Randomization (KASLR): Although Android has supported userspace Address Space Layout Randomization (ASLR) for years, we've backported KASLR to help mitigate vulnerabilities on Android kernels 4.4 and newer. KASLR works by randomizing the location where kernel code is loaded on each boot, making code reuse attacks probabilistic and therefore more difficult to carry out, especially remotely.

App security and device identifier changes

Android Instant Apps run in a restricted sandbox which limits permissions and capabilities such as reading the on-device app list or transmitting cleartext traffic. Although introduced during the Android Oreo release, Instant Apps supports devices running Android Lollipop and later.

In order to handle untrusted content more safely, we've isolated WebView by splitting the rendering engine into a separate process and running it within an isolated sandbox that restricts its resources. WebView also supports Safe Browsing to protect against potentially dangerous sites.

Lastly, we've made significant changes to device identifiers to give users more control, including:

  • Moving the static Android ID and Widevine values to an app-specific value, which helps limit the use of device-scoped non-resettable IDs.
  • In accordance with IETF RFC 7844 anonymity profile, net.hostname is now empty and the DHCP client no longer sends a hostname.
  • For apps that require a device ID, we've built a Build.getSerial() API and protected it behind a permission.
  • Alongside security researchers1, we designed a robust MAC address randomization for Wi-Fi scan traffic in various chipsets firmware.

Android Oreo brings in all of these improvements, and many more. As always, we appreciate feedback and welcome suggestions for how we can improve Android. Contact us at security@android.com.

_____________________________________________________________________

1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven

Making Pixel better for Drivers

Posted by Marc Stogaitis and Tajinder Gadh, Software Engineers

Driving is an essential part of our daily activities. So at Google we spend a lot of time thinking how we can make Android devices better and safer for our users. How we can prevent distracted driving and together build an open ecosystem to enable safety first smartphone experiences.

Recently we launched Driving Do-Not-Disturb on the newly announced Pixel 2 generation of devices. Once enabled, Driving Do-Not-Disturb automatically puts your device into a do not disturb mode while driving. During this mode any incoming messages and notifications are silenced while you can still receive incoming calls, navigation directions and voice interactions using a connected Car bluetooth. The product is designed to limit distractions during driving while at the same time not getting in the way so users can continue to use navigation or other similar apps with minimal friction.

Behind the scenes, it uses AI powered on-device Activity Recognition that detects when a person is driving using low power signals from multiple sensors, bluetooth and WiFi. Activity Recognition uses the Android Sensor Hub to ensure low latency, low power and accurate driving detection.

This is a next step in our journey, but we are far from done. Early next year we are introducing the Activity Recognition Transition Api, which is the same Api used by Driving Do Not Disturb to build distraction-free driving experiences.

We appreciate the feedback, and will continue to listen to your feedback as the product evolves.

If you have questions about setting up the Driving Do-Not-Disturb, check out our Help Center.

Announcing Architecture Components 1.0 Stable

Posted by Lukas Bergstrom, Product Manager, Android Developer Frameworks Team

Android runs on billions of devices, from high-end phones to airplane seatbacks. The Android OS manages resources aggressively to perform well on this huge range of devices, and sometimes that can make building robust apps complicated. To make it easier, we launched a preview of Architecture Components at Google I/O to provide guidance on app architecture, with libraries for common tasks like lifecycle management and data persistence. Together, these foundational components make it possible to write modular apps with less boilerplate code, so developers can focus on innovating instead of reinventing the wheel - and we hope to keep building on this foundation in the future.

Today we're happy to announce that the Room and Lifecycle Architecture Components libraries have reached 1.0 stable. These APIs are ready for production apps and libraries, and are our recommendation for developers looking for help with app architecture and local storage (although they're only recommended, not required.) Lifecycles are now also integrated with the Support Library, so you can use them with standard classes like AppCompatActivity.

Although we're declaring them stable today, the beta components are already used in apps that together, have billions of installs. Top developers, like Zappos, have been able to spend more time on what's important thanks to Architecture Components:

Prior to the release of Android Architecture Components we had our own ViewModel implementation. We used Loaders and Dependency Injection to persist our ViewModel through config changes. We recently switched to the Architecture Components ViewModel implementation and all that boilerplate went away. We found that we were able to spend more time on design, business logic and testing, and less on writing boilerplate or worrying about Android lifecycle issues.

We've also started to use LiveData which hooks directly into the Activity lifecycle. We use it to retrieve and display network data and no longer have to concern ourselves with ​network call subscription management. - David Henry, Android Software Engineer, Zappos

Architecture Components provide a simple, flexible and practical approach that frees developers from some common problems so they can focus on building great experiences. This is based on core building blocks tied together by guidance on app architecture.

Lifecycles

Every Android developer has to deal with the operating system starting, stopping and destroying their Activities. That means managing the state of components - such as observables used to update UI - as you move through the lifecycle. Lifecycles enables the creation of lifecycle-aware components that manage their own lifecycles, reducing the possibility of leaks or crashes. The Lifecycle library is the foundation for other Architecture Components like LiveData.

LiveData

LiveData is a lifecycle-aware observable that holds data and provides updates. Your UI code subscribes to changes and provides LiveData a reference to its Lifecycle. Because LiveData is lifecycle-aware, it provides updates when its Lifecycle is started or resumed, but stops providing updates when the LifecycleOwner is destroyed. LiveData is a simple way to build reactive UIs that are safer and more performant.

ViewModel

ViewModel separates ownership of view data and logic from lifecycle-bound entities like Activities and Fragments. A ViewModel is retained until its associated Activity or Fragment is disposed of forever - that means view data survives events like a Fragment being recreated due to rotation. ViewModels not only eliminate common lifecycle issues, they help build UIs that are more modular and easier to test.

Room

Nearly all apps need to store data locally. While Android has bundled SQLite with the platform since version 1, using it directly can be painful. Room is a simple object-mapping layer that provides the full power of SQlite with less boilerplate. Features like compile-time query verification and built-in migration make it easier to build a robust persistence layer, while integration with LiveData lets Room provide database-backed, lifecycle-aware observables. Room blends of simplicity, power and robustness for managing local storage, and we hope you give it a try.

Guide to App Architecture and more

Last but not least, we created a Guide to App Architecture that provides core principles applicable to all developers, and specific guidance on using Architecture Components together. Because we've heard from you that clear and consistent guidance is important, today we're updating developer documentation to point to Architecture Components where appropriate. We also have a rich set of videos, codelabs and sample apps available at the Architecture Components site, with more to come.

Watch this space

Although the first set of Architecture Components is now stable, we know there's more work to do. Over the last few months, we've listened to your feedback and made improvements. We also recently launched a new Architecture Component, PagedList, to alpha, in response to your feedback that handling large datasets with RecyclerView is too difficult. This is just the beginning - we have more major components under development that we're looking to announce in the upcoming months.

Our hope with Architecture Components is to free developers to focus on providing unique new experiences for mobile devices. We're glad we can finally announce them as stable for production use. We'd like to thank the community, which has given such great feedback along the way, and we look forward to continuing the discussion in the comments of this post. Finally, for those of you who've been waiting for this stable launch, get started today.

Update on Kotlin for Android

Posted by James Lau, Product Manager (twitter.com/jmslau)

Today is the beginning of KotlinConf. It's been almost 6 months since we announced Kotlin as a first-class language for Android at Google I/O. During this period, the number of apps on Google Play using Kotlin has more than doubled. More than 17% of the projects in Android Studio 3.0 are now using Kotlin. We are really excited about the strong momentum, and we are thrilled that Android developers all over the world are discovering the joy of Kotlin programming.

Kotlin for Android is production-ready. From startups to Fortune 500 companies, developers are already using Kotlin to build their apps. Developers from Pinterest, to Expedia, to Basecamp -- and many others -- are finding their use of Kotlin is increasing productivity and their overall developer happiness levels. Take a look at some of their experiences with Kotlin below.

With the recent release of Android Studio 3.0, there is now a stable version of our IDE that has Kotlin support built-in. With Support Library 27, we have started adding nullability annotations to make the APIs friendlier to use in Kotlin. We recently published the Android Kotlin Guides on GitHub to provide some guidance for Android Kotlin style and interop. We have also been porting some of our Android samples to Kotlin, and we are adding Kotlin to our official documentation.

Android Studio 3.0

Last week, we released Android Studio 3.0 on the stable channel. This is the first stable release of Android Studio that has Kotlin support built-in. Building on the strength of IntelliJ's Kotlin support, many critical IDE features like code completion and syntax highlighting work well for Kotlin. You can choose to convert Java code to Kotlin by using CodeConvert Java File to Kotlin File, or you can convert snippets of code just by pasting Java code into a Kotlin file.

Project and code templates have also been updated with Kotlin support. When you create a new project or add a new code file, you can choose Kotlin as one of the language options.

The tooling experience with Kotlin is by no means perfect yet. We are aware of several known issues, and we will continue to improve the IDE support for Kotlin in future releases.

Android Kotlin Guides

There are two separate Android Kotlin Guides:

  1. Style guide - details a set of rules and coding standards that Google recommends when writing Kotlin for Android. The guide addresses naming conventions, formatting, structure of the source contents, and much more.
  2. Interop guide - provides a set of rules for creating APIs in the Java and Kotlin programming languages, so that the consuming code in the other language will feel idiomatic.

We intend these guides to be living documents and will evolve them over time. They are hosted on GitHub and we welcome your contributions.

Nullability Annotations

Null-safety is an important feature of the Kotlin language. It helps developers avoid NullPointerExceptions and improves the quality of their apps. Null-safety is a bit more complicated when using Java code from Kotlin. Since any reference in Java may be null, Kotlin's requirement for strict null-safety becomes impractical for Java objects. Types declared in Java that do not contain nullability annotations are called platform types - this means the Kotlin compiler does not know whether it is nullable or not. When calling methods with variables of platform types, the Kotlin compiler relaxes null-safety checks. That means the overall null-safety of your app is weakened.

To let developers take more advantage of Kotlin's strict null-safety, we have started adding nullability annotations in Support Library 27. The Support Library contains a huge API surface area, and we will continue to expand the nullability annotation coverage in the next several releases. In addition, we will also be adding nullability annotations to other Android APIs over time.

While the Kotlin adoption growth is fantastic, our commitment to the Java and C++ programming languages remains unchanged. We've added Java 8 language features support in Android Studio 3.0, and we've added more Java 8 language APIs in Android Oreo. We are also continuing to improve our support for C++17 in the NDK. So even if you are not using Kotlin, your language support will continue to improve.

It's an exciting time to be an Android developer. If you haven't had a chance to try Kotlin, you can get started by learning the basic syntax and by playing with the excellent Kotlin Koans. When you are ready to use Kotlin in your Android app, you can jump to the Android Kotlin page for more resources. With Kotlin's Java interoperability and Android Studio's Java to Kotlin converter, it's easy to start using Kotlin in your project.

Happy Kotlin-ing!

Working with Multiple JobServices

Posted by Isai Damier, Software Engineer, Android DA

Working with Multiple JobServices

In its continuous effort to improve user experience, the Android platform has introduced strict limitations on background services starting in API level 26. Basically, unless your app is running in the foreground, the system will stop all of your app's background services within minutes.

As a result of these restrictions on background services, JobScheduler jobs have become the de facto solution for performing background tasks. For people familiar with services, JobScheduler is generally straightforward to use: except in a few cases, one of which we shall explore presently.

Imagine you are building an Android TV app. Since channels are very important to TV Apps, your app should be able to perform at least five different background operations on channels: publish a channel, add programs to a channel, send logs about a channel to your remote server, update a channel's metadata, and delete a channel. Prior to Android 8.0 (Oreo) each of these five operations could be implemented within background services. Starting in API 26, however, you must be judicious in deciding which should be plain old background Services and which should be JobServices.

In the case of a TV app, of the five operations mentioned above, only channel publication can be a plain old background service. For some context, channel publication involves three steps: first the user clicks on a button to start the process; second the app starts a background operation to create and submit the publication; and third, the user gets a UI to confirm subscription. So as you can see, publishing channels requires user interactions and therefore a visible Activity. Hence, ChannelPublisherService could be an IntentService that handles the background portion. The reason you should not use a JobService here is because JobService will introduce a delay in execution, whereas user interaction usually requires immediate response from your app.

For the other four operations, however, you should use JobServices; that's because all of them may execute while your app is in the background. So respectively, you should have ChannelProgramsJobService, ChannelLoggerJobService, ChannelMetadataJobService, and ChannelDeletionJobService.

Avoiding JobId Collisions

Since all the four JobServices above deal with Channel objects, it should be convenient to use the channelId as the jobId for each one of them. But because of the way JobServices are designed in the Android Framework, you can't. The following is the official description of jobId

Application-provided id for this job. Subsequent calls to cancel, 
or jobs created with the same jobId, will update the pre-existing 
job with the same id. This ID must be unique across all clients 
of the same uid (not just the same package). You will want to 
make sure this is a stable id across app updates, so probably not 
based on a resource ID.

What the description is telling you is that even though you are using 4 different Java objects (i.e. -JobServices), you still cannot use the same channelId as their jobIds. You don't get credit for class-level namespace.

This indeed is a real problem. You need a stable and scalable way to relate a channelId to its set of jobIds. The last thing you want is to have different channels overwriting each other's operations because of jobId collisions. Were jobId of type String instead of Integer, the solution would be easy: jobId= "ChannelPrograms" + channelId for ChannelProgramsJobService, jobId= "ChannelLogs" + channelId for ChannelLoggerJobService, etc. But since jobId is an Integer and not a String, you have to devise a clever system for generating reusable jobIds for your jobs. And for that, you can use something like the following JobIdManager.

JobIdManager is a class that you tweak according to your app's needs. For this present TV app, the basic idea is to use a single channelId over all jobs dealing with Channels. To expedite clarification: let's first look at the code for this sample JobIdManager class, and then we'll discuss.

public class JobIdManager {

   public static final int JOB_TYPE_CHANNEL_PROGRAMS = 1;
   public static final int JOB_TYPE_CHANNEL_METADATA = 2;
   public static final int JOB_TYPE_CHANNEL_DELETION = 3;
   public static final int JOB_TYPE_CHANNEL_LOGGER = 4;

   public static final int JOB_TYPE_USER_PREFS = 11;
   public static final int JOB_TYPE_USER_BEHAVIOR = 21;

   @IntDef(value = {
           JOB_TYPE_CHANNEL_PROGRAMS,
           JOB_TYPE_CHANNEL_METADATA,
           JOB_TYPE_CHANNEL_DELETION,
           JOB_TYPE_CHANNEL_LOGGER,
           JOB_TYPE_USER_PREFS,
           JOB_TYPE_USER_BEHAVIOR
   })
   @Retention(RetentionPolicy.SOURCE)
   public @interface JobType {
   }

   //16-1 for short. Adjust per your needs
   private static final int JOB_TYPE_SHIFTS = 15;

   public static int getJobId(@JobType int jobType, int objectId) {
       if ( 0 < objectId && objectId < (1<< JOB_TYPE_SHIFTS) ) {
           return (jobType << JOB_TYPE_SHIFTS) + objectId;
       } else {
           String err = String.format("objectId %s must be between %s and %s",
                   objectId,0,(1<<JOB_TYPE_SHIFTS));
           throw new IllegalArgumentException(err);
       }
   }
}

As you can see, JobIdManager simply combines a prefix with a channelId to get a jobId. This elegant simplicity, however, is just the tip of the iceberg. Let's consider the assumptions and caveats beneath.

First insight: you must be able to coerce channelId into a Short, so that when you combine channelId with a prefix you still end up with a valid Java Integer. Now of course, strictly speaking, it does not have to be a Short. As long as your prefix and channelId combine into a non-overflowing Integer, it will work. But margin is essential to sound engineering. So unless you truly have no choice, go with a Short coercion. One way you can do this in practice, for objects with large IDs on your remote server, is to define a key in your local database or content provider and use that key to generate your jobIds.

Second insight: your entire app ought to have only one JobIdManager class. That class should generate jobIds for all your app's jobs: whether those jobs have to do with Channels, Users, or Cats and Dogs. The sample JobIdManager class points this out: not all JOB_TYPEs have to do with Channel operations. One job type has to do with user prefs and one with user behavior. The JobIdManager accounts for them all by assigning a different prefix to each job type.

Third insight: for each -JobService in your app, you must have a unique and final JOB_TYPE_ prefix. Again, this must be an exhaustive one-to-one relationship.

Using JobIdManager

The following code snippet from ChannelProgramsJobService demonstrates how to use a JobIdManager in your project. Whenever you need to schedule a new job, you generate the jobId using JobIdManager.getJobId(...).

import android.app.job.JobInfo;
import android.app.job.JobParameters;
import android.app.job.JobService;
import android.content.ComponentName;
import android.content.Context;
import android.os.PersistableBundle;

public class ChannelProgramsJobService extends JobService {
  
   private static final String CHANNEL_ID = "channelId";
   . . .

   public static void schedulePeriodicJob(Context context,
                                      final int channelId,
                                      String channelName,
                                      long intervalMillis,
                                      long flexMillis)
{
   JobInfo.Builder builder = scheduleJob(context, channelId);
   builder.setPeriodic(intervalMillis, flexMillis);

   JobScheduler scheduler = 
            (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
   if (JobScheduler.RESULT_SUCCESS != scheduler.schedule(builder.build())) {
       //todo what? log to server as analytics maybe?
       Log.d(TAG, "could not schedule program updates for channel " + channelName);
   }
}

private static JobInfo.Builder scheduleJob(Context context,final int channelId){
   ComponentName componentName =
           new ComponentName(context, ChannelProgramsJobService.class);
   final int jobId = JobIdManager
             .getJobId(JobIdManager.JOB_TYPE_CHANNEL_PROGRAMS, channelId);
   PersistableBundle bundle = new PersistableBundle();
   bundle.putInt(CHANNEL_ID, channelId);
   JobInfo.Builder builder = new JobInfo.Builder(jobId, componentName);
   builder.setPersisted(true);
   builder.setExtras(bundle);
   builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY);
   return builder;
}

   ...
}

Footnote: Thanks to Christopher Tate and Trevor Johns for their invaluable feedback

Next-generation Dex Compiler Now in Preview

Posted by James Lau, Product Manager

Android developers know that dex compilation is a key step in building an APK. This is the process of transforming .class bytecode into .dex bytecode for the Android Runtime (or Dalvik, for older versions of Android). The dex compiler mostly works under the hood in your day-to-day app development, but it directly impacts your app's build time, .dex file size, and runtime performance.

That's why we are investing in making important improvements in the dex compiler. We're excited to announce that the next-generation dex compiler, D8, is now available for preview as part of Android Studio 3.0 Beta release.

When comparing with the current DX compiler, D8 compiles faster and outputs smaller .dex files, while having the same or better app runtime performance.

* Tested with benchmark project here.
*Tested with benchmark project here.

How to try it?

D8 is available for your preview starting with Android Studio 3.0 Beta. To try it, set the following in your project's gradle.properties file:

android.enableD8=true

We have tested D8's correctness and performance on a number of apps, and the results are encouraging. We're confident enough with the results that we are switching to use D8 as the default dex compiler for building AOSP. There are currently no known issues, but we would love to hear your feedback. You can file a bug report using this link.

What's next?

We plan to preview D8 over the next several months with the Android Studio 3.0 release. During this time, we will focus on addressing any critical bug reports we receive from the community. We plan to bring D8 out of preview and enable it as the default dex compiler in Android Studio 3.1. At that time, the DX compiler will officially be put in maintenance mode. Only critical issues with DX will be fixed moving forward.

Beyond D8, we are also working on R8, which is a Proguard replacement for whole program minification and optimization. While the R8 project has already been open sourced, it has not yet been integrated with the Android Gradle plugin. We will provide more details about R8 in the near future when we are ready to preview it with the community.

Tool developers: get your bytecode tools Java 8 ready

In April, we announced Java 8 language features with desugaring. The desugaring step currently happens immediately after Java compilation (javac) and before any bytecode reading or rewriting tools are run. Over the next couple of months, the desugar step will move to a later stage in the pipeline, as part of D8. This will allow us to further reduce the overall build time and produce more optimized code. This change means that any bytecode reading or rewriting tools will run before the desugar step. If you develop .class bytecode reading or rewriting tools for Android, you will need to make sure they can handle the Java 8 bytecode format so they can continue to work properly when we move desugaring into D8.

Happy dex'ing!