[perpe]

Hello Guys,

I own an ASUS MeMO Pad FHD 10 with the Intel Z2560 SoC. In the README.android I read that it builds successfully for x86, I haven't found somewhere a x86 apk, so I give it a run. My build failed
I don't know if the readme is outdated or if my configuration command was faulty. I adapted the command in the xbmc/tools/depends/README to use the x86 NDK compiler. This means I used --host=i686-linux-android.
After my unsuccessful build try I looked into the configure.in files and saw that there is no choice for i686-linux-android, but a i*86*-android-linux-gnu*. I don't know a Android gnu compiler and there isn't one in the NDK .
After playing a little bit with the configuration command I gave up and began to change the configure.in files and some other files. Now, my build succeeds and XBMC for Android works on my x86 tablet.
I found this link http://www.auby.no/files/video_tests/ in the libstagefright thread. I played all the videos, only the hddvd file runs on very slow speed. The xvid one has too many artifacts, but xvid is faulty with other Android movie players, too. No problems with the other files.

Now, I want to submit my changes to your Github repo, if it wasn't my fault.
I replaced the i*86*-android-linux-gnu* choices with i*86*-linux-android*. Do you need the i*86*-android-linux-gnu* choice? The question is, should I overwrite it or add my changes as an additional choice?

(if someone wants to test my build, you can download it at http://d-h.st/tOg )

[sheepybach]

perpe,
As I really don't know much about coding and the like but bloody hell mate I downloaded your test build onto my Tab3 10.1, installed fusion and from there Mashup and Naxi x.
On Navi x I've tried live streams and films and they all run great. On mashup I decided to got for the top and at this moment in Time am watch a film from there in Full 1080HD and it's like a dream. Will check more content on these 2 addons and then slowly add more addons and try them out and if you want I can report back on if they run ok or not. I understand that if they don't run they maybe the addons at fault, So tell me what you would like me to do and as I've good lots of free time I can help if you want bearing in mind I'm an old 53 yr old git and not up on all the ins and outs of coding lol.

One thing I've noticed is that on start up I get an error " failed to start Commoncache "

Well done Sir and thank you

[davilla]

Now, I want to submit my changes to your Github repo, if it wasn't my fault.
I replaced the i*86*-android-linux-gnu* choices with i*86*-linux-android*. Do you need the i*86*-android-linux-gnu* choice? The question is, should I overwrite it or add my changes as an additional choice?

Just do a PR and the XBMC devs will see it and make comments if needed.

[Memphiz]

Are your changes any different from what i have done here?

https://github.com/xbmc/xbmc/pull/3098

Sorry we didn't merge it in yet because of missing feedback of one of the main android devs...

[perpe]

@sheepybach
Many thanks for your feedback. I must admit I am not really a XBMC user. I have built it for other users. Nice to read, that it works fine.

@Memphiz
It seems to be mostly the same, your code misses two changes. It will compile, but don't install and run. At the moment I am not at home to submit my changes, but i can show you what is missing.
1. tools/android/packaging/Makefile ARCH and CPU have to be the same (x86) otherwise you would get an error on installation, because all the lib files will be in a folder called "i686". On installation Android checks if the native libs for the architecture are available, Android looks only if the right folder is there. If you name it i686 instead of x86, you get an installation error. (see the libs: section of the Makefile it uses CPU and not ARCH)

If you change this, the installation will succeed, but the XBMC splash screen will fire up an error. NEON isn't available on x86. (the new ATOM SoCs have SSSE3, maybe using this can give us better performance see http://software.intel.com/en-us/articles...intel-atom )
2. xbmc / tools / android / packaging / xbmc / src / org / xbmc / xbmc / Splash.java needs a build.CPU_ABI check, if it is x86 skip CheckCpuFeature("neon") (look at line 270)

Edit: I also added a use_neon=no into xbmc/tools/depends/configure.in at i*86*-linux-android*) to make sure neon is disabled

[Memphiz]

could you do a pr to my branch with those missing bits? that would make it a bit more easy for all and reviewers ...

[Stildawn]

Hi Perpe, you posted on my other thread for Galaxy Tab 3 10.1 intel cpu.

Reading the responses here, it sounds like this isnt a complete xbmc build?? Like I need an external player or something?

I would love to try this out if it is a complete build that works out of the box so to speak?

[sheepybach]

Stildawn,
This build does not need an external player it uses the internal 1 build into XBMC which has H/W acc in the form of libstagefright and it plays perfect 1080p Full HD videos, it also plays 720p HD live TV streams. If you want to use an external player you have to change some setting in the ......... Sorry I can't remember what it's called. No doubt somebody will tell you. This build does work out of the box but like all alpha builds things will crop up that don't on RC builds, I can live with that and to date it's only failed a few times on different this and until a thread is started for these problems/bugs to be looked into then it's hit and miss. The only complete build for xbmc is Frofo 12.2 but sadly that will not run on our Tab3's as is.

[perpe]

could you do a pr to my branch with those missing bits? that would make it a bit more easy for all and reviewers ...

Easier said than done, I'm too new to git. I made a PR to the xbmc repo including your and my changes. PR to your droid-x86 branch showed too many changes. They said, I have to rebase. Now, I have to read, what rebasing is. I'm learning
My pr: https://github.com/xbmc/xbmc/pull/3256

[Memphiz]

You are getting to it as i see

[perpe]

Yeah, with your great help

I built the x86 version with our changes and it works like a charm, building and running the arm version, too.
Now, I have another problem (and again, it is maybe my fault). What is the right way to clean up my working directory? I tried clean and distclean, but it seems that it doesn't clean up all directories. "git clean -xfd" cleans up everything and works. It seems that we miss some clean up routines for the android build.
Without a complete clean directory I can't build the x86 version after the arm version (and vise versa). it fails on make apk, because it tries to include some libs from the earlier build process into the new apk. "git clean -xfd" solves it.

[Memphiz]

Sounds like a broken clean indeed. git clean -xfd is a good workaround if you ask me. As i am not the creator of the unified depends system its not really my part of responsibility. It hink a working clean has bit of a lower priority for now.

[Martijn]

As of today we will produce nightlies for Android x86 platforms. Do NOT mix up the different APK versions as it will just crash

They can be found here:
http://mirrors.xbmc.org/nightlies/android/x86/

[davilla]

there is a PR for droid packaging clean

[sheepybach]

As of today we will produce nightlies for Android x86 platforms. Do NOT mix up the different APK versions as it will just crash

They can be found here:
http://mirrors.xbmc.org/nightlies/android/x86/

Here's a good 1 for you, I downloaded and installed 14th Oct nightly on my tab 3 10.1 and tried it out and it worked great (well done and thanks) so I decided to look at which h/w acc was on and I found both media codec and libsf on. So I turned LSF off to try MC only and got a lot of slow playback, stalling et al. So I tried the other way around and ended up with the same issues. So I turned both back on and it now plays like a dream. Pass as why this is so