Android dev blog

Announcing VLC 3.2

2019-12-03T00:00:00+00:00

VLC 3.2 is the second feature update for VLC 3. This update focused on polishing the user interface, adding some more features to Android TV and chromebooks and improving network browsing.

Under the hood, the VLC app is now (almost) 100% written in kotlin!

UI redesign, including player and TV browsers

Android TV

The browsing on Android TV has been made easier and more efficient.

You can now browse your media, filter them, jump to headers in a brand new screen.

When listening music, a Now playing line now displays media currently played

Players

On phones and tablets, the video player interface has been modernized and the controls have been reorganized.

The audio player design has also been improved.

Playlists

The playlist now has redesigned covers and can be easily modified.

Equalizer

The equalizer UI has been completely reworked and is now more pleasant to see and to use!

Media info

The media information screen has been redesigned to be clearer.

Chromebook

We added the support for desktop multi-selection with ctrl and shift. We also implemented most of the VLC desktop player keyboard shortcuts.

The support for external devices has also been improved.

You can read more about this on the Android developer story

Group videos by name feature

The videos can be grouped by name or by folder allowing you to find the right video quicker. This implementation is quite basic right now, next feature update will improve it to have grid view for any king of videos grouping.

Voice search on TV

The Medialibrary content is now searchable from TV launcher.

Cleaner media titles

The media titles are cleaned up for a better readability. Medialibrary now removes files extension and common garbage keywords from video files title.

Improved SMBv2/3 support

The SMB support has been improved to provide a better network browsing experience. There should be no conflict between SMBv1 and v2/v3 anymore. And login process has been improved too.

Under the hood

LibVLC has been updated, to get latest fixes, security patches and performance enhancements.

The whole Android app is now 100% written in kotlin! (but the medialibrary and libvlc API bindings remain in Java, to not induce kotlin dependency)

We also improved the architecture by continuing our Android Arch components integration and by the use of kotlin coroutines.

Announcing VLC 3.1 release!

2019-04-03T00:00:00+00:00

This is the first feature update in the VLC 3 cycle. It brings back Android auto and improves support of Oreo and Pie. This version only supports Android 4.2 and newer. This allows us to use up-to-date SDK and restore some features like Android Auto!

After 3.0 release, we could upgrade SDK and start a big refactoring. VLC now implements Android Arch Components, which helped us to drastically improve the application.
We basically rewrote the middle layer of VLC-Android from scratch, and made app architecture cleaner and safer. It results in a more stable app and more code shared between mobile and TV UIs.

Release cycles will become shorter now, v3.2 should be released before the summer. It will be easier for us to publish it and VLC will keep up to date.

Onboarding

Scanning your whole device storage is no longer mandatory. We have the will to keep VLC application lightweight, and some of you only use it as a player.
We heard that, and now you can choose between the classic big scanning, a folders selection or no medialibrary at all!
VLC still provides a file and network browser, if that’s enough for you.

Launcher shortcuts

On Android 7.1 and above, you can resume the last playlist you were listening to without even opening VLC 😌
Just long press on VLC icon on your device and shortcuts will pop up.

They are only static shortcuts for now, we plan to make it customizable.

Group videos by folders

There is a new option in Settings→Video→Group videos, videos can now be grouped by folder. It’s a convenient way to present you your collection.
That was a much asked feature.

Android Auto is back!

Because of Android 2 support, VLC-Android 3.0 was stuck on an old SDK and Android Auto had become too buggy.
It is now restored, enjoy your music with VLC on the road again!

Large media libraries

Among the huge refactoring we did on VLC-Android, we implementend pagination for audio collection. This offers a better support of large collections. Collections with like 10GB of MP3s no longer overflow VLC, it should handle the task now.

VLC won’t load all tracks at once anymore, it loads ‘pages’ of media and fills the list on the fly.

Home screen channel

You can now see last added videos from Android TV launcher (only for Android 8 and above), and even preview one when you focus on it!

File browser

Browser gains some neat additions.

First of all, OTG devices are now supported.

You also can now set any folder as favorite (not only network folders), so you will find them directly at root level of browser

To ease navigation, a breadcrumb is now displayed to show you where you are.

Other new goodies

Application:

Refactored subtitles downloader
Sorting preferences are now saved
A-B repeat
Manual orientation lock in video player
Podcast detection has been improved
Bottomsheet style for context menus
Playback notification is now persistent, even when app is closed by Android

TV:

Sort media
group videos by name

VLC:

AV1 software decoding.
SMB 2/3

For any feedback, you are welcome to join the VLC-Android community page!

Android runtime permissions in one (suspending) function

2019-03-09T00:00:00+00:00

This post offers a basic implementation of a single suspending function managing the runtime permission process.

Runtime permission API

If you are reading this, you should already know this API. It is only composed of requestPermissions method, and its related callback onRequestPermissionsResult. But this is a View-level API, not really convenient.

We still are lucky, this API is accessible from fragments, and that will allow us to make it way easier to use.

Headless Fragment

The trick is to make it a headless fragment, i.e. a fragment without a view. It’s still bound to its activity and can fire dialogs, that’s what we want.

override fun onCreate(savedInstanceState: Bundle?) {
    retainInstance = true
    requestPermissions(arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE), PERMISSION_STORAGE_CODE)
}

// No onCreateView() overriding

override fun onRequestPermissionsResult(requestCode: Int, permissions: Array<String>, grantResults: PermissionResults) {
    when (requestCode) {
        PERMISSION_STORAGE_CODE -> {
            if (grantResults.granted()) {
                deferredGrant.complete(true)
                exit()
                return
            } else if (shouldShowRequestPermissionRationale(...)) {
                // We insist
                return
            }
            deferredGrant.complete(false)
            exit()
        }
    }
}
protected fun exit() {
    retainInstance = false
    activity?.run {
        if (!isFinishing) supportFragmentManager
            .beginTransaction()
            .remove(this@BaseHeadlessFragment)
            .commitAllowingStateLoss()
    }
}

Our runtime permission implementation has become modular, it can be called from any activity just by starting this fragment. That’s a first step!

The permission grant result is handled by deferredGrant.complete(boolean), that’s how we can get a suspend function controlling our fragment.

Deferred behavior

We will now leverage it, and create a single function to launch this permission granting process and get its result.
For this, we use a CompletableDeferred, which is a Deferred like the one returned by the async function, but we can complete it by ourselves once we have our result.

All we have to do is to launch our fragment, prepare a CompletableDeferred and await for it.

Voilà! We have our function:

protected val deferredGrant = CompletableDeferred<Boolean>()

suspend fun awaitGrant() = deferredGrant.await()

companion object {
    suspend fun FragmentActivity.getStoragePermission() : Boolean {
        if (canReadStorage()) return true
        return launchFragment().awaitGrant()
    }
}

Profit

Usage is straghtforward:
From a coroutine, any activity can call getStoragePermission(), and it suspends until user has made its choice.
No callback anymore, and it’s callable from any Activity or Fragment in your app \o/

if (getStoragePermission()) {
    proceed()
} else {
    retreat()
}

While the user is asked for the permission you want for your app, coroutine execution is suspended by getStoragePermission() condition. Then, the relevant branch of this if expression will be executed.

Modern concurrency on Android with Kotlin

2018-07-13T00:00:00+00:00

Current Java/Android concurrency framework leads to callback hells and blocking states because we do not have any other simple way to guarantee thread safety.

With coroutines, kotlin brings a very efficient and complete framework to manage concurrency in a more performant and simple way.

Suspending vs blocking

Coroutines do not replace threads, it’s more like a framework to manage it.
Its philosophy is to define an execution context which allows to wait for background operations to complete, without blocking the original thread.

The goal here is to avoid callbacks and make concurrency easier.

Basic usage

Very simple first example, we launch a coroutine in the Main context (main thread). In it, we retrieve an image from the IO one, and process it back in Main.

launch(Dispatchers.Main) {
    val image = withContext(Dispatchers.IO) { getImage() } // Get from IO context
    imageView.setImageBitmap(image) // Back on main thread
}

Staightforward code, like a single threaded function. And while getImage runs in IO dedicated threadpool, the main thread is free for any other job! withContext function suspends the current coroutine while its action (getImage()) is running. As soon as getImage() returns and main looper is available, coroutine resumes on main thread, and imageView.setImageBitmap(image) is called.

Second example, we now want 2 background works done to use them. We will use the async/await duo to make them run in parallel and use their result in main thread as soon as both are ready:

val job = launch(Dispatchers.Main) {
    val deferred1 = async(Dispatchers.Default) { getFirstValue() }
    val deferred2 = async(Dispatchers.IO) { getSecondValue() }
    useValues(deferred1.await(), deferred2.await())
}

job.join() // suspends current coroutine until job is done

async is similar to launch but returns a deferred (which is the Kotlin equivalent of Future), so we can get its result with await(). Called with no parameter, it runs in current scope default context.

And once again, the main thread is free while we are waiting for our 2 values.

As you can see, launch funtion returns a Job that can be used to wait for the operation to be over, with the join() function. It works like in any other language, except that it suspends the coroutine instead of blocking the thread.

Dispatch

Dispatching is a key notion with coroutines, it’s the action to ‘jump’ from a thread to another one.

Let’s look at our current java equivalent of Main dispatching, which is runOnUiThread:

public final void runOnUiThread(Runnable action) {
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action); // Dispatch
    } else {
        action.run(); // Immediate execution
    }
}

Android implementation of Main context is a dispatcher based on a Handler. So this really is the matching implementation:

launch(Dispatchers.Main) { ... }
        vs
launch(Dispatchers.Main, CoroutineStart.UNDISPATCHED) { ... }


// Since kotlinx 0.26:
launch(Dispatchers.Main.immediate) { ... }

launch(Dispatchers.Main) posts a Runnable in a Handler, so its code execution is not immediate.
launch(Dispatchers.Main, CoroutineStart.UNDISPATCHED) will immediately execute its lambda expression in the current thread.

Dispatchers.Main guarantees that coroutine is dispatched on main thread when it resumes, and it uses a Handler as the native Android implementation to post in the application event loop.

Its actual implementation looks like:

val Main: HandlerDispatcher = HandlerContext(mainHandler, "Main")

To get a better understanding of Android dispatching, you can read this blog post on Understanding Android Core: Looper, Handler, and HandlerThread.

Coroutine context

A couroutine context (aka coroutine dispatcher) defines on which thread its code will execute, what to do in case of thrown exception and refers to a parent context, to propagate cancellation.

val job = Job()
val exceptionHandler = CoroutineExceptionHandler {
    coroutineContext, throwable -> whatever(throwable)
}

launch(Disaptchers.Default+exceptionHandler+job) { ... }

job.cancel() will cancel all coroutines that have job as a parent. And exceptionHandler will receive all thrown exceptions in these coroutines.

Scope

A coroutineScope makes errors handling easier:
If any child coroutine fails, the entire scope fails and all of children coroutines are cancelled.

In the async example, if the retrieval of a value failed, the other one continued then we would have a broken state to manage.
With a coroutineScope, useValues will be called only if both values retrieval succeeded. Also, if deferred2 fails, deferred1 is cancelled.

coroutineScope { 
    val deferred1 = async(Dispatchers.Default) { getFirstValue() }
    val deferred2 = async(Dispatchers.IO) { getSecondValue() }
    useValues(deferred1.await(), deferred2.await())
}

We also can “scope” an entire class to define its default CoroutineContext and leverage it.

Example of a class implementing CoroutineScope:

open class ScopedViewModel : ViewModel(), CoroutineScope {
    protected val job = Job()
    override val coroutineContext = Dispatchers.Main+job

    override fun onCleared() {
        super.onCleared()
        job.cancel()
    }
}

Launching coroutines in a CoroutineScope:

launch or async default dispatcher is now the current scope dispatcher. And we can still choose a different one the same way we did before.

launch {
    val foo = withContext(Dispatchers.IO) { … }
    // lambda runs within scope's CoroutineContext
    …
}

launch(Dispatchers.Default) {
    // lambda runs in default threadpool.
    …
}

Standalone coroutine launching (outside of any CoroutineScope):

GlobalScope.launch(Dispatchers.Main) {
    // lambda runs in main thread.
    …
}

We can even define a scope for application with dispatcher Main as default:

object AppScope : CoroutineScope by GlobalScope {
    override val coroutineContext = Dispatchers.Main.immediate
}

Notes

Coroutines limit Java interoperability
Confine mutablility to avoid locks
Coroutines are for ~~threading~~ waiting
- Avoid I/O in Dispatchers.Default (and Main…)
- Dispatchers.IO designed for this
Threads are expensive, so are single-thread contexts
Dispatchers.Default is based on a ForkJoinPool on Android 5+
Coroutines can be used via Channels

Callbacks and locks elimination with channels

Channel definition from JetBrain documentation:

A Channel is conceptually very similar to BlockingQueue. One key difference is that instead of a blocking put operation it has a suspending send (or a non-blocking offer), and instead of a blocking take operation it has a suspending receive.

Actors

Let’s start with a simple tool to use Channels, the Actor.

We already saw it in this blog with the DiffUtil kotlin implementation.

