WebViews are one of the most controversial subjects in the Community and unfortunately have been much maligned by developers. WebViews can be extremely useful and the best first implementation for a ton of situations from Login and Payments to User Support and Legal. Using WebViews, you can allocate your resources and attention to what your customers value most. WebView-primary apps even make up almost a third of all Apps on the Google Play Store.

So, how do we make really good WebViews?

Knowledge Drop 🧠💧

1. WebKit implementation varies
   ⏺ Non-Chromium-based (Non-GMS devices and some vendors)
   ⏺ Not all Play-Enabled devices have all features. Use isFeatureSupported and permission checks rather than @Targetan Android OS to be safe.
   ⏺ Customized Chromium Base (Samsung and Amazon Fire devices)
2. There are 3 “Standard” WebViews available embedded as providers.
   ⏺ “Standalone” AOSP basic implementation and standard for 5.X-6.X
   ⏺ “Monochrome” public and AOSP-accessible unified Browser and WebView for 7.X-9.X
   ⏺ “Trichrome” which is a base Core Library, WebView, and Chrome browser all separated for 10.X — Now (13.X)
3. Use the modern WebViewCompat extensions with AndroidX Webkit / AndroidX Browser to avoid compatibility issues & version-based errors
4. All WebView instances in your app will share the same Cache and Dom Storage, improving performance and memory usage
5. Trust the Chromium Docs first over android.dev
   ⏺ WebView is now built and maintained by the Chrome team, so their documentation is going to be the most accurate and extensive

WebView Settings for Success 🏆

“Make it look like Chrome” or “Why is Scaling broken?!?!?!”

ReactJS, VueJS and similar front end frameworks rely on viewport and framing information in order to enable their dynamic sizing and styling features. By Default, what exists on Chrome is not what is enabled in the WebView and it requires some browser/web rendering knowledge to even figure out what is going wrong. Try these out to get the flags that Chrome uses by default (And the CLI WebView Shell shares Chrome default flags, which is infuriating when trying to Test a problem!!!).

*This can be KEY for A11Y where Text and Scaling has been enlarged and especially on 720p screens as often users will lose parts of the webpage.

WebView.settings.apply{
  layoutAlgorithm = WebSettings.LayoutAlgorithm.TEXT_AUTOSIZING
  loadWithOverviewMode = true
  useWideViewPort = true
}

“The WebView page didn’t pass our Security Tests”

You have too much enabled and probably think you need features that you don’t anymore, especially for upload and hybrid interactions
(web <-> native).

