Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[droid] - add pvraddons to depends #1527

wants to merge 2 commits into


None yet
6 participants

Memphiz commented Oct 3, 2012

Basically what the title says. I'm not sure if this will work on android. IIRC the libs need the ".so" extension or so? But maybe you can use this as a base.

Its based on darwin depends

@theuni RFC

i can see it's based on the darwin deps ;-)

this will need a bump cause of a minor api change


theuni commented on 26774ea Oct 7, 2012

This needs quite a few changes in order to not break parallel build. I'll push a patch in the next few hours when i can jump to my android tree.


Memphiz replied Oct 7, 2012

Cool :). I thought it would need some more changes at runtime too no?


theuni commented Oct 8, 2012

@Memphiz See here for the changes needed on the pvr-side to get this rolling: opdenkamp/xbmc-pvr-addons#52

For the XBMC side, I took your PR and changed it up a bit to get things into the right places: https://github.com/theuni/xbmc/commits/android-pvr


Memphiz commented Oct 9, 2012

Ok - i should get my odroidx in a few days (once that stupid trans-o-flex got it that i have rerouted it to my working adress grr) and then i will test the shit out of it :)


fape commented Oct 10, 2012

I compiled without error. But I can't enable addons for pvr. Log: http://pastebin.com/BVtj1Zih (default build, fresh install, Seby 0.7.1 rom: android 4.0.3)


Memphiz commented Oct 10, 2012

With the patches from theuni on both XBMC and pvr-addons side? ^^

If you only tried the initial pull request - its likly that it doesn't work ... was more a RFC and for getting things rolling.


fape commented Oct 11, 2012

Yes, I tried with the latest 3 commit from https://github.com/theuni/xbmc/commits/android-pvr. But I bumped the version in Makefile for use theuni's pvr-addons commits.


theuni commented Oct 12, 2012

Yea, need to bump the version to after the merge on the pvr side.

@fape this doesn't include any work needed to actually get them loaded, this is just build/install.


theuni commented Oct 12, 2012

I've had a look at the pvr addons, and it seems as though they should load without having to go through a wrapped soloader (whew!). This is because pvr addons build everything in static, and only link to base system libs.

The immediate problem will be finding the addons. We can install to 2 places: system libs and profile. If we ship addons with the default apk, which we almost certainly will, they'll need to be installed in lib/$platform/ in the apk. This is an android-ism and is necessary to ensure that we don't break multi-platform. This PR handles that already.

However, the PVR addons expect to find the lib in the same directory as the addon.xml and the rest. For user-installed binary addons (down the road) that will be fine, as there's no concern of multi-arch when we're already installed. But for pre-packaged addons, we'll have to add an android case to look for them in the right place. The trick here is actually to NOT give it a path. So rather than loading "foo/bar/libaddon.so", we just need to load "libaddon.so".


theuni commented Oct 12, 2012

There's one more Android gotcha. The reasonable thing would be to try to load from the addon dir first, and if it's not found, load it without a path. However, due to bionic fun, if you try to load foo/libaddon.so and it fails, you can never load libaddon.so for the life of the program, even if it would now succeed. Bionic caches dlopen failures.

So we need to be sure to stat first and verify that the file exists before trying to load it.


elupus commented Oct 12, 2012

Add a wrapper for dlopen perhaps, to avoid the gothca?


theuni commented Oct 12, 2012

@elupus xbmc/android/loader ;)

In this case it will need to be in the pvr addons as they're trying to dlopen the other addons, so our in-xbmc wrapper doesn't do us any good. And if the wrapper would do nothing more than a quick stat before open, I don't see any reason to abstract that out as it's not a bad sanity check for other platforms as well I'd think?


theuni commented Oct 12, 2012

On second thought, I'm not sure if this is what you meant, but an actual __wrap_dlopen could be nicer than messing with the default paths. I'll experiment a bit, thanks for the advice.


mikrohard commented Oct 12, 2012

@theuni So every Android platform can behave differently? I just packaged the build libraries into the standard addons folders inside the apk and everything (pvr with tvheadend addon) loaded without any problems on my android device (ICS 4.0.4). Was it just a coincidence?


theuni commented Oct 13, 2012

@mikrohard no, it'll work fine that way, but it's not in fitting with how android uses libs, and it'll cause the libs to be cached, so we're better off storing them in lib/$platform in the apk.


mikrohard commented Oct 13, 2012

Ah... OK :) Thanks for clearing that up.


theuni commented Oct 13, 2012

I've created a PR on the addons side that fixes the path issues: opdenkamp/xbmc-pvr-addons#64

I've also rewritten the Makefile to be much friendlier.

I'm going to close this PR and open a new one with the rebased changes. However, it will need to wait until the above change is in the PVR repo.

Thanks for getting this rolling @Memphiz!

@theuni theuni closed this Oct 13, 2012

@theuni theuni referenced this pull request Oct 13, 2012


Android PVR Depends #1615

@tru tru added a commit to plexinc/plex-home-theater-public that referenced this pull request Apr 30, 2015

@tru tru Disable VIA CPU Assembler in AES code.
Was causing a lot of crashes on non-VIA CPU’s. Fixes #1527

@Memphiz Memphiz deleted the Memphiz:pvraddons branch May 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment