missing stingray proprietary binaries on xoom 4G

[David David]

Hi

I am trying to compile AOSP ICS for xoom 4G stingray, and i used the script at http://code.google.com/android/nexus/drivers.html

but I still get the following error,

make: *** No rule to make target `vendor/moto/stingray/proprietary/libdmengine.so', needed by `out/target/product/stingray/system/lib/libdmengine.so'.  Stop.
make: *** Waiting for unfinished jobs....


can someone tell me where I can get this and other proprietary apks? or if this "dmengine" is not that critical,  which file can I modify to bypass this?

Thanks.

[Jean-Baptiste Queru]

Just so I can try to reproduce: are you trying this on the master branch, or on android-4.0.3_r1?

JBQ

--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.

[David David]

master branch, sorry forgot to mention.

in addition, I deleted :~/mydroid/vendor/moto/stingray/proprietary/Android.mk file to bypass the proprietary APK errors.

For now, I just don't care about those moto/verizon specific proprietary APKs.

[Jean-Baptiste Queru]

I'm a bit confused here, and I can't reproduce.

The confusing part is that I'm not seeing any reference to that file in any of my makefiles, and I don't have any vendor/moto/stingray/proprietary directory here (since we don't have a license from Motorola to use their proprietary binaries with AOSP).

I recommend that you delete all vendor entries related to stingray (rm -rf vendor/*/stingray), re-extract the 2 stingray self-extractors, and retry.

JBQ

[David David]

Actually, beyond the 2 stingray extractors, I also ran extract-files.sh in device/moto/stingray/

is this extract-files.sh supposed to be run ?

Let me delete and retry. Thanks JBQ.

[Jean-Baptiste Queru]

Ah, that'd explain. You're not supposed to run that. It's my own private tool, and it doesn't really work.

JBQ

[David David]

Yes, now it compiles. Thanks JBQ.

But the runtime error comes, no ui


D/libEGL  ( 1369): loaded /system/lib/egl/libGLES_android.so
W/dalvikvm( 1369): threadid=20: thread exiting with uncaught exception (group=0x40a3f1f8)
E/AndroidRuntime( 1369): *** FATAL EXCEPTION IN SYSTEM PROCESS: WindowManagerPolicy
E/AndroidRuntime( 1369): java.lang.RuntimeException: eglConfig not initialized
E/AndroidRuntime( 1369):        at android.view.HardwareRenderer$GlRenderer.initializeEgl(HardwareRenderer.java:565)
E/AndroidRuntime( 1369):        at android.view.HardwareRenderer$GlRenderer.initialize(HardwareRenderer.java:501)
E/AndroidRuntime( 1369):        at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1300)
E/AndroidRuntime( 1369):        at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2442)
E/AndroidRuntime( 1369):        at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 1369):        at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 1369):        at com.android.server.wm.WindowManagerService$PolicyThread.run(WindowManagerService.java:745)


Did I still miss something? Forgive me if this is off-topic since the building phase is done.

[Jean-Baptiste Queru]

That's unexpected.

Typically, that implies that the proprietary graphics libraries aren't found.

I just did a build and flashed a device, and things are fine for me.

Can you run "grep nv out/target/product/stingray/installed-files.txt" ? That should list a few dozen NVIDIA files.

JBQ

[David David]

 grep nv out/target/product/stingray/installed-files.txt
825:           7  /system/bin/printenv

I figured out why, because I am runing extract-***-stingray.sh from ~/mydroid/device/moto/stingray dir

because I dont want keep too many extract-***.sh in my ~/mydroid dir and  downloaded  and untarred it in device specific dir.

the extract-***-stingray.sh assumed to be run in ~/mydroid, so all the extracted files are in
~/mydroid/device/moto/stingray/vendor dir in my case.

I am not sure whether there is a specific reason to use relative path in extract-***-stingray.sh scripts, but if not, you can change it to absolute path as something like ANDROID_ROOT/vendor to save extracted path in next version, to avoid problems like I'v made.


Now my own build runs on device ok.

Thanks JBQ.

[Jean-Baptiste Queru]

Ah, that explains.

It's a bit of a double-edge sword, and extracting relative to ANDROID_ROOT opens up the possibility that the files would be extracted into the wrong tree.

That being said, it wouldn't be hard to sanity-check that the scripts are run from what looks like the top of a source tree.

Check device/moto/stingray/self-extractors/PART1, that's part of what becomes the self-extractor script (sadly, currently copy-pasted across each device, I need to clean this up at some point). We could fail the extraction if there's not at least a Makefile file and a build/ and a device/ directory.

JBQ