1. Dom Storage — aka Local Storage is the key-value store available to browsers which they sometimes use to manage state, but is also completely unprotected.
2. Javascript — I encourage you to test if you actually need it for your application, as some pages may not need this. You do need this for Javascript <-> Native app interactions and captures. Otherwise, you could just leaving the ability to execute code here open.
3. Files — Ton of settings here, but the odds are that unless you are doing something like a PDF or ePub reader they are usually not needed. You absolutely can still do WebView upload with these disabled. If you need to to load local or downloaded assets, use WebViewAssetLoader.
4. Safebrowsing — Don’t load any ClearText Urls (http://) ever, just… no

WebView.settings.apply{
  domStorageEnabled = false //Careful here as your Website might need this
  javaScriptEnabled = false //Check if you actually need this
  allowContentAccess = false
  allowFileAccess = false
  allowFileAccessFromFileURLs = false
  allowUniversalAccessFromFileURLs = false
  safeBrowsingEnabled = true //API 26+ only, use the Compat version below!
}

if(WebViewFeature.isFeatureSupported(WebViewFeature.SAFE_BROWSING_ENABLED)){
  WebSettingsCompat.setSafeBrowsingEnabled(WebView.settings, true)
}

BONUS: Did you know that shouldOverrideUrlLoading() only works on get requests? So, its up to do you to your own validation before loadUrl too.

“Why is this scroll not 60FPS tho?”

1. Optimizing your Web Code will do more than optimizing your WebView
   ⏺ Minify Code
   ⏺ Strip your CSS and packages to what you just need for those pages
   ⏺ Image services that scale to the device/window being serviced
2. More Flags for your profit

WebView.settings.apply{
  loadsImagesAutomatically = true //default value but should declare too
  offscreenPreRaster = true //only API 23+, use Compat version below!
  setSupportZoom(false) //disable to load scale to window size, but disables zoom :(
}

if(WebViewFeature.isFeatureSupported(WebViewFeature.OFF_SCREEN_PRERASTER)){
  WebSettingsCompat.setOffscreenPreRaster(WebView.settings, true)
}

3. Think about your Caching Strategy (LOAD_DEFAULT, LOAD_NO_CACHE, LOAD_CACHE_ELSE_NETWORK, LOAD_CACHE_ONLY) and what the tradeoffs are for your implementation. Cache is powerful.

WebView.settings.setCacheMode(WebSettings.LOAD_DEFAULT)

Testing Your WebViews 🧪

“The Web Team needs something that they can test with on CLI”

Introducing System WebView Shell which you can build yourself (with your own settings) or use one of the pre-built APKs available HERE.

This is the package used by the Compatibility Test Suite and should be a good baseline. Remember though, by default it comes with the WebView.Settings that are used by Chrome and not all the default values assigned in AOSP base.

Some good instructions on gathering traces for reporting are found for Instrumented Tests here and Logging of network data here.

“How do I test it in the App with Tools?”

You can use Chrome Dev Tools with your Android App WebViews.

There are some limitations though not present in usual Chrome.
 — You cannot change executing code in the window (edits mean nothing)
 — Code execution breakpoints work, but might be more flaky for inspection
 — User Gestures and object Inspection don’t really work through the view port

1. Make your WebViews Debuggable (only valid API 19+)
   *Be smart 🧐 and put this in your debug app build setting parameters.

WebView.setWebContentsDebuggingEnabled(true)

Now, you can run your app and connect to that active WebView by going to chrome://inspect/#devices in Chrome and tapping the inspect button under your device. This works for Emulators and Real Devices on the same local network.

2. Network Settings to make it work for ClearText urls and Proxying
*Odds are if you are testing a web application routed through local host or another port locally, you will need to enable insecure URLs or Proxying. The default setting for Android is to have ClearText disabled in all cases.

Add this to your network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
  <!-- Debug Override considerations -->
  <debug-overrides cleartextTrafficPermitted="true">
    <trust-anchors>
       <certificates src="user" />
       <certificates src="system" />
    </trust-anchors>
  </debug-overrides>

3. Add the AndroidX Tracing Controller for tracing deeper into the code at runtime and performance profiling

if (WebViewFeature.isFeatureSupported(
    WebViewFeature.TRACING_CONTROLLER_BASIC_USAGE)) {
  val tracingController = TracingController.getInstance()
  tracingController.start(
      TracingConfig.Builder().addCategories(CATEGORIES_WEB_DEVELOPER).build()
  )
}
....
//Optional
tracingController.stop(FileOutputStream("trace.json"), Executors.newSingleThreadExecutor())

“Unit Test all the things!”

Some of the Best Instructions and Samples on how to do this well again live in the Docs.

Take a Look at the AOSP Tests as well as the SourceCode for AndroidX Browser and Webkit.

Hybrid Apps

“My WebViews need to talk to my App and my App needs to talk to my WebViews” 👉👈

Time to skip and stop using the ol’ JavascriptInterface standard for Web <-> App communication and start using the HTML5 MessageChannel spec because we care about user security and message integrity! This spec works on iOS too.

This is a dedicated set of ports for doing posting and receiving of WebMessage. For obvious reasons, please use WebMessageCompat to avoid compatibility issues.

val uri = Uri.parse("https://developer.android.com/develop/ui/views/layout/webapps")
// Check if this feature is supported, 
// Don't use Android API versions as they aren't guaranteed
if (WebViewFeature.isFeatureSupported(
    WebViewFeature.CREATE_WEB_MESSAGE_CHANNEL)){
   createMessageChannel()
}

fun createMessageChannel(){
  val channel = webView.createMessageChannel() //Creates 2 ports 
  val recievePort = channel[0]
  val sendPort = channel[1]
  //Receive on port 0
  recievePort.setWebMessageCallback(
              WebMessagePortCompat.WebMessageCallBackCompat(){
    override fun onMessage(port: WebMessagePortCompat, 
                           message: WebMessageCompat?){
      // Received Message
    } 
  })
  //Send on port 1
  webView.postWebMessage(WebMessageCompat("a message", 
                          WebMessagePortCompat[]{sendPort}, uri))
}

Some Caveats to be aware of:

1. This only works on Loaded Pages, so no “startup” code can be gathered here. Must wait for onPageFinished() to be called inside of WebViewClientCompat
2. Android 6.0+ only, not supported on older.
3. file://asset_url doesn’t really work here, so if that is your content (ePub Readers and PDF loaders for example) use webview.loadDataWithBaseUrl() instead of loadUrl().

“I need my web page to only load the Android || iOS version”

Did you know that you can grab Javascript Boolean parameters from Android AND iOS (WKWebView) PRIOR TO THE onDocumentReady() CYCLE IN JAVASCRIPT?!

No really, and I have done it to build ALL KINDS of WebViews that “Feel Native” and it’s a solid alternative to custom URL parameters.

Basically, you need to do a Javascript query against the window or a custom extension ala window.mobileInterface for the JS Object. Then just assign boolean values to your JavascriptInterface function that maps to in Android 👇.

class MyJSInterface(){
  @JavascriptInterface
  fun isAndroid():Boolean { return true }
}

val extJSConst = "window.mobileInterface"

And then just add WebView.addJavascriptInterface(MyJSInterface, extJSConst)

which means that window?.mobileInterface.isAndroid() from Javascript would returntrue || null with null being the fail-over.

Since that can be executed prior to onDocumentReady , it means you can set objects to render and not to render in your JS code. This means that the end user will never see a flashing screen of things turning off, execution is faster and streamlined, and you can customize your “Mobile-first” experience without messing with your other web code.

In my opinion, this is just about the only acceptable use of @JavascriptInterface in modern apps because manipulation through MITM security or data concerns just simply don’t exist.

“I need my WebViews to be logged in.” / “Why are my users getting logged out?”

We need to use the CookieManager. This is because most login sessions for Web Apps use Cookies that contain their Token to manage their session validity.

Cookies are managed by default in the caching scheme you defined earlier and that is self managing. If your login is also a WebView (you should consider using a Chrome Custom Tab if you are a hybrid app), the WebView should receive the cookie and “it just works” with regards to your WebViews. If not, you will need to grab your Logged-In token and generate a Cookie or have a Cookie Generator API in your system which you then set below

val cookieManager = CookieManager.getInstance()
cookieManager.setCookie(myUrl, myCookieString, null) //Can use ValueCallback instead of null

This automatic web and cache management does mean that when the user logged in session has timed out either from an invalid session or an expired cookie, it will kick the user out to log in again. This does not align with mobile user expectations where the user has logged in and the app remembers in-perpetuity. This is why users might be complaining about being “logged out” and more importantly for a business, could be negatively affecting your notifications and metrics.

So, let’s save our Logged-In token and store our existing Cookies to put back when the app is restarted. Or, just the cookies we care about most. Now, how you save and store this is very much going to depend on your application and I would encourage you to look at options like making an encrypted DataStore or type-safe Proto DataStore. Don’t worry, invalidation on the web side will still work correctly if you have a user return outside of the window or if you had to do an internal rotation.

val cookieManager = CookieManager.getInstance()
val cookiesString = cookieManager.getCookies()
//Store cookies how you see fit....
cookieManager.setCookie(myUrl, cookiesString, null) 

Conclusion

Not everything needs to or should be fully-Native Mobile. We can build great web experiences in our Apps for our users when we put in the work.

So, I encourage you to think deeply about whether those “Terms and Conditions” popups should be accessed and maintained in an API or simply route to your Url? Do you really want to build all of your customer support pages natively as well? Is this a good use of our resources to build this out natively? If it isn’t for now, doesn’t this still give us a path to evolve later?

Using WebViews effectively can enable teams to move quickly and spend time on what matters most to their customers. Building better Web Apps and WebViews means building better mobile-first experiences that can grow and evolve as you and your company does. Sometimes, web-first is the only solution to getting your product in front of customers and that is fine too. Let’s just make them the best we can! 🥇

SPECIAL THANKS!
I want to thank the Chrome teams for all of the effort and great resources that they have built to help us in our journey to higher quality end user experiences from one engineer to another.

Editors and commenters: Erik Hellman, Mike Nakhimovich, Mike Wolfson

The Better WebViews Collection was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now we are all well past the ANT and Eclipse days, but there are tools that have remained highly functional or grown to be more useful over time. Or, in the light of new tech like ComposeUI, have gained new functionality not easily achievable any way else. 🤫

Let’s talk about… Developer Options

Beware, this article is a re-hash of existing content (see above) in a practical sense for practical devs that actually shows & explains. Not all options will show on all devices.

You are now a Developer…

But did you ever take a look at all the tools in there? 👀

Standard Debugging Tools

Standard things everyone uses almost every day or should know

Bug report shortcut — For Bug reports …a shortcut

Verbose vendor logging — (Vendor devices only) More complete logging in Logcat than would happen normally and can be useful for vendor interactions, fixing a vendor bug, or debugging an integration (*coughs in Samsung*)

Enable view attribute inspection — See View Attributes in the Layout Inspector in Android Studio

Select debug app + Wait for debugger — App won’t start unless the debugger is attached in Android Studio, so you can debug things at startup without a crazy logcat to parse and false warnings.

Verify apps over USB + Verify bytecode of debuggable apps — Generally smart to make sure you don’t load a dodgy app or general malware by accident (usually online)

Logger buffer sizes — Enable longer or shorter logcats (easier to parse longer ones and capture more events)

Feature Flags — Enable features normally hidden for most users, usually more useful on pre-release or experimental release builds with features to be enabled (features like PiP and onscreen notifications were originally tested this way)

Enable GPU debug layers — Enables Vulkcan validation layers for error checking (Mostly for mobile game developers not using OpenGL, though some made-for-Android libs use it too for 3D rendering)

Show refresh rate — It's the refresh rate of the device and screen currently in use (120FPS!) 😎

Debug and Record Touch Targets and Gestures

These two tools are great for recording your work, displaying functionality to others, and debugging things like touch targets and gestures.

Show taps — Small round icon onscreen for where the device believes you are touching (or multiples)

Pointer location — Shows on screen the whole trace of your finger(s) while in a continuous motion along with coordinates (up top)

UI Inspection and Overdraw

Set of tools to be used all the time by any app developer with a front end.

Show surface updates — Flashes when there are updates to the UI(usually pink)

Show layout bounds*** — SUPER USEFUL!!! Shows the bounds of each piece as drawn on screen and how they are connected (great for ConstraintLayout), but this has GREAT helpful bits for Compose UI too! For Compose, you can see if you left any remnants or are actually drawing elsewhere then moving. For a11y, you know exactly where your bounds are and how flat your compositions are to better your speed and UI/UX.

Debug GPU overdraw — Shows you on-screen where and how you are overdrawing in the space. This is bad for rendering in several ways, but can also indicate why a user interaction isn’t working properly (redraw). Standard color = no overdraw. Blue = 1 layer overdrawn. Green = 2 layer overdraw. Pink = 3 layers overdraw. Red = 4+ layers overdrawn. (This one gets weird with Compose because of how it works with the draw cycles, so take that into account on ComposeUI.)

Show view updates — Flashes when there are draw updates (multi-color)

Show hardware layers updates — Flashes when there are updates to the hardware layers (green)

Visual Performance

Know if you are meeting UI performance standards in real-time and what is causing lag.

Strict mode enabled — Flashes on screen when something is is holding the main thread too long

Profile HWUI Rendering — “On Screen as Bars” presenting a visual of the GPU Rendering graph. Each bar is a “frame” on screen and the height indicates how long it took to render. The Green Bar represents hitting a 60FPS target which means no visible jitter to the user (16ms), smooth. The red bar represents 30FPS and beyond it is the “Danger Zone” where it is noticeable by everyone. If the bar fills the screen, the UI skipped those frames as far as the user is concerned. Click here to go more in-depth on what each piece means.

Testing device crashes and weirdness

Emulate systems with low ram or slow processors and certain scenarios that are otherwise hard to replicate. Make your apps resilient and finally track down that one bug! 🐛

Don’t keep activities — kill activities as soon as the next activity is started. GREAT for testing back-stack and returning apps from 3rd party integrations where data is lost or computation entirely gone that is needed.

Background process limit — Emulate older devices and aggressive runtimes/schedulers that limit what can be run at any given time (can also be a performance boon for older devices). Track down what happens when your async code fails that really should be synchronized tasks.

Force activities to be resizable — Know how your app looks and works when resized for different devices like small phones, tables, convertibles and CHROMEBOOKS.

Force desktop mode — See how your apps work on desktops like Chromebooks and Tablets when hooked up to external displays like TVs.

Recording Traces in the wild! 🏕

Did you know that you can record a system trace on-device with only the things you care about RIGHT when you happen to see odd behavior, but don’t happen to have your computer handy?

Record trace — Starts and ends the system trace

Trace debuggable applications — Traces any debuggable applications currently installed

Categories — All of the different selectable system processes to trace

Please share any tools that matter to you and message me (my DMs are open) so that we can continue to add sections depending on what you do as an Android developer (IoT, Game, Flutter, etc). 👋

Video has been shown to increase engagement in apps and with content. How else could gif servicing apps be worth tens of millions and Youtube influencers be selling billions of dollars of product?

The problem is that video in Android can be difficult. You are given the assumption that the video types you will support are pretty basic : embedded MPEG video, URLs to MP4/AVI files, and HLS Streaming. A naive approach would be to use the embedded video player sent with Intents, but that takes the user out of your app. You think, 🤔 “ I’ll just use the Android VideoView class with AppCompat .” Then you realize that it is nearly impossible to make the experience consistent across users because of codec support and whatever the phone manufacturer may have customized in the video player. Finally you settle on Exoplayer2 because it is the package everyone, including Google, uses. Upon further inspection, you quickly realize that it requires a lot of code to make it work and the example application on the Github is confusing, far too extensive for what you are doing. Another route you could take is ExoMedia by Brian Wernick, but it trades extensibility, theming, and control for simplicity.

Fortunately, you only need the Exoplayer2 libraries to have a fantastic video player experience within your app.

SimpleExoplayer “2” the Rescue

First you need to make an app which can receive a URL and play it using Exoplayer. For this, you will need SimpleExoplayer and the Playerview from the UI package. Playerview has easy to manipulate styling/theming elements as well as available media controls. SimpleExoPlayer gives you a preconfigured player to work with without having to handle deeper logic yourself.

Start by adding the Gradle dependencies to your build.gradle :

implementation 'com.google.android.exoplayer:exoplayer-core:2.X.X'
implementation 'com.google.android.exoplayer:exoplayer-hls:2.X.X'
implementation 'com.google.android.exoplayer:exoplayer-ui:2.X.X'
implementation 'com.google.android.exoplayer:extension-mediasession:2.X.X'

Prepare a layout for your video:

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@android:color/black">

    <com.google.android.exoplayer2.ui.PlayerView
        android:id="@+id/playerView"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_gravity="center" />

</android.support.constraint.ConstraintLayout>

Implement Exoplayer in a VideoActivity (Kotlin) :

Quick Note : Exoplayer should be set up in the onStart() for quick initialization that does not interfere with onCreate().

lateinit var player : SimpleExoPlayer
var mUrl = *some string HLS/Standard video url passed to it*

override fun onStart() {
    super.onStart()


    player = ExoPlayerFactory
             .newSimpleInstance(this, DefaultTrackSelector())

    playerView.player = player

    val dataSourceFactory = 
                DefaultDataSourceFactory(this, 
                Util.getUserAgent(this,                  
                applicationInfo.loadLabel(packageManager)
                .toString()))

    when (Util.inferContentType(Uri.parse(mUrl))) {
        C.TYPE_HLS -> {
            val mediaSource = HlsMediaSource
                .Factory(dataSourceFactory)
                .createMediaSource(Uri.parse(mUrl))
            player.prepare(mediaSource)
        }

        C.TYPE_OTHER -> {
            val mediaSource = ExtractorMediaSource
                .Factory(dataSourceFactory)
                .createMediaSource(Uri.parse(mUrl))
            player.prepare(mediaSource)
        }

        else -> {
            //This is to catch SmoothStreaming and
            //DASH types which we won't support currently, exit
            finish()
        }
    } 
    player.playWhenReady = true
}

override fun onStop() {
    super.onStop()
    playerView.player = null
    player.release()
}

That was almost too easy!

Boost it with Picture-in-Picture

This is where things get interesting.

According to the basic documentation on AndroidDevelopers, this is all you need to get started with Picture in Picture :

//For N devices that support it, not "officially"
@Suppress("DEPRECATION")
fun enterPIPMode(){
    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.N
            && packageManager
            .hasSystemFeature(
            PackageManager.FEATURE_PICTURE_IN_PICTURE)) {
        videoPosition = player.currentPosition
        playerView.useController = false
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val params = PictureInPictureParams.Builder()
            this.enterPictureInPictureMode(params.build())
        } else {
            this.enterPictureInPictureMode()
        }
}