Actor is, yet again, very similar to Handler: we define a coroutine context (so, the tread where to execute actions) and it will execute it in a sequencial order.

Difference is it uses coroutines of course :), we can specify a capacity and executed code can suspend.

An actor will basically forward any order to a coroutine Channel. It will guaranty the order execution and confine operations in its context. It greatly helps to remove synchronize calls and keep all threads free!

protected val updateActor by lazy {
    actor<Update>(capacity = Channel.UNLIMITED) {
        for (update in channel) when (update) {
            Refresh -> updateList()
            is Filter -> filter.filter(update.query)
            is MediaUpdate -> updateItems(update.mediaList as List<T>)
            is MediaAddition -> addMedia(update.media as T)
            is MediaListAddition -> addMedia(update.mediaList as List<T>)
            is MediaRemoval -> removeMedia(update.media as T)
        }
    }
}
// usage
fun filter(query: String?) = updateActor.offer(Filter(query))
//or
suspend fun filter(query: String?) = updateActor.send(Filter(query))

In this example, we take advantage of the Kotlin sealed classes feature to select which action to execute.

sealed class Update
object Refresh : Update()
class Filter(val query: String?) : Update()
class MediaAddition(val media: Media) : Update()

And all this actions will be queued, they will never run in parallel. That’s a good way to achieve mutability confinement.

Android lifecycle + Coroutines

Actors can be profitable for Android UI management too, they can ease tasks cancellation and prevent overloading of the main thread.

Let’s implement it and call job.cancel() when activity is destroyed.

class MyActivity : AppCompatActivity(), CoroutineScope {
    protected val job = SupervisorJob() // the instance of a Job for this activity
    override val coroutineContext = Dispatchers.Main.immediate+job


    override fun onDestroy() {
        super.onDestroy()
        job.cancel() // cancel the job when activity is destroyed
    }
}

A SupervisorJob is similar to a regular Job with the only exception that cancellation is propagated only downwards.
So we do not cancel all coroutines in the Activity, when one fails.

A bit better, with an extension function, we can make this CoroutineContext accessible from any View of a CoroutineScope

val View.coroutineContext: CoroutineContext?
    get() = (context as? CoroutineScope)?.coroutineContext

