Exoplayer: Access to ExoPlayer from the main thread of another process

[thesquare12]

I want to update the Exoplayer version from 2.5.3 to 2.9.2.
I have encountered the following logs:

Player is accessed on the wrong thread. See https://google.github.io/ExoPlayer/faqs.html#what-do-player-is-accessed-on-the-wrong-thread-warnings-mean

As is known, access to ExoPlayer is through the main thread.
Probably because my app is using multi process. (Podcast App)
Calling Looper.getMainLooper () in two processes returns different address values.
That seems to mean that both processes have their own main thread.
Is there a solution for this?
Or, if anything I missed, I would appreciate it if you could let me know.

Version of ExoPlayer being used

2.9.2

Device(s) and version(s) of Android being used

Samsung Galaxy S7, 8.0

[tonihei]

Can you try accessing the player from one of the processes only? I suppose there must be some interprocess communication anyway, so it would be good if the second process could just forward all commands and requests to the player on one process and the answer (if needed) gets returned to the requesting process.

[tonihei]

I want to update the Exoplayer version from 2.5.3 to 2.9.2.

By the way, we always had the requirement that the player needs to be used from one thread, we now only started to warn users if they use ExoPlayer from another thread as this may cause unexpected exceptions.

[ojw28]

so it would be good if the second process could just forward all commands and requests to the player on one process and the answer (if needed) gets returned to the requesting process.

Isn't that the only way it could work anyway? The object must live in one process or another, not both. To be seeing that warning it must be the case that the player object is being accessed from multiple threads within that single process.

[thesquare12]

Looper.myLooper() returns null in verifyApplicationThread()

[ojw28]

The main thread has a looper, so Looper.myLooper() wont return null. The fact that it is implies that something is calling the player from another thread. If you can reproduce the issue locally it should be pretty easy to attach a debugger to work out where the rogue call is coming from, and on which thread.

[tonihei]

The log message should also have a stack trace which shows you exactly where the call is coming from.

[tonihei]

Closing due to inactivity. Also looks like the underlying problem was explained in all detail.

[davidaik]

I found that in a multi-process setup, the IPC calls are executed on a different thread than the main thread of the server. I have been getting the warning but I ignored it because I was completely sure that the IPC calls would execute on the Service's main thread. I was wrong.

[axitasavani]

i have same issue. i have used mutiple thread and getting warning and another thread is not proper working . below the logs:

SimpleExoPlayer: Player is accessed on the wrong thread. See https://google.github.io/ExoPlayer/faqs.html#what-do-player-is-accessed-on-the-wrong-thread-warnings-mean
    java.lang.IllegalStateException
        at com.google.android.exoplayer2.SimpleExoPlayer.verifyApplicationThread(SimpleExoPlayer.java:1190)
        at com.google.android.exoplayer2.SimpleExoPlayer.getCurrentWindowIndex(SimpleExoPlayer.java:1059)
        at com.google.android.exoplayer2.BasePlayer.seekTo(BasePlayer.java:42)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:193)
        at android.os.HandlerThread.run(HandlerThread.java:65)

continue below line is display in logcat :

SimpleExoPlayer: Player is accessed on the wrong thread. See https://google.github.io/ExoPlayer/faqs.html#what-do-player-is-accessed-on-the-wrong-thread-warnings-mean

please provide the more information to solved this issue .

[ojw28]

You should not be accessing the player on multiple threads. This is explained in the documentation.

[davidaik]

I worked around the issue by using a Handler in the main thread and posting runnables to it which would run the code that accesses the ExoPlayer instance.

[ojw28]

Yes, that's one approach. Application code is responsible for making sure that all calls to the player onto a single thread. It's not a workaround, but rather it's the correct thing to do :).

[axitasavani]

You should not be accessing the player on multiple threads. This is explained in the documentation.

i know we can't used multiple thread in main thread but this warning is only raised in OS-9 (Nokia).
i can't understand why in only OS-9?

[ojw28]

i know we can't used multiple thread in main thread but this warning is only raised in OS-9 (Nokia). i can't understand why in only OS-9?

The ExoPlayer library doesn't show the warning or not based on what OS version the app is running on, so if you're seeing the warning only on a particular OS version, that means your application code is calling ExoPlayer from the wrong thread only on that OS version. ExoPlayer has no control over which thread you call it on, so this is something you need to debug on your side.

[axitasavani]

OK. i'll try to find what is wrong.thank you.

[thesquare12]

I worked around the issue by using a Handler in the main thread and posting runnables to it which would run the code that accesses the ExoPlayer instance.

I would appreciate if you share how you implement this.

[davidaik]

@thesquare12 What I did involves these steps.

1. Create a Handler object in the same thread where you will create your ExoPlayer object.

private Handler mHandler = new Handler();

1. Create an object to use as lock - to ensure that ExoPlayer accessing methods are executed one at a time.

   private final Object mMotherOfAllLocks = new Object();

2. Create Runnable objects which will contain all our ExoPlayer accessing code.

   private class ExoPlayerAccessingRunnable implements Runnable {
   private CountDownLatch latch; // Used to notify of completion
   ExoPlayerAccessingRunnable(CountDownLatch l) {
   latch = l;
   }
   @Override
   public void run() {
   // Do stuff with ExoPlayer here
   // Do more stuff with ExoPlayer here.
   latch.countDown(); // Notify completion here
   }
   }

3. Write methods that will execute the Runnable above.

   public void doSomethingWithExoPlayer() { // Call this from any thread
   synchronized (mMotherOfAllLocks) {
   CountDownLatch latch = new CountDownLatch(1);
   ExoPlayerAccessingRunnable runnable = new ExoPlayerAccessingRunnable(latch);
   mHandler.post(runnable); // This will make the runnable execute on the thread
   // that it was created in, i.e. The main thread.
   try {
   latch.await();
   } catch (InterruptedException e) {
   }
   }
   }

4. Every time you need to do something with ExoPlayer from any Thread, just directly call doSomethingWithExoPlayer()

I hope you get something from this. If you need to "return" data from the ExoPlayer() you'll need more clever stuff :P

[tonihei]

@davidaik This contains way too many locks and latches.

@thesquare12
You can just do something like this:

// Create Handler for main thread (can be reused).
Handler mainThreadHandler = new Handler(Looper.getMainLooper());
// Post message to do something with ExoPlayer on main thread.
mainThreadHandler.post(() -> exoPlayer.seekTo(newPosition));

And if you need information on your background thread, listen to events or send information directly:

/* EventListener */
public void onPlayerStateChanged(...) {
  backgroundThreadHandler.post(() -> stateChanged());
}

long currentPosition = exoPlayer.getCurrentPosition();
backgroundThreadHandler.post(() -> handlePosition(currentPosition));

[davidaik]

@tonihei That's true. I could probably do without the lock, but my own project requires the latch. I should have removed those before writing here.