Now, I will say that while implementing Picture in Picture support, Google was notified of issues in documentation. It’s better now and includes some of the things like checking if the system has the feature (some devices will not have Picture in Picture because of RAM considerations) which is shown above. 👏

Next, hook up switching to Picture in Picture when the user hits the Recents, Home, and Back buttons here :

override fun onBackPressed(){
    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.N
            && packageManager
            .hasSystemFeature(
            PackageManager.FEATURE_PICTURE_IN_PICTURE)){
        enterPIPMode()
    } else {
        super.onBackPressed()
    }
}

/Called when the user touches the Home or Recents button to leave the app.
override fun onUserLeaveHint() {
    super.onUserLeaveHint()
    enterPIPMode()
}

Google has added some of this to the documentation recently 😀, but not onBackPressed() 🧐 . What could be unique about onBackPressed()?

Permission Handling

The user can turn off this permission as part of the Advanced permissions.

If you are familiar with deeper permission handling as well as the system the normal Permissions tie into, you should just be able to handle this case in AppOpsManager. In that case, the code would look like this :

val appOpsManager = 
    getSystemService(Context.APP_OPS_SERVICE) as AppOpsManager

if(appOpsManager.checkOpNoThrow(
    AppOpManager.OP_PICTURE_IN_PICTURE, 
    packageManager.getApplicationInfo(packageName, 
    PackageManager.GET_META_DATA).uid, packageName)
    == AppOpsManager.MODE_ALLOWED){
     //Picture in Picture is enabled, yay!
}

