Jump to content
 
Sign in to follow this  
Docbeamz

Missing Android library

Recommended Posts

Hi,

Our developers have informed us of an issue with the version of Android used by the Focus that has stalled our project.

The Vive Focus (Android) is missing a library, libwvm.so, which is used by our software.

We're investigating a workaround.

Can you explain why this is missing from Focus Android, if it will be added, and any suggestions you would have for fixing this ASAP.

 

Thx

Doc

Share this post


Link to post
Share on other sites

Was it related to using android.media.MediaExtractor.setDataSource ?

Share this post


Link to post
Share on other sites

Hi ,

Thanks for the fast response.

 

Here's the full error:   E/WVMExtractor: Failed to open libwvm.so: dlopen failed: library "libwvm.so" not found.

 

Developer : …………….. "did some digging and found that the issue was with the container format."

 

It involves .mp3 decompression.

If they convert the .mp3's into .wav's the problem doesn't show up.


 

Share this post


Link to post
Share on other sites

For anyone else seeing this error, it can also be due to using the Android MediaExtractor with assets or raw resources (or if you're using a library that calls that). This would require changing the android call to setDataSource to more than just a path, something like: 

AssetFileDescriptor afd = getResources().getAssets().openFd("sample.mp4");

mediaExtractor.setDataSource(afd.getFileDescriptor(), afd.getStartOffset(), afd.getLength());

Share this post


Link to post
Share on other sites

Hi Dario,

Thanks for the reply.

This is from our programmer:

no, that's not the issue
it's not using assets or raw resources
but I suppose they can try loading the files differently

Thanks

 

 

 

Share this post


Link to post
Share on other sites

Hi Dario,

Well, we're still stalled on this problem.

 

We're experiencing this issue with our Android music engine.

 

The previous programmer observations I mentioned came from our UI team.

 

Our engine team spent a couple hours investigating and weighed in on this.

 

This is what they sent to me today:

--------------------

Hi, Doc. Here is my current thoughts:

BeamzEngine is not using MediaExtractor. We decoding MP3 in native C++ code by using minimp3 library. minimp3 is provided in source code and it is platform independent, so I don't think that it uses MediaExtractor (at least I don't see it in minimp3 sources). To work with mp3 files we using simple fopen/fclose/mmap/munmap functions, they are definitelly exists on any Android system. So I think problem in another place, mp3 decoding is not the reason of this problem.

Java part of BeamzEngine uses android.media.AudioManager to query system audio params. Here is its usage:

// "_context" here is activity, passed to BeamzEngineFactory.createEngine or BeamzEngineFactory.createEngine2

Object audManObj = _context.getSystemService(Context.AUDIO_SERVICE);

 

AudioManager audMan = (AudioManager) audManObj;

String fpb = audMan.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER);

String sr = audMan.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE);

Another possible place: for mp3 recording we are using OpenSL ES. Maybe it is uses MediaExtractor in its implementation.

But you are saying that changing of song files from mp3 to wav fixes the problem, so it is doent't looks like what file recording or quering of system audio params is the reason. But maybe I am wrong.

--------------

 

To recap,

Our Android engine runs perfectly on other Android systems.

This issue only shows up on the Focus Android device, so it's something unique to the Focus.

 

Our engine programmers will continue to debug this but, we will also be relying on your assistance.

 

Thanks

Doc

Share this post


Link to post
Share on other sites

Hi Dario,

 

Our Engine programmer made some progress last night but we’re still singing the Android blues.

He was able to intermittently verify that mediaextractor is referenced somewhere in the engine code.  He will isolate the offending code tonight so we just have to hang in there a bit longer.

 

Here’s what he logged:

 

Here is current results:

 

It took some time to run beamz sample app on my Huawei Honor 8 (android build environment was updated since last builds) but looks like I saw creation of MediaExtractor on launching of app. But it is not always creates. In device logs I see lines like:

 

07-23 15:04:26.947 1579-1737/? W/MediaExtractor: creating media extractor in calling process

07-23 15:04:26.955 1579-1737/? I/MediaExtractor: extractor created in uid: 10028 (u0_a28)

It appears in two cases:

 

Android device startup

First launch of beamz sample app after device reboot.

Second, third and so on launches of beamz app are not produces logs with creation of MediaExtractor. But when I reboot device and run beamz sample app at first time then I always saw these logs.

 

Maybe there is some system cache of MediaExtractor object and new instance of beamz app could reuse MediaExtractor from previous app instance?

 

I am going to cut pieces of code to determine which code will produce logs with MediaExtractor. First I will try with clean app (without beamz library), next I will cut all OpenSL ES initialization and finally will cut AudioManager object. Hope this will be enough to found why system creates MediaExtractor.

 

It appears that your initial hunch was right.

There IS some problem with MediaExtractor on the Focus device.

Although we do not use this directly, apparently, some included libs do – coding workarounds may not be possible.

 

Can HTC fix this?

 

Thx

Doc

Beamz

 

Share this post


Link to post
Share on other sites

Hi Docbeamz,

 

Well unless it's really missing a lib from the required list of.libs for a AOSP based build of Android there's not much we could do as it would require adding (and clearing) this lib for what seems like a side case. I would recommend looking into submitting this as an issue on AOSP (unless it's been fixed in a later version). Sine I've see this reported against other Android OEMs online I would guess it's an AOSP issue but we can look into a patch for our builds if there's an official fix, but  the thrid party libs making the call could also be patched with the work around I found to avoid calling this lib.

 

best,

Dario

 

 

Share this post


Link to post
Share on other sites

Hi Dario,

 

We eliminated the MediaExtrator problem by eliminating OpenSL ES which we used for mp3 decompressing. - It calls MediaExtractor.  We now use minimp3 for decompression. 

Thanks for the help

 

Share this post


Link to post
Share on other sites

Please sign in to comment

You need to be a member in order to leave a comment

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...