This class implements the media browser service interface as a standalone class for clearer separation of concerns (otherwise everything would need to go in PlayerService, since PlayerService overrides MediaBrowserServiceCompat)
Co-authored-by: Haggai Eran <haggai.eran@gmail.com>
Co-authored-by: Profpatsch <mail@profpatsch.de>
This class will receive the media URLs generated by [MediaBrowserImpl] and will start playback of the corresponding streams or playlists.
Co-authored-by: Haggai Eran <haggai.eran@gmail.com>
Co-authored-by: Profpatsch <mail@profpatsch.de>
This changes significantly how the MediaSessionCompat and MediaSessionConnector objects are used:
- now they are tied to the service and not to the player, and so they might be reused with multiple players (which should be allowed)
- now they can exist even if there is no player (which is fundamental to be able to answer media browser queries)
Some old Android devices have a broken WebView implementation, that can't execute the poToken code. This is now detected and the getWebClientPoToken return null instead of throwing an error in such a case, to allow the extractor to try to extract the video data even without a poToken.
This prevents non-abilities to fetch BotGuard challenge and send its
result with the jnn-pa.googleapis.com domain (domain block like done
on Pi-hole lists or DNS servers).
That's what the official website uses to send the challenge execution
result, however it uses InnerTube to fetch the challenge. Embeds
still use the jnn-pa.googleapis.com domain.
Also rename the makeJnnPaGoogleapisRequest method appropriately.
The headers should be overwritten in the same way, based on how
`.header` is the same as `.removeHeader().addHeader()`.
We weren’t closing the request resources after using them, potentially
leaking file handles. This will add autoclosing for both the request
and the body objects.
The change
b9dd7078ad3ae2ac1c20969fdd8b97736026b7dc
accidentally moved the `return` into the `{}`, so the logic would fall
through to
```
if (fragmentManager.getBackStackEntryCount() == 1) {`
```
and close the app even though there are still items on the
`VideoFragmentDetail` stack.
To reproduce:
Start video, enqueue another video, then start a third video (which
adds one entry to the stack), and press `back` on the expanded video.
This should keep the player open and go back to the first 2-video
queue, but it actually closes the app before this fix.