Oh, there is a problem with that. It’s not valid in Android Studio 😠.

https://github.com/aosp-mirror/platform_frameworks_base/blob/studio-3.1.2/core/java/android/app/AppOpsManager.java#L1640

For the Integer-Op-type, unlike the String-Op-type version, the ability to check the permission is hidden 🙅.

WHY?!?!

One likely answer is that this was a carry-over from N where Google didn’t anticipate Picture in Picture becoming a public feature or Google could be trying to enforce certain developer behavior. Right now, if the user does not have the Picture in Picture mode enabled in these special permissions, it will not work and there isn’t a nice way to check it 😥. For apps, it means that you cannot enable Picture in Picture mode for onBackPressed() without risking needless crashes and an unpleasant user experience.

Pressing the back button seems like the most common use-case for small video content, so this lack of handling the Back button doesn’t entirely make sense.

Again, they could have this fixed in the proper AndroidStudio 3.2.X release, but that isn’t out yet.

So, you need to be a little creative here 🤔 :

fun enterPIPMode(){
        if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.N
            && packageManager
            .hasSystemFeature(
            PackageManager.FEATURE_PICTURE_IN_PICTURE)) {

         ...
         ...

    Handler().postDelayed({checkPIPPermission()}, 30)
    }
}

@RequiresApi(Build.VERSION_CODES.N)
fun checkPIPPermission(){
    isPIPModeeEnabled = isInPictureInPictureMode
    if(!isInPictureInPictureMode){
        onBackPressed()
    }
}