We can now combine all this, setOnClick function creates a conflated actor to manage its onClick actions. In case of multiple clicks, intermediates actions will be ignored, preventing any ANR, and these actions will be executed in Activity’s scope. So it will be cancelled when Activity` is destroyed 😎

fun View.setOnClick(action: suspend () -> Unit) {
    // launch one actor as a parent of the context job
    val scope = (context as? CoroutineScope)?: AppScope
    val eventActor = scope.actor<Unit>(capacity = Channel.CONFLATED) {
        for (event in channel) action()
    }
    // install a listener to activate this actor
    setOnClickListener { eventActor.offer(Unit) }
}

In this example, we set the Channel as Conflated to ignore events when we have too much of them. You can change it to Channel.UNLIMITED if you prefer to queue events without missing anyone of them, but still protect your app from ANR

We also can combine coroutines and Lifecycle frameworks to automate UI tasks cancellation:

val LifecycleOwner.untilDestroy: Job get() {
    val job = Job()

    lifecycle.addObserver(object: LifecycleObserver {
        @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
        fun onDestroy() { job.cancel() }
    })

    return job
}
//usage
GlobalScope.launch(Dispatchers.Main, parent = untilDestroy) {
    /* amazing things happen here! */
}

Callbacks mitigation (Part 1)

Example of a callback based API use transformed thank to a Channel.

API works like this:

requestBrowsing(url, listener) triggers the parsing of folder at url address.
The listener receives onMediaAdded(media: Media) for each discovered media in this folder.
listener.onBrowseEnd() is called once folder parsing is done.

Here is the old refresh function in VLC browser provider:

private val refreshList = mutableListOf<Media>()

fun refresh() = requestBrowsing(url, refreshListener)

private val refreshListener = object : EventListener{
    override fun onMediaAdded(media: Media) {
        refreshList.add(media))
    }
    override fun onBrowseEnd() {
        val list = refreshList.toMutableList()
        refreshList.clear()
        launch {
            dataset.value = list
            parseSubDirectories()
        }
    }
}

How to improve this?

We create a channel, which will be initiated in refresh. Browser callbacks will now only forward media to this channel then close it.

Refresh function is now easier to understand. It sets the channel, calls the VLC browser then fills a list with the media and processes it.

Instead of the select or consumeEach functions, we can use for to wait for media and it will break once browserChannel is closed

private lateinit var browserChannel : Channel<Media>

override fun onMediaAdded(media: Media) {
    browserChannel.offer(media)
}

override fun onBrowseEnd() {
    browserChannel.close()
}

suspend fun refresh() {
    browserChannel = Channel(Channel.UNLIMITED)
    val refreshList = mutableListOf<Media>()
    requestBrowsing(url)
    //Suspends at every iteration to wait for media
    for (media in browserChannel) refreshList.add(media)
    //Channel has been closed
    dataset.value = refreshList
    parseSubDirectories()
}

Callbacks mitigation (Part 2): Retrofit

Second approach, we don’t use kotlinx-coroutines at all but the coroutine core framework.
Let’s see how coroutines really work!

retrofitSuspendCall function wraps a Retrofit Call request to make it a suspend function.
With suspendCoroutine we call the Call.enqueue method and suspend the coroutine. The provided callback will call continuation.resume(response) to resume the coroutine with the server response once received.

Then, we just have to bundle our Retrofit functions in retrofitSuspendCall to have a suspending functions returning the requests result.

suspend inline fun <reified T> retrofitSuspendCall(request: () -> Call<T>
) : Response<T> = suspendCoroutine { continuation ->
    request.invoke().enqueue(object : Callback<T> {
        override fun onResponse(call: Call<T>, response: Response<T>) {
            continuation.resume(response)
        }
        override fun onFailure(call: Call<T>, t: Throwable) {
            continuation.resumeWithException(t)
        }
    })
}

suspend fun browse(path: String?) = retrofitSuspendCall {
    ApiClient.browse(path)
}

// usage (within Main coroutine context)
livedata.value = Repo.browse(path)

This way, the network blocking call is done in Retrofit dedicated thread, coroutine is here to wait for the response, and in-app usage couldn’t be simpler!

This implementation is inspired by gildor/kotlin-coroutines-retrofit library, which makes it ready to use.
JakeWharton/retrofit2-kotlin-coroutines-adapter is also available with another implementation, for the same result.

To be continued

Channel framework can be used in many other ways, you can look at BroadcastChannel for more powerful implementations according to your needs.
We can also create channels with the Produce function.
It can also be useful for communication between UI components: an adapter can pass click events to its Fragment/Activity via a Channel or an Actor for example.

Announcing VLC 3.0 release!

2018-02-09T00:00:00+00:00

Version 2.5 has been a nice upgrade for VLC on Android. Now it’s been stabilized, and we are finally shipping the long awaited version 3.0!

VLC 3.0 is the first ever synchronized release between desktop application and mobile ports. Today, VLC is released everywhere, with the same version number and at the same time. It will be simpler for everyone, including VideoLAN developers 😊

On Android, this release mainly brings Chromecast feature, but it also repairs some lacks in priors versions. VLC on Android becomes more complete and it will continue!

Chromecast

Stop vertical videos now! Turn your phone horizontally when you record your children, because you’re going to show them to the family on the big screen now 📺

Chromecast support is finally here. As soon as a Chromecast is detected by VLC, you can send it a video or audio media and enjoy watching it!
If media codecs are supported by your Chromecast device, VLC only acts as a streaming server (which is battery consuming). If not, VLC will transcode and stream media, which is highly cpu and battery consuming.

Please consider Chromecast support beta for now, we will work on hardening it in the upcoming weeks thanks to your feedbacks.

VLC everywhere

VLC for Android is also available on different Android platforms like DeX, Chromebooks and Android auto.

You can now drop media files on VLC from other applications and use the right click on VLC media to get the context menu.

Android Auto allows you to easily command VLC with a simplified UI or even by voice while driving. You can ask “play Daft Punk (with VLC)” and Google Assistant will recognize whether it’s an artist, an album or a song you’re asking for and tell VLC to play it.

Playlist files

Version 2.5 suffered from a painful regression: The lack of playlist file support. This was due to the migration to our new multiplatform medialibrary. This is now fixed with this update, VLC can scan your .m3u again and show your playlists.

Features Catch-Up

Delete is back

VLC 2.5 had troubles dealing with delete on internal storage on Oreo, this is now resolved and new permissions access is well managed.

But the big news is the support of media deletion on external devices for Android Lollipop+ device. All you have to do is to select the sdcard/USB key in the awful Google dialog and then VLC can delete any file in it!
For this special process, we prepared a small tutorial in the app which looks like this:

Fast seek

‘Fast seek’ VLC option is now activated by default. VLC will now load faster when you change the current position during media playback. This can be deactivated in Settings → Video → ‘Enable fast seek option’

Subs (not) auto-loading

Not everyone wants subtitles, and we did not focus on this because most of the VideoLAN developers are European. But now you can deactivate automatic subtitles loading in Settings → Subtitles → ‘Auto load subtitles’.

Enjoy your videos without distraction now!

Why chromecast support took so long

Chromecast support is everywhere and VLC took years to get it, right, but there are plenty of good reasons for it:

First of all, VideoLAN is a nonprofit organization and not a company. There are few developers paid for making VLC, most of them do it in their free time. That’s how you get VLC for free and without any ads!

Also, VLC is 100% Open Source and Chromecast SDK isn’t: We had to develop our very own Chromecast stack by ourselves. This is also why there is no voice actions for VLC (except with Android Auto), we cannot use Google Play Services.

Furthermore, Chromecast is not designed to play local video files: When you watch a Youtube video, your phone is just a remote controller, nothing more. Chromecast streams the video from youtube.com.
That’s where it becomes complicated, Chromecast only supports very few codecs number, let’s say h264. Google ensures that your video is encoded in h264 format on youtube.com, so streaming is simple.
With VLC, you have media of any format. So VLC has to be a http server like youtube.com, and provide the video in a Chromecast compatible format. And of course in real time, which is challenging on Android because phones are less powerful than computers.

At last, VLC was not designed to display a video on another screen. It took time to properly redesign VLC to nicely support it. The good news is we did not make a Chromecast specific support, it is generic renderers: in the next months we can add UPnP support for example, to cast on any UPnP box or TV!

Announcing VLC 2.5 release!

2017-10-02T00:00:00+00:00

VLC is back on Play Store! Version 2.0 is more than 1 year old and will leave room for 2.5 which brings very interesting evolutions!

VLC for Android releases have been trapped in VLC 3.0 preparation and big media library refactoring black holes. So, there hasn’t been any update for 13 months, but development is still active and cool new stuff is coming!

This post will focus on features, implementations will be detailed in other blog posts (like the DiffUtil intro).

For now, let me introduce you to the new VLC for Android.

Minimum Android version is now Gingerbread.
FroYo support has been abandonned, these devices cannot access Google Play Store anymore.

UX evolutions

New dynamic UI

Video cards have been refactored, we now show you video details over its cover picture. This is a nicer presentation and gives room for displaying more videos at once.

Audio lists have been slightly lifted too. Others lists view have been reworked, like audio media, browsers and history. We got rid of cardview pattern, and got back to a more flat and clean design.

You can now select multiple items at the same time, to start a playlist for example.

Sort options have been spread to Audio and Browser sections.

Info page has also been redesigned with a fancy collapse effect for thumbnail or cover.

According to Material design principles, application has also become a bit more dynamic.

New Audio Player Style

Audio player background is now a blurred version of current art cover if available.

Picture-In-Picture mode

VLC implements PiP support for Oreo devices and even Nougat Android TVs. You can activate it from video advanced options during playback.

We also added an option to automatically continue video playback in PiP or background mode (audio only) while multitasking.
Go in VLC settings to activate it and video playback will switch to PiP when you’ll press HOME button.

Android TV

TV interface had its own minor lifting too. Background is filled with blurred covers and colors are warmer. Also I made long media titles scroll, I heard your (justified) frustration :)

Android Auto

This release will bring Android Auto compatibility.
You’ll be able to use VLC as your travel music player with easy browsing into you audio library, with the minimum possible distraction from driving.

VLC also supports voice actions on Android Auto:
You can ask “play Daft Punk (with VLC)” and Google Assistant will recognize whether it’s an artist, an album or a song you’re asking for and command VLC to play it.

Chrome OS support

VLC has been tested and adapted for latest Chrome OS running Android apps. You now have an awesome media application ready for your chromebook!

360° Videos support

VLC now supports 360° videos, you can change viewpoint by swiping or with remote control arrows.

Cardboard/VR mode is not available yet but we are working on it.

Search

Search has been split in two modes:

First step, the text you type in triggers a filtering in the current view. Exactly like in current playlist view.
If you want to do a global search, click on the SEARCH IN ALL MEDIALIBRARY button to show the new search view. This will bring detailed results grouped by video/artist/album/songs/genres/playlist.

Bonus: VLC is now compatible with voice search.
Asking Google Now “Search Artic Monkeys in VLC” will trigger a Arctic Monkeys search and show you this new search result screen.

Miscellaneous new features

DayNight mode integration
Audio boost in video
Equalizer custom presets
Save and resume position for podcasts & audiobooks
Restored double/long click on remote play to skip songs
Removed sound lowering on notification
Force previous song on audioplayer swipe
Fix audioplayer layout for black theme and RTL
Save subtitles delay and optionally audio delay for each file.
Support for devices with large aspect ratio, like G6 and S8 phones

Under the hood

MediaLibrary

That’s the most important change in this update, because it affects the whole application, but you should barely notice it…

VLC now uses medialibrary like VLC for Tizen (other VLC ports will follow).
It’s a C++ library, written by Hugo Beauzée-Luyssen, which parses storages for video/audio files and manages a sqlite database to model your media library (with album, artist, genre classification, etc..). It replaces the old system we had on Android which just saved media files with their metadata, we had no proper structure for media library.
Categories lists are now faster to show up, we don’t have to generate them at runtime. And this is all native code, which is faster than Java.
Beside this speed improvement, one of the main benefits of this medialibrary is to provide better search results.

For now we are focusing on the first scan performance to make it at least as fast as the previous system.

So, this library is aimed to be a common module of all VLC ports, wich means all debugging, performance and any improvement will benefit other platforms.

Next steps for this library will be media scrapping, and network scan:

Medialibrary will get information and illustrations for your media, so we’ll be able to present you a nice collection instead of an uncheerful files list. We will also group media by shows/seasons et genre/release year/whatever
You will be able to scan your NAS content to access your media easily.

This will make VLC a fully featured media center!

Playback performance & formats support

VLC core team worked hard too to bring performance improvements and some new features. Here are some highlights:

Adaptive (HLS/Dash) & TS playback improved
OpenGLES 2.0 is now used to render video (for software decoders & mediacodec)
Support for VP8/9/10 in MP4
HDMI passthrough

Future

We also plan to implement a feature to download media on your device, in order to sync your series episodes or songs from your NAS to your device.

We’d like to support videos playlists like we do with videos grouped by their common name prefix.

As previously stated, medialibrary will help VLC to turn into a real media center with fancy movies/tv shows presentation, and better artists/albums artworks.

At last, I started an extension API to help everyone eager to develop android applications that can provide content to VLC, and benefit from VLC Auto and TV implementation. As a start, we will release (with sources of course) extensions for podcasts subscriptions and Google Drive access.

Signing android releases with yubikey

2017-06-01T00:00:00+00:00

At VideoLAN, we recently changed our signing procedure to leverage our security keys. As explained on Yubico website, Android signing is quite easy.

With this method, I can now sign the VLC releases on any of my computers without duplicating the keystore file. And keystore password is replaced by my Yubikey PIN.

Here is the precise process we went through to get this done.

Setup

Install dependencies

I am considering a Debian based distribution with open JDK 8 installed for this post.

First of all, we need to install the pkcs11 opensc lib and the zipalign tool

sudo apt-get install opensc-pkcs11 zipalign

zipalign can also be found in android_sdk_path/build-tools/version/

Prepare configuration file

Then, we prepare the pkcs11 configuration. Let’s create file pkcs11_java.cfg and fill it with:

name = OpenSC-PKCS11
description = SunPKCS11 via OpenSC
library = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
slotListIndex = 0

Yubico How-To advises slotListIndex = 1, but I had to set it to 0 to make it work with my Yubikey 4.

Let’s assume we save it in: ~/.pkcs11_java.cfg

Set up your own management key

If you did not set your management key, you have to do it now:

key=`dd if=/dev/random bs=1 count=24 2>/dev/null | hexdump -v -e '/1 "%02X"'`
echo $key
yubico-piv-tool -a set-mgm-key -n $key

Change your PIN

Same for PIN setting, default one is 123456

yubico-piv-tool -a change-pin -P 123456 -N <NEW PIN>

Keystore import

Now it’s time to import our keystore to the key PIV slot.

keytool -importkeystore -srckeystore mykeystore.keystore -destkeystore mykeystorey.p12 -srcstoretype jks -deststoretype pkcs12
yubico-piv-tool -s 9a -a import-key -a import-cert -i mykeystorey.p12 -K PKCS12 -k

You will be asked to type in the keystore password, then the certificate management key.

Starting from now, you won’t have to type the keystore password anymore but your Yubikey PIN.

We can check that our key is ready to sign apps:

keytool -providerClass sun.security.pkcs11.SunPKCS11 -providerArg ~/.pkcs11_java.cfg -keystore NONE -storetype PKCS11 -list -J-Djava.security.debug=sunpkcs11

This is the Yubikey PIN you have to type-in now.
And don’t forget to touch it if you enabled the ‘touch-to-sign’ option.

App signature

In build tools 24.0.3 Google has released apksigner, a new signature tool with convenient arguments like --min-sdk-version to get sure the application signature is correct.

Until release (26.0.1) apksigner doesn’t handle pkcs11 protocol correctly. So, you need to use build-tools 26.0.1+

We now have to get an unsigned apk, so we must tell gradle to not apply any signing config for release builds

 buildTypes {
        release {
            signingConfig null
            //…
        }
    }

Finally we can sign an apk without our keystore, we just need the Yubikey to be plugged and fire up apksigner

ANDROID_SDK_PATH/build-tools/BUILD_TOOLS_VERSION/apksigner sign --ks NONE --ks-pass "pass:$YUBI_PIN" \
--min-sdk-version 9 --provider-class sun.security.pkcs11.SunPKCS11 \
--provider-arg pkcs11_java.cfg --ks-type PKCS11 app.apk

We can now verify the package is signed:

apksigner verify --verbose app.apk

verify accepts --min-sdk-version and --max-sdk-version to ensure your users won’t get 103 Play Store error code once the app is released.

Scripting

Here is the full bash script I use to sign all my apks at once:

#! /bin/sh

echo "Please enter Yubikey PIN code "
stty -echo
trap 'stty echo' EXIT
read -p 'PIN: ' YUBI_PIN
stty echo
trap - EXIT

BT_VERSION="26.0.1"

echo "\nSigning apks\n"
for i in `ls *.apk`;
do
$ANDROID_SDK/build-tools/$BT_VERSION/zipalign 4 $i $i.tmp && mv -vf $i.tmp $i
$ANDROID_SDK/build-tools/$BT_VERSION/apksigner sign --ks NONE \
        --ks-pass "pass:$YUBI_PIN" --min-sdk-version 9 \
        --max-sdk-version 26 --provider-class sun.security.pkcs11.SunPKCS11 \
        --provider-arg ~/.pkcs11_java.cfg --ks-type PKCS11 $i
done
unset YUBI_PIN

Jarsigner

We can also use jarsigner to sign your apk:

jarsigner -providerClass sun.security.pkcs11.SunPKCS11 -providerArg ~/.pkcs11_java.cfg \
  -keystore NONE -storetype PKCS11 -sigalg SHA1withRSA -digestalg SHA1 \
  app.apk "Certificate for PIV Authentication"

The -sigalg SHA1withRSA -digestalg SHA1 parameters are needed because we support old devices. If you don’t support Android 4.2 and older you can rip it off.

With jarsigner, we need to zipalign the apk after signing them.

And verify the package is signed:

jarsigner -verify app.apk

DiffUtil off the UI thread

2017-03-13T00:00:00+00:00

As stated in the previous post, we do process all DiffUtil.DiffResult calculations in main thread to preserve adapter state consistency.
But in VLC, we have to deal with potentially HUGE datasets, so calculation could take some time.

Background calculation is mandatory then, and we have to preserve dataset consistency. I lost a few days trying different techniques then finally chose to stack updates within a queue and use it for all dataset operations, because it provides consistency safetyness.
I’ve been inspired by Jon F Hancock blog post to get this right.

To achieve background calculation and preserve data consistency, we now have to use our update() method for all dataset updates or manage the pending queue state manually.

Threading

update(list) method is now splitted in two, in order to allow queueing and recursivity:
update(list) which is now limited to queueing the new list and triggering internalUpdate(list) to do the actual job.

Notice all queue accesses or modifications are done in the main thread (for the same reasons that for dataset changes).

// Our queue with next dataset
private final ArrayDeque<Item[]> mPendingUpdates = new ArrayDeque<>();

@MainThread
void update(final ArrayList<Item> newList) {
    mPendingUpdates.add(newList);
    if (mPendingUpdates.size() == 1)
        internalUpdate(newList); //no pending update, let's go
}

//private method, called exclusively by update()
private void internalUpdate(final ArrayList<Item> newList) {
    VLCApplication.runBackground(new Runnable() {
        @Override
        public void run() {
            final DiffUtil.DiffResult result = DiffUtil.calculateDiff(new MediaItemDiffCallback(mDataset, newList), false);
            //back to main thread for the update
            VLCApplication.runOnMainThread(new Runnable() {
                @Override
                public void run() {
                    mDataset = newList;
                    result.dispatchUpdatesTo(BaseBrowserAdapter.this);
                    //We are done with this dataset
                    mPendingUpdates.remove();
                    //Process the next queued dataset if any
                    if (!mPendingUpdates.isEmpty())
                        internalUpdate(mPendingUpdates.peek());
                }
            });
        }
    });
}

For simple actions, like item insertion/removal, we must check the mPendingUpdates state. Either we handle it, either we use update(list) in order to respect the queue process we just set. So, we have to copy the most recent dataset, add/remove the item then call update(list).

Using mDataset as the current reference state can be a mistake, if mPendingUpdates is not empty, another dataset will be processed between mDataset and our new list with item added or removed. In this case, we have to peek the last list from mPendingUpdates.

@MainThread
void addItem(Item item) {
  ArrayList<Item> newList = new ArrayList<>(mPendingUpdates.isEmpty() ? mDataset : mPendingUpdates.peekLast());
  newList.add(item);
  update(newList);
}

For item removal, I’d recommend to just avoid calling it with position only, prefer to pass the item reference. Because the position value is likely to be wrong if there is a pending update at this time.

Skip queued updates

In case you can receive a bunch of updates while DiffUtil is calculating the DiffUtil.DiffResult, you get a stack of new datasets to process. Let’s skip to the last one: as we made sure they are consistent we can do it. That’s just factorizing the updates.
We have to clear the mPendingUpdates queue from all its elements but the last one.

Here is our current queue processing:

mPendingUpdates.remove();
if (!mPendingUpdates.isEmpty())
    internalUpdate(mPendingUpdates.peek());

Which becomes:

mPendingUpdates.remove();
if (!mPendingUpdates.isEmpty()) {
    if (mPendingUpdates.size() > 1) { // more than one update queued
        ArrayList<Item> lastList = mPendingUpdates.peekLast();
        mPendingUpdates.clear();
        mPendingUpdates.add(lastList);
    }
    internalUpdate(mPendingUpdates.peek());
}

Code factorization

Here is my base adapter class, dedicated to pending queue management. Children classes just need to call update(newList) for any update.
(I chose to not specify List<T> because I also use arrays)

public abstract class BaseQueuedAdapter <T, VH extends RecyclerView.ViewHolder> extends RecyclerView.Adapter<VH> {

    protected T mDataset;
    private final ArrayDeque<T> mPendingUpdates = new ArrayDeque<>();
    final Handler mHandler = new Handler(Looper.getMainLooper());

    @MainThread
    public boolean hasPendingUpdates() {
        return !mPendingUpdates.isEmpty();
    }

    @MainThread
    public T peekLast() {
        return mPendingUpdates.isEmpty() ? mDataset : mPendingUpdates.peekLast();
    }

    @MainThread
    public void update(final T items) {
        mPendingUpdates.add(items);
        if (mPendingUpdates.size() == 1)
            internalUpdate(items);
    }

    private void internalUpdate(final T newList) {
        new thread(new Runnable() {
            @Override
            public void run() {
                final DiffUtil.DiffResult result = DiffUtil.calculateDiff(new ItemDiffCallback(mDataList, newList), false);
                mHandler.post(new Runnable() {
                    @Override
                    public void run() {
                        mDataset = newList;
                        result.dispatchUpdatesTo(BaseQueuedAdapter.this);
                        processQueue();
                    }
                });
            }
        }).start();
    }

    @MainThread
    private void processQueue() {
        mPendingUpdates.remove();
        if (!mPendingUpdates.isEmpty()) {
            if (mPendingUpdates.size() > 1) {
                T lastList = mPendingUpdates.peekLast();
                mPendingUpdates.clear();
                mPendingUpdates.add(lastList);
            }
            internalUpdate(mPendingUpdates.peek());
        }
    }
}

My adapter class becomes:

public class MyAdapter extends BaseQueuedAdapter<List<Item>, MyAdapter.ViewHolder>

That’s it, we now have asynchronous and classy RecyclerView updates without extra boilerplate 😎

The Kotlin way

Because we can do better with Kotlin!

First of all, we use an Actor, to easily operate a Channel, so we can send this one every single update we want. It’s capacity is set to CONFLATED which means that the channel will bufffer at most one element: when busy, it will just replace the buffered element by the new one we provided. That’s a smarter way to process our waiting queue.

When ready, eventActor will call internalUpdate in the CommonPool, in which we still do the calculation.
UI dispatch is done in launch higher-order function with UI as parameter so we can join() it:
In Kotlin, join() doesn’t block the current thread but it suspends it while UI job is done, so no thread blocking!

And as a bonus, we gained thread safety! We can call update(list) from any thread now.

abstract class DiffUtilAdapter<D, VH : RecyclerView.ViewHolder> : RecyclerView.Adapter<VH>() {

    protected var mDataset: List<D> = listOf()
    private val diffCallback by lazy(LazyThreadSafetyMode.NONE) { DiffCallback() }
    private val eventActor = actor<List<D>>(capacity = Channel.CONFLATED) { for (list in channel) internalUpdate(list) }

    fun update (list: List<D>) = eventActor.offer(list)

    private suspend fun internalUpdate(list: List<D>) {
        val result = DiffUtil.calculateDiff(diffCallback.apply { newList = list }, false)
        launch(UI) {
            mDataset = list
            result.dispatchUpdatesTo(this@DiffUtilAdapter)
        }.join()
    }

    private inner class DiffCallback : DiffUtil.Callback() {
        lateinit var newList: List<D>
        override fun getOldListSize() = mDataset.size
        override fun getNewListSize() = newList.size
        override fun areContentsTheSame(oldItemPosition : Int, newItemPosition : Int) = true
        override fun areItemsTheSame(oldItemPosition : Int, newItemPosition : Int) = mDataset[oldItemPosition] == newList[newItemPosition]
    }
}

Recyclerview++ with DiffUtil

2017-03-03T00:00:00+00:00

DiffUtil is an AppCompat utility class developed to ease Recyclerview updates.

You just pass it the new dataset and current one and it automagically handles all the notifyItemRange* events to provide cool RecyclerView animations or subtle item updates (like a single progressbar update instead of the whole item layout rebinding).

Principles

Provide your custom DiffUtil.Callback fed with the old and new datasets to the DiffUtil.calculateDiff method, and obtain a DiffUtil.DiffResult which contains all the necessary operations (additions, deletions and optionnally moves) to get from old list to the new one.
Update your dataset
Call diffResult.dispatchUpdatesTo(recyclerviewAdapter), your recyclerviewAdapter will receive all the corresponding notifyItemRange* events and benefit from shiny recyclerview animations!

It is strongly advised to run all dataset operations in the main thread, to ensure consistency. And for now (until next post), DiffUtil calculations will also be run in the main thread for consistency concern.

Basic usage

Here is a simple example of DiffUtil powered recyclerview update method in browsers adapter:

@MainThread
void update(final ArrayList<Item> newList) {
    final DiffUtil.DiffResult result = DiffUtil.calculateDiff(
                new MediaItemDiffCallback(mDataset, newList), false);
    mDataset = newList;
    result.dispatchUpdatesTo(MyAdapter.this);
}

You can see we only have these 3 basic steps.
With mDataset the current dataset, newList the new one, and false the parameter value for moves detection, we don’t handle it for now.

The base DiffUtil.Callback implementation we use:

public class MediaItemDiffCallback extends DiffUtil.Callback {
    protected Item[] oldList, newList;

    public MediaItemDiffCallback(Item[] oldList, Item[] newList) {
        this.oldList = oldList;
        this.newList = newList;
    }

    @Override
    public int getOldListSize() {
        return oldList == null ? 0 : oldList.length;
    }

    @Override
    public int getNewListSize() {
        return newList == null ? 0 : newList.length;
    }

    @Override
    public boolean areItemsTheSame(int oldItemPosition, int newItemPosition) {
        return oldList[oldItemPosition].equals(newList[newItemPosition]);
    }

    @Override
    public boolean areContentsTheSame(int oldItemPosition, int newItemPosition) {
        return true;
    }
}

For now, areContentsTheSame always returns true, we’ll see later how to use it for smarter updates. Let’s focus on areItemsTheSame: this is simply a equals-ish method to determine if two instances correspond to the same model view.

Now, with this diffResult, for every item insertion and deletion we get the precise adapter notification.
Typical application is list feeding, all new items are nicely inserted or removed which makes fancy animations to happen, like if we had set all the notifyItemInserted and notifyItemDeleted one by one.

A nicer use case is list/grid filtering. Here’s the result, with that simple update(newList) call:

Finer items updates

In video section, we want to update an item view if media progress or thumbnail has changed, but we don’t want to completely rebind its view.
Until VLC 2.0.6, you could experience a flicker of the video you were watching once getting back from video player. That’s because media progress had changed and we blindly updated the whole view (which triggered thumbnail reloading).

Here is the DiffUtil.Callback specific to video grid which not only checks if items are the same, but if their content has changed also:

private class VideoItemDiffCallback extends DiffUtil.Callback {
        List<Item> oldList, newList;
        VideoItemDiffCallback(List<Item> oldList, List<Item> newList) {
            this.oldList = oldList;
            this.newList = newList;
        }

        @Override
        public int getOldListSize() {
            return oldList == null ? 0 : oldList.size();
        }

        @Override
        public int getNewListSize() {
            return newList == null ? 0 : newList.size();
        }

        @Override
        public boolean areItemsTheSame(int oldItemPosition, int newItemPosition) {
            return oldList.get(oldItemPosition).equals(newList.get(newItemPosition));
        }

        @Override
        public boolean areContentsTheSame(int oldItemPosition, int newItemPosition) {
            Item oldItem = oldList.get(oldItemPosition);
            Item newItem = newList.get(newItemPosition);
            return oldItem.getTime() == newItem.getTime() &&
              TextUtils.equals(oldItem.getArtworkMrl(), newItem.getArtworkMrl());
        }

        @Nullable
        @Override
        public Object getChangePayload(int oldItemPosition, int newItemPosition) {
            Item oldItem = oldList.get(oldItemPosition);
            Item newItem = newList.get(newItemPosition);
            if (oldItem.getTime() != newItem.getTime())
                return UPDATE_TIME;
            else
                return UPDATE_THUMB;
        }
    }

If areItemsTheSame returns true, areContentsTheSame is called for the same items. areContentsTheSame returns false if we detect small changes we want to propagate to the UI without totally rebinding the concerned item view. In our case this is two Item instances representing the same video file but artwork URL or time value has changed.

If areContentsTheSame returns false, getChangePayload is called for the same items. We define here the updated value and return it. The dispatch util will call notifyItemChanged(position, payload) with this value. Then it’s up to the adapter to manage the update:

In the adapter, we override onBindViewHolder(holder, position, payload) to achieve this:

@Override
public void onBindViewHolder(ViewHolder holder, int position, List<Object> payloads) {
    if (payloads.isEmpty()) {
        onBindViewHolder(holder, position);
    } else {
        MediaWrapper media = mVideos.get(position);
        for (Object data : payloads) {
          switch ((int) data) {
            case UPDATE_THUMB:
                AsyncImageLoader.loadPicture(holder.thumbView, media);
                break;
            case UPDATE_TIME:
                fillView(holder, media);
                break;
          }
        }
    }
}

onBindViewHolder(holder, position, payloads) makes the smart move and updates the related view(s), instead of rebinding the whole item view. In our case, we load the thumb in the ImageView or we regenerate the progress string and update the progress bar with fillView().
As the dataSet is already updated, we don’t need to pass the values here, so I opted for constants refering to the different actions.

DiffUtil process scheme

Moves detection

The DiffUtil.calculateDiff algorithm can optionnally do a second pass to look for items movements between the old and new lists. If the sort order doesn’t change, it is useless to do it.
In VLC it’s only interesting in video grid for now, so we call:

DiffUtil.calculateDiff(new VideoItemDiffCallback(oldList, newList), detectMoves);

Where detectMoves variable is a boolean which is set to true only in case of video resorting call, in other cases we spare the second pass. Thanks to it, animations are fancier with only moving cards. Without this moves detection we’d get disappearing and reappearing cards.

Resorting videos with moves detection:

Without moves detection:

Going further

We now master diffutil, but we can do better and get calculation out of UI thread.
Rendez-vous to the second part of this post to check it out.

Announcing VLC 2.1 beta release!

2017-02-23T00:00:00+00:00

Not so much activity on Play Store since v2.0.6 release.
I’ve been quite busy but VLC keeps going on with very interesting evolutions!
This post will only deal with features, not their implementation. I will later publish other posts, more interesting for developers, about it.

2.1.x version name will be used for beta only, we’ll decide later which version the stable release will be.

To get it you need to join the beta program, and you’ll receive it like a normal update.

For now, let me introduce you to the new VLC for Android.

UX evolutions

Presentation

Video cards have been refactored, we now show you video informations over its cover picture. This is a nicer presentation and gives room for displaying more videos at once. Others lists view have been reworked too, like audio media, browsers and history. We got rid of cardview pattern, and got back to a more flat and clean design.

Audio lists have been a bit lifted too but this change is lighter.

Info page has also been redesigned with a fancy collapse effect for thumbnail or cover.

New Audio Player Style

Audio player background is now a blurred version of current art cover if available.

Dynamic UI

Scrolling

The action bar will now hide when your scroll your media lists, to save the more useful space possible while you’re looking for your media.

Album view has been revamped to become more #Material and now serves for playlists too

Updating content

Thanks to the DiffUtil tool from Appcompat library, grids/lists updates are now animated and more efficient.
One disturbing side effect is when you refresh and there’s no change in your media library. You won’t see any update, not even any flickering.
But the cool thing is whith actual content update, like during media scan or filtering the current view with the new search UX, insertions/deletions and position changes are animated:

TV design

TV interface had its own lifting too, nothing really impressive here. Colors are less depressive and we make long media titles scroll, I heard your (justified) frustration :)

The interesting new feature on TV is the Picture-In-Picture (aka PIP) mode, available for all Android TVs powered by Android 7+.
It’s really like our popup mode in classic phone/tablet interface (so we used the very same icon in video advanced options for PIP).
You can still watch your video while using another application.

360° Videos support

VLC now supports 360° videos, you can change viewpoint by swiping or with remote control arrows.

Cardboard/VR mode is not available yet but we are working on it.

Search

Search has been splitted in two modes:

First step, the text you type in triggers a filtering in the current view. Exaclty like in current playlist view.

Then, if you want to do a global search, click on the SEARCH IN ALL MEDIALIBRARY button to show the new search activity. Which will bring detailed results grouped by video/artist/album/songs/genres/playlist

Bonus: VLC will now be compatible with voice search.
Asking Google Now “Search game in VLC” will trigger a game search and show you this new search result screen.

Android Auto

VLC also supports voice actions on Android Auto:
You can ask “play Daft Punk” and Google Assistant will recognize whether it’s an artist, an album or a song you’re asking for and trigger VLC to play it.

Action mode

You can now select multiple items by long press on them (classic context menu is still available with the three dots icon) and enjoy actions like play it all or add selection to playlist
Actions available depend on media type and selection count.

This is very handy for starting or creating a playlist.

Miscellaneous new features

DayNight mode integration
Restored double/long click on remote play to skip songs
Removed sound lowering on notification
Force previous song on audioplayer swipe
Fix audioplayer layout for black theme and RTL
Save subtitles delay and optionally audio delay for each file.
Support for LG devices with 18:9 aspect ratio

Under the hood

MediaLibrary

That’s the most important change in this update, because it affects the whole application, but you should barely notice it…

VLC now uses medialibrary like VLC for Tizen, others VLC ports will follow.
It’s a C++ library, written by Hugo Beauzée-Luyssen, which parses storages for video/audio files and manages a sqlite database to model your media library (with album, artist, genre classification, etc..). It replaces the old system we had on Android which just saved media files with their metadata, we had no proper structure for media library.
So these categories listing are now faster, we don’t have to generate categories at runtime. And this is all native code, which is faster than Java.
Beside this speed improvement, one of the main benefits of this medialibrary is to provide better search results

For now we are focusing on the first scan performance to make it at least as fast as the previous system.

So, this library is aimed to be a common module of all VLC ports, wich means all debugging, performance and any improvement will benefit other platforms.

Next steps for this library will be media scrapping, and network scan:

Medialibrary will get informations and illustrations for your media, so we’ll be able to present you a nice collection, and not files list anymore. We will also group media by shows/seasons et genre/release year/whatever
You will be able to scan your NAS content to access your media easily.

Playback performance & formats support

VLC core team worked hard too to bring performance improvements and some new features. Here are some highlights:

360° videos support
Adaptive (HLS/Dash) & TS playback improved
OpenGLES 2.0 is now used to render video (for software decoders & mediacodec)
Support for VP8/9/10 in MP4
e-AC3 HDMI passthrough

Future

We also plan to implement a feature to download media on your device, in order to sync your series episodes or songs from your NAS to your device.

We’d like to support videos playlists like we do with videos grouped by their common name prefix.

As previously stated, medialibrary will allow to make VLC a real media center with fancy movies/tv shows presentation, and better artists/albums illustrations.

At last, I started an extension API in order for everyone to develop android applications which will provide content to VLC. For example, we will release (with sources of course) extensions bringing support of podcasts subscriptions and Google Drive access.