I know, it seems a bit jank. But, 25–30ms to check whether the Activity actually went into Picture in Picture mode is plenty of time, even devices that have very limited memory (512mb + running other apps), to enter Picture in Picture mode as far as the system is concerned. It also gives you enough time to send the onBackPressed() so that the system knows you aren’t holding the user hostage and the delay is neigh imperceptible by the user. Yes, this is under the AOSP “Bad Behavior” timer. 😜

More Picture in Picture oddness discovered

Now that Picture in Picture mode is working and no crashes can really happen, there is another scenario which comes up.

The user hits the “X” or drags the Picture in Picture window down to dismiss. You would expect that this simply calls finish() and the window disappears into the ether. But, it doesn’t. You can still see the activity lingering in the Recents for what seems like forever as you wait for it to be collected………*3 minutes later*………….now. 😞

This is a problem because:

1. It doesn’t look good for your app
2. It can be a major headache if you want to start up a new Picture in Picture instance because the old one is just lingering there.

If you watch to see what is getting called when the user “closes” a Picture in Picture window you see this being called :

override fun onStop() {
    super.onStop()
}

Logically, finish() is being called and that is one of the first LifecycleEvents part of that flow. But, not in the traditional sense.

Picture-in-Picture mode is unique, especially in the separate Activity case, because it acts like it is entirely its own app.

To get around this problem and clear out the VideoActivity quickly and efficiently implement this :

override fun onStop() {
    ....
    ....
    if ((Build.VERSION.SDK_INT >= Build.VERSION_CODES.N)
        && packageManager.hasSystemFeature(
        PackageManager.FEATURE_PICTURE_IN_PICTURE)) {
        finishAndRemoveTask()
    }
}

Done. Killed and removed appropriately.

Adding Media Controls to Picture-in-Picture

Start/Stop/Next

By default, Exoplayer + Picture in Picture does not give you the Picture in Picture media controls you see in the Youtube player for instance. Picture in Picture mode depends on a MediaSession to handle that communication. If you have written an AndroidTV application, audioplayer, or video-centric app before, you should be familiar with it. It can also be used for handling media controls from outside devices (like bluetooth headsets), widgets or advanced notifications with media controls. Here, you will be using the MediaSession Extension Library to take care of this. ⏯

Just add this code in the onStart() after handling your Exoplayer :

val mediaSession = MediaSessionCompat(this, packageName)
val mediaSessionConnector = MediaSessionConnector(mediaSession)
mediaSessionConnector.setPlayer(player, null)
mediaSession.isActive = true

One More Thing

Since Picture in Picture essentially acts like its own Application, it can live on without the Main App.

Yes, if you kill your Main App the Picture in Picture window will live on without you unless you kill it first. That means, if you have connecting information (such as multiple URLs or other streaming info) being sent and resetting the content of the Picture in Picture window that connection will be lost and it will become a ZOMBIE Picture in Picture WINDOW 😱.

What you can do to solve this is register an “Exit Event” Service to capture when the user Force Closes your app. In this Service, you need to override onTaskRemoved(rootIntent:Intent) and send a signal (RxJava Observable/Subscriber, Eventbus, Intent, etc.) which the Picture in Picture’d Activity can catch and call finishAndRemoveTask() to make a clean exit.

Code

There you have it folks! Lots of little gotchas taken care of.

Full code example with a DROP-IN VideoActivity.kt you can use right now.

http://bit.ly/exoplayerPIPexample

It includes some extra, useful features:

• Play/Pause/Resume/SeekTo controls for v ideo
• Show/Hide Exoplayer controls when the user goes in-out of Picture in Picture mode
• Rotation handling (fullscreen and vertical with no placement loss).

Drop-in Android Video — Exoplayer2 with Picture in Picture was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.