Related
I've been hankering to start porting a game I've been working on(originally was going to be for Zune HD but they haven't released the damn 3D SDK. Video of it running in windows is available on youtube, where my username is marcusmaximus04) to android but was hesitant due to the lack of OpenGL ES2.0 support in the Android SDK. However, looking through the file system on my nexus one, I spotted the file libGLESv2.so, which appears to be the shared object file for exactly this!
Obviously, I still can't use the normal SDK to use this, but in theory, one could use the NDK to use OpenGL ES 2.0 features(shaders, etc) through that shared object file.
The purpose of this post is three-fold. One I want to know if anyone has any background with using OpenGL through the NDK or knows of any tutorials for doing so(I'm not entirely sure how that would work...). Two, I wanted to bring this to the attention of all the devs out there who might be holding off from using ES 2.0 features. And three, I wanted to let everyone else know that such a thing is possible, just 'cause it's exciting.
At any rate, even if I can't find any tutorials I'll probably start plugging away at getting this to work and this should make for an exciting couple weeks/months.
Since we have this pretty well working(even on non-rooted phones) I'll post a sample apk. It doesn't look like much, but it does prove that we're using OpenGL ES 2.0(this will only work on the Nexus One). I'll also post the libGLESv2_adreno.so shared library in the same zip file. Enjoy .
From http://developer.android.com/guide/topics/graphics/opengl.html:
note that though Android does include some basic support for OpenGL ES 1.1, the support is not complete, and should not be relied upon at this time.
Click to expand...
Click to collapse
so official 2.0 support might be a bit off :/
kozm0naut said:
From http://developer.android.com/guide/topics/graphics/opengl.html:
so official 2.0 support might be a bit off :/
Click to expand...
Click to collapse
Possibly, but it does still support it in the NDK(really, this hardcore graphics stuff should be done in the NDK anyway). Even there it's not really official, but they aren't likely to change the API calls since those are already set in stone by khronos.
Hi Marcus,
to get started, grab the OpenGL ES 2.0 headers from www DOT khronos.org/registry/gles/ and copy the library file from your phone to the NDK installation dir (build/platforms/android-4/arch-arm/usr/lib/). Next you might inspect the libGLESv2.so with objdump to see what functions it provides:
build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -t libGLESv2.so
It should have the 2.0 functions like glCompileShader(), glCreateProgram(), etc.
Finally, add the following line to the Android.mk file in the jni/ directory of your Android project:
LOCAL_LDLIBS += -Lbuild/platforms/android-4/arch-arm/usr/lib -lGLESv2
If you're lucky, that should allow you to compile and link OpenGL ES 2.0 code. I cannot try this right now but will as soon as I get my Nexus One on monday
I haven't done any OpenGL ES coding with the NDK, but it should be straightforward if you've written OpenGL (ES) code before. This might be of use: code DOT google.com/p/glesquake/
robert-qfh said:
Hi Marcus,
to get started, grab the OpenGL ES 2.0 headers from www DOT khronos.org/registry/gles/ and copy the library file from your phone to the NDK installation dir (build/platforms/android-4/arch-arm/usr/lib/). Next you might inspect the libGLESv2.so with objdump to see what functions it provides:
build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -t libGLESv2.so
It should have the 2.0 functions like glCompileShader(), glCreateProgram(), etc.
Finally, add the following line to the Android.mk file in the jni/ directory of your Android project:
LOCAL_LDLIBS += -Lbuild/platforms/android-4/arch-arm/usr/lib -lGLESv2
If you're lucky, that should allow you to compile and link OpenGL ES 2.0 code. I cannot try this right now but will as soon as I get my Nexus One on monday
I haven't done any OpenGL ES coding with the NDK, but it should be straightforward if you've written OpenGL (ES) code before. This might be of use: code DOT google.com/p/glesquake/
Click to expand...
Click to collapse
Alright! Thanks for the help. I've done a lot of opengl work before and a little bit of opengl es when i had my g1 but haven't ever used the ndk, so that'll get me started.
EDIT: Sweet, I've dumped the list of functions available and it looks like all the appropriate shader functions are there. I'm attaching the full list output from my computer. I actually had to use arm-eabi-strings, since the objs one showed no objects. Regardless, it's looking good on the OpenGL ES2.0 front, and I've already looked into running opengl code from the NDK which is perfectly possible and ok.
ANOTHER EDIT: Haven't quite gotten it to build yet, but I got it to load gl2.h without any complaints. Now I just have a crapload of errors because the sample project I was using(from the ndk samples, san-angeles) was written for OpenGL ES 1.0 and all the things now done in shaders no longer exist(GL_LIGHTING, GL_MATERIAL, etc). Regardless, I'm considering this a success so far, since all that is expected.
YET ANOTHER EDIT: It runs! I'm not displaying anything yet(so it's not really a good test), but I got the shared library to build using OpenGL ES 2.0 and it runs on my phone. Gonna implement a simple program to display a triangle or something just to prove it works and will provide source code/binaries here(also, if anyone has a Droid or knows someone who does, it'd be great if we could test out to make sure this works on the Droid as well)
I just wanted to drop in and say I'm very interested in what y'all are doing I'm of very good at coding. All I know is Java but ill definantly be following yall and keep up the good work
Decided to post a reply, rather than just adding to that one post.
Well, I encountered a fairly large roadblock:
Code:
E/libEGL ( 3366): called unimplemented OpenGL ES API
That's what I see now every time I call one of the functions dealing with ES 2.0. I'm hoping there's another library I can use that'll make that go away, but we might not be as easy as I thought to do this.
That's bad news indeed. I was hoping that everything is in place and Google just didn't release a new NDK with ES 2.0 support yet, but if the libGLESv20.so is merely a stub, we're pretty much out of luck. I'd probably disassemble the file to see if there's actually some code besides "return unimplemented" in there, but even if there was, I'd have no idea on how to continue...
I'm wondering how they render the fancy rain drop effect on the wallpaper. Looks like a perfect fit for a 2.0 fragment shader, however there are a lot of other ways to create that effect.
robert-qfh said:
That's bad news indeed. I was hoping that everything is in place and Google just didn't release a new NDK with ES 2.0 support yet, but if the libGLESv20.so is merely a stub, we're pretty much out of luck. I'd probably disassemble the file to see if there's actually some code besides "return unimplemented" in there, but even if there was, I'd have no idea on how to continue...
I'm wondering how they render the fancy rain drop effect on the wallpaper. Looks like a perfect fit for a 2.0 fragment shader, however there are a lot of other ways to create that effect.
Click to expand...
Click to collapse
Well I managed to view the assembly code, but can't get it into any form that I can/want to read(I know how to read assembly but unless you spend hours with it, it's damn near impossible to decode anything. Plus, I haven't looked at ARM assembly before). Know of a good program to convert it into C?
At any rate, I'll attach the disassembler dump(ran it using arm-eabi-objdump with flags -DS). From looking at it briefly, all the implemented functions look like they might be stubs since they're pretty bare bones and have almost all the same instructions(with a slight modification to one single instruction). But it's hard to tell with assembly. Let me know if you can make anything of it. I had to attach the file in a .zip by the way because it was too big.
SUCCESS!!!! So, it looks like those functions were stubs. Google seems to have done it intentionally for whatever reason. They took the .so that actually worked(libGLESv2_adreno200.so) and shoved it under /system/lib/egl, which the ndk doesn't seem able to access(gives you a runtime error if you linked against it). However, If you just copy that file to /system/lib (yes, this requires root unfortunately) then you can use it. I successfully drew a triangle using shaders .
I'll try to get it to attach that xxx_adreno200.so file to the .apk so it can be used without messing around with such things(and work without root). If I can, then I'll throw it on here so everyone can see. Right now it's just a triangle, but tomorrow: the world.
EDIT: Alright, I attached the .apk(it's in the zip file, xda still doesn't allow posting .apks). I tried to attach the libGLESv2_adreno200.so library to it, so it wouldn't require moving the local one but it just wouldn't accept it. So, at least for the mean time, if you want to actually run that app without having it crash you'll have to do an adb remount and then the following in the terminal(or adb shell) as root:
Code:
cd /system/lib/egl
cp libGLESv2_adreno200.so ../
Once you do that, when you run the app it should display a yellowish triangle on a blue background(it was from the second tutorial from the OpenGL ES 2.0 sdk for PowerVX). Like I said, it's not much right now, but it is using custom shaders to display that triangle.
ANOTHER EDIT: I decided to change the test program a little. All I changed was the fragment and vertex shaders, which I made to change the color of the pixels based on where they are on the triangle. This should show(to those of you who know OpenGL) that it really is using custom shaders, since it's one triangle and it's clearly not using fixed-function pipeline shading .
Awesome work on reverse-engineering this! Keep us posted.
Indeed, keep at it Marcus! Very interested to see how this progresses.
Well done, Marcus! I'm glad you found that working library.
You should be able to embed the library search path in your own library by using the rpath directive while linking your program. See "man ld" for more information. You need to get the NDK to call the compiler like this:
gcc ... -Wl,-rpath=/system/lib/egl
That should allow you to use that library without copying it around, and therefore make it work on non-root phones as well.
I guess all you need to do is add the directive to the LOCAL_LDLIBS variable in Android.mk, or maybe it has LOCAL_LDFLAGS, which would be more appropriate.
robert-qfh said:
Well done, Marcus! I'm glad you found that working library.
You should be able to embed the library search path in your own library by using the rpath directive while linking your program. See "man ld" for more information. You need to get the NDK to call the compiler like this:
gcc ... -Wl,-rpath=/system/lib/egl
That should allow you to use that library without copying it around, and therefore make it work on non-root phones as well.
I guess all you need to do is add the directive to the LOCAL_LDLIBS variable in Android.mk, or maybe it has LOCAL_LDFLAGS, which would be more appropriate.
Click to expand...
Click to collapse
Ya, I tried adding it to LOCAL_LDLIBS, but that just seemed to make it use that path for the local library on my computer when building it. It still failed to find that library on my phone when I ran it. I'll try poking around a little more since that would obviously be ideal.
Alright. Are you sure you used rpath and not rpath-link?
BTW, there's a libGLESv2.so in the 2.1 emulator image. Did you try using that? I wonder if the emulator supports ES 2.0...
robert-qfh said:
Alright. Are you sure you used rpath and not rpath-link?
BTW, there's a libGLESv2.so in the 2.1 emulator image. Did you try using that? I wonder if the emulator supports ES 2.0...
Click to expand...
Click to collapse
I didn't touch either actually, just changed the name of the library and the path it had. I haven't done a lot of make files beyond the most basic operations so a little study might be necessary.
Haven't tried the emulator image one, but the one from the phone just had those stubs. It would be really strange if the emulator had the actual functionality and the phone didn't.
I think you're right that if there's hope then it lies in the makefile, so I'll keep looking into that.
EDIT: Just tried adding --rpath=/system/lib/egl everywhere I could possibly think of and all with no change.
Hmm I can't try this yet, but it looks like it uses the property java.library.path to determine where to look for shared libraries. Maybe I can have it look in /system/lib/egl too?
Ack, tried it, didn't do anything. Still can't find that library.
So ya, I'm giving up on this front for now. Google obviously has some of this ready but doesn't want us using it for now, so I'll just wait for them to give us access unless I get some new info. In the meantime, I'll continue the work I've already started on porting that game from the video I linked to. At least we now have the tools to test this stuff.
[email protected] said:
Hmm I can't try this yet, but it looks like it uses the property java.library.path to determine where to look for shared libraries. Maybe I can have it look in /system/lib/egl too?
Ack, tried it, didn't do anything. Still can't find that library.
So ya, I'm giving up on this front for now. Google obviously has some of this ready but doesn't want us using it for now, so I'll just wait for them to give us access unless I get some new info. In the meantime, I'll continue the work I've already started on porting that game from the video I linked to. At least we now have the tools to test this stuff.
Click to expand...
Click to collapse
thats depressing i was checking this thread like 10 times a day waiting for new info to popup lol call me obsessed but i respect your work
Yet another idea to try. On Linux you can specify the library search path using the environment variable LD_LIBRARY_PATH, e.g. if you run a program like this
LD_LIBRARY_PATH=/some/path /path/to/program
then the linker will search that path for libraries.
Maybe it's possible to set that variable from within the Java code, but before the JNI library is loaded:
static {
// Set environment variable LD_LIBRARY_PATH
System.loadLibrary("your_jni_lib");
}
Finally another idea, so we cannot link our library to the OpenGL ES library. But we could probably dlopen() it from within the JNI library and grab all the function pointers using dlsym(). I will get my Nexus One in a few hours, and ES 2.0 will be one of the first things I'm going to look into
EDIT: Marcus, would you mind posting the source code of your ES 2.0 triangle demo application? Basically all I need is the gl....() stuff. I haven't done too much Shader stuff so far, so that would save me a lot of time.
robert-qfh said:
Yet another idea to try. On Linux you can specify the library search path using the environment variable LD_LIBRARY_PATH, e.g. if you run a program like this
LD_LIBRARY_PATH=/some/path /path/to/program
then the linker will search that path for libraries.
Maybe it's possible to set that variable from within the Java code, but before the JNI library is loaded:
static {
// Set environment variable LD_LIBRARY_PATH
System.loadLibrary("your_jni_lib");
}
Finally another idea, so we cannot link our library to the OpenGL ES library. But we could probably dlopen() it from within the JNI library and grab all the function pointers using dlsym(). I will get my Nexus One in a few hours, and ES 2.0 will be one of the first things I'm going to look into
EDIT: Marcus, would you mind posting the source code of your ES 2.0 triangle demo application? Basically all I need is the gl....() stuff. I haven't done too much Shader stuff so far, so that would save me a lot of time.
Click to expand...
Click to collapse
Sure. I'll post it when I get home from work tonight. I don't have anything proprietary in there yet.
For the setting of the environment variable, from my understanding that's basically what System.SetProperty("java.library.path"... is supposed to do. But it still couldn't find the library and didn't seem to have any effect.
The dlopen bit might work. I was thinking of trying that but haven't had any time. I'm not really too sure on how these shared libraries are used, whether once they're open any other program can find and use them or whether the path to them has to be given explicitly at link time for the program that wants to use them and just generally having one loaded won't help.
EDIT: By the way, @pr0cl1v1ty: Don't worry, I'm not going to stop digging into ES 2.0 entirely. I'm just not going to be pushing as much for getting it to work on non-rooted phones. I've got bigger fish to fry.
So I've watched the ICS Motorola Webtop Beta 3.0 video and it may be me but it looks very similar to the Evo Desktop PC in concept and function. Considering that ICS wasn't even available this time last year this would have been the logical progression of the project. I'm not asking for Moto to send me a check but I'm waiting to see how the credits roll out. If the Sun here on Mars has baked my brain then feel free to say so.
Lokifish Marz said:
I'm not asking for Moto to send me a check but I'm waiting to see how the credits roll out.
Click to expand...
Click to collapse
Wow
The check is in the mail.
CCallahan said:
The check is in the mail.
Click to expand...
Click to collapse
So are you going to send it on their behalf?
Actually I've been in contact with Moto since the videos surfaced and am getting the "hot potato" treatment. All I'm looking for is to have a civil dialog with them about it. All I'm getting is being told I need to contact Department A by Department B after just being directly referred to Department B by Department A. I have even gone so far as to include the direct referral and names in my communications. You probably have a good idea as to how well that's working.
The odd thing is that with 200+ views nobody has said I should have my head checked. Is everybody on XDA being nice?
Interesting question, locki. Definitely a fair one. If I understand correctly, from watching the video (I had the volume down - A cold and a headache coming down so I'm trying to minimize the noises). In any case, your version looks to me like phone mirroring with a keyboard and a mouse. Not sure how it's set up (you probably said it in the video). But I don't think the ICS demo is a complete demo. This looks like he just reviewed the phone mirroring version, but didn't do a complete webtop review. Also, webtop on the current system is also pretty limited. From that video, I don't see much difference between the ICS and what we have on our phone, except that this is a proof of concept. In any case, you could say the same thing about a comparable presentation from the webtop experience on the mopho if you only show the the phone window usage. could also say the same thing about your ubuntop if you only show a limited version of the capabilities. I guess my point is I don't think you have a fair comparison at this point. But my head is stuffy and I am on my way to an early bedtime, so maybe I'm missing something...
I replaced the video of webtop 3.0 with one that shows webtop3.0 in use. I also have a copy of the ICS RAZR leak and osh (or anything related to that partition) is nowhere to be found. Neflix is obviously Netflix for tablets. The desktop look of Chrome appears to be a ui switch for the mobile chrome browser. If the ICS leak is anywhere near what the official release is, then the tech/android reports are correct that the new webtop is nothing more than modified tablet mode mirroring.
I'm not saying it's not good work. Had HCL Launcher, Chrome mobile browser and Netflix for tablets been out when I released Evo Desktop you would be hard pressed to tell the difference.
My other concern is if the leak I have and the videos are correct this does not bode well for Webtop becoming a true desktop with ICS like many had hoped.
So If I am understanding things correctly, the new webtop is just tweaked phone mirroring, as opposed to now where there are 2 operating systems running side by side. I guess ubuntop won't work on that system then. very disappointing.
As nice as Evo Desktop was there were tons of drawbacks. So I can tell you from experience that this is going to be a serious step backwards for "Webtop". Open up a mobile browser and visit a page that has flash based chat embedded. You cannot leave that page (view another page in another tab) because as soon as you leave the chat page tab everything gets suspended. When you go back to the chat page tab you have to log back in and start over.
Document editing will also be an issue as you have to use cloud based editors like Google Docs because to my knowledge none of the current office apps have that tablet switch needed change how the ui is rendered. When you combine this with the browser tabs issue and that Google Docs puts a fairly heavy load on the browser, you can say goodbye to any real doc editing.
What it comes down to is that many app devs are going to have to add the needed ui switch and changes to keep the new webtop from being trash. This will not be easy. I fought for months to just get a browser with a "desktop ui" look with no success. Even with thousands of users on the Evo project nobody would touch it. I ended up having to modify an existing browser to give my users a desktop look. Multiply that by how many commonly used apps that would need a ui switch and Moto is just asking for failure.
My other concern is what happens to the, now wasted, 1.3GB osh partition? The leak has no mention of it in the install script. It looks like it will still present but only accessible via vnc which has it's own issues and drawbacks.
I'm sure a lot of you have played The Amazing Spiderman app and were disappointed with the graphics on our devices. I found a link for a configuration file that enhances the graphics of the game for a device that was well bellow the Atrix and decided to make my own.
DO NOT try to push these settings further. For the last couple of days I've done a lot of trial and error and this is as far as the app will allow us to push these settings until they reset when you start the game.
READ the Readme in the zipped file on where to put this file. Make sure to overwrite or back up the original.
I'd post screenshots but I don't have the camera in the game and when trying to take a screenshot via Power button, it opens the menu.
Changes include:
Lower resolution to remove / reduce lag with these settings
Enhanced graphics for Spiderman, sky and water
Manholes produce smoke? (Haven't seen any, yet, but it is enabled)
Birds? (Haven't seen any, yet, but it is enabled)
Slightly further rendering of buildings
Higher LOD of vehicles and NPCs
More types of vehicles and NPCs
Slightly more populated streets
Bloom and Specular lighting enabled
Speed lines when web slinging and running
I am running Neutrino 2.8 EE. If anyone that is overclocked wants one with the standard resolution, or even higher, let me know.
HTML:
http://db.tt/wYZAnO3t
Sent from my MB860
Cant download
from the (m)ATRIX...
I forgot I switched up the folder it's in. I'll post an updated link in a bit.
--edit--
Link has been fixed.
Sent from my Jellybean Atrix 4G
Hi Everyone!
My names Mike, and I'm an artist working in the UK. I've had an idea for an art project for quite some time now, and in the process of working through the details I believe a component of it could be solved using an Android Application. The idea for the application would be to have a camera that is always at the ready and will snap a picture every time a certain level of audio input is reached. Now, this will be slightly different to your average 'Audio Trigger' in the sense that the camera will have to be able to take pictures at an incredibly fast pace. Two, three, four or more a second if possible.
Obviously, Ive done a bit of research to see if there are any applications available that could do the job without any alterations. There are a few apps that come close.
The first is 'Fast Burst Camera'
This is an amazingly quick camera application capable of taking photos in the region of 30fps at 1280x720. (I'm guessing this uses some sort of modified video camera function?) Setting this to Full Manual mode allows for amazing capture speed, taking photos as fast as you can hit the shutter button. Perfect!
The second is 'Sensor Camera'
This app has perfect control over the sound meter levels for the 'Audio Trigger'. Allowing you to set a watch value at 10db increments. The only drawback is the use of full resolution shots, making the capture rate far to low.
I'm wondering if it would be possible to combine the two functionalities into one application? Whether this would be possible in terms of processor speed and hardware?
I know the commercial appeal for this functionality would be almost non-existent, but for the use in this project it would be perfect! I've emailed the respective developers of each application, without much interest.
If anyone is interested please let me know. This is for a non-profit art project, so it would be great if people wanted to donate their time, but I would also be happy to pay. The app would not be used commercially at my end, only for the work in the project.
If you've made it this far, thank you for your time
Mike.
Hey your app sound cool let's do some Mindstorm:
Problems I see for the app: If you hit a loud sound and you don't want to take a picture. (Ex. Train passes nearby and the phone it's locked in your pocket).
Functioning diagram: In the java we implement a action listener that hear the sound and this will return in a action (making a photo). The ui must not be so complex only a force photo button and maybe some preview.
It's a great app and it's easy. Maybe I can analyze if it's too difficult to make it but now I'm in holidays and I don't have too much time... I'll say something, what can be great it's to have the eclipse project of those two apps if they are opensource, specially the sound hearing one.
Sent from my RK29 tab...
---------- Post added at 09:33 PM ---------- Previous post was at 08:43 PM ----------
I said previously I'm on holidays and i don't know if I'm interested in the project yet.
SferaDev said:
package org.sferadev.audiot;
Working on source of a simple photo picker. Next get audio listener and then combine it.
Click to expand...
Click to collapse
Sent from my RK29 tab...
Hey SferaDev!
Thanks a lot for the detailed reply, sounds like you've definitely got some headway with this one.
On the subject of unwanted sounds triggering a shot, for this project, that wont actually be a problem! As long as its possible to adjust the trigger using some sort of incremental value (in db?) it should be perfect. I'll probably be using a separate audio source fed through the headset line-in as the trigger.
Thanks again for your interest.
Oh, and they're both commercial apps, so I doubt there's much chance of getting to the project files
Yeah I deserve the camera app it's not as difficult as it seems. We are not working from the API, w are just requesting to the camera app a photo. What it's difficult because I never worked with audio recording apps within the source it's to listen the balance of the dB...
Hope I helped but we need more exp devs, because all my Android apps are related to internet usage not to media usage, but I'm quickly learning...
Sent from my RK29 tab...
No worries SferaDev! I really appreciate the information so far. I'm totally determined to see this through so hopefully there's someone who can help
Project continues here: http://forum.xda-developers.com/showthread.php?t=1840300
Sent from my RK29 tab...
Similar to my TWRP / Multirom thread, this is temporary until xda decides to add this device to the dev db list. A few comments and a known issues list will be all in this post. Please report any and all problems you find. This is still very early in the development process.
NOTES:
This will only install using my TWRP build here because I'm have to do some hacky things to support a unified build. I may eventually find a cleaner method.
This doesn't yet contain my attempt at controller pairing. The framework patches are there, but not the apk. It will be tested and included in later builds. Wifi doesn't work, so pairing wouldn't work anyways.
I had to use aosp libs to make this boot, which is different from my Portable and Tablet releases. The hdcp libs seems to be very different, so I have no idea if 4k works at all and I seriously doubt youtube and netflix drm will verify correctly.
You will have to wipe data to install this, make a backup first. Do note this is just /data, not the entire internal sd.
KNOWN ISSUES:
Wireless controller pairing not implemented
No audio over hdmi (so, no audio at all)
SOURCE:
device
kernel
vendor
CURRENT RELEASE:
cm-13.0-20160224-UNOFFICIAL-foster.zip
OLD RELEASES:
cm-12.1-20150819-UNOFFICIAL-foster.zip
cm-12.1-20150720-UNOFFICIAL-foster.zip
cm-12.1-20150709-UNOFFICIAL-foster.zip
missing default android keyboard?
installs fine boots into CM - displaying in 1080p on my monitor just fine.
missing android keyboard.
works fine with usb keyboard (logitech k400r)
amazon app store installs fine, recognizes all apps - minecraft PE crashes on start
touch pad / mouse freezes intermittently
netflix installs but does not play
great start, looking good.
I'm finding all kinds of interesting things working on this... Well, I got the stock libs 'working'. HDCP (or something in the graphics stack) locks up the system on boot when using a custom built kernel. From within CM or even from Nvidia's aosp tree. It will only boot with the kernel pulled out of an official boot image. I compared the ikconfig out of the official kernel with what I'm building in CM and they match. So, I'm kinda lost as to what black magic is at work here... Is something doing a crc check? Is there black box GPL violations in the stock kernel? I don't know. And I had a custom kernel booting stock when I was first trying multirom stuff. So that makes me *really* confused. For the moment, I've disabled kernel compiles in my device tree and I'm shipping a blob kernel. And I hate doing that.
Haven't looked at the missing keyboard yet.
Wifi is closer, but still not there. The wlan0 interface seems to init, but the p2p interface fails and brings it immediately back down. I'll do some more research into that over the weekend.
The screen flickers at times. Don't know why, but I think I saw some system props that affects the screen drawing on stock, once I find those again I should be able to fix that.
The OMX libs work now. Which means game streaming works. I tested a grid game already. Don't have Windows, so I can't test local streaming. And theoretically the aforementioned Netflix problem should be fixed by this as well.
I'm kicking off a build to run overnight (takes 4+ hours for a clean release build [on a AMD FX 9370, no less]), so I should have this stuff up first thing tomorrow morning (pending life (r)).
Edit: And... build failed. Starting over... So, looking at this afternoon now.
Edit 2: Well... I can make it boot when I tinker with it manually, but I'm not having much luck making a reproducible build from source. So... I'll have a release eventually, but with 4 hour rebuilds, I can't say when at this rate.
Steel01 said:
Similar to my TWRP / Multirom thread, this is temporary until xda decides to add this device to the dev db list. A few comments and a known issues list will be all in this post. Please report any and all problems you find. This is still very early in the development process.
NOTES:
This will only install using my TWRP build here because I'm have to do some hacky things to support a unified build. I may eventually find a cleaner method.
This doesn't yet contain my attempt at controller pairing. The framework patches are there, but not the apk. It will be tested and included in later builds. Wifi doesn't work, so pairing wouldn't work anyways.
I had to use aosp libs to make this boot, which is different from my Portable and Tablet releases. The hdcp libs seems to be very different, so I have no idea if 4k works at all and I seriously doubt youtube and netflix drm will verify correctly.
You will have to wipe data to install this, make a backup first. Do note this is just /data, not the entire internal sd.
KNOWN ISSUES:
Wifi doesn't enable. (ethernet works fine, though)
Keyboard not installed
SOURCE:
device
kernel
vendor
CURRENT RELEASE:
cm-12.1-20150709-UNOFFICIAL-foster.zip
Click to expand...
Click to collapse
screenshots ?
Glad to see ATV gettin some action ... ooooo hel I'm excited. I've been fastbooting your twrp img. for a few things and its working quite nicely on my pro model. BIG BIG thanks for that @Steel01 Does it look like there will be any issues reguarding which version console its running?
@aniel300: Screenshots? It's Cyanogenmod. The same Cyanogenmod as on any other device...
@ElwOOd_CbGp: Like mentioned in the OP, I do a hacky thing or two to support unified builds. It have the pro version myself, so that's what I test on. I'm pretty sure it will work with no extra problems on the 16 GB model, however.
Alright, I *think* I finally ironed my build problems (all related to using a prebuilt kernel... got to figure out a way to not have to do that), so theoretically I'll have a build out tomorrow. Probably won't be able to test much until the afternoon, so I doubt it'll be out bright and early.
yey! please keep going! AOSP + Kodi + Support for official remotes would be awesome!
Steel01 said:
@aniel300: Screenshots? It's Cyanogenmod. The same Cyanogenmod as on any other device...
@ElwOOd_CbGp: Like mentioned in the OP, I do a hacky thing or two to support unified builds. It have the pro version myself, so that's what I test on. I'm pretty sure it will work with no extra problems on the 16 GB model, however.
Alright, I *think* I finally ironed my build problems (all related to using a prebuilt kernel... got to figure out a way to not have to do that), so theoretically I'll have a build out tomorrow. Probably won't be able to test much until the afternoon, so I doubt it'll be out bright and early.
Click to expand...
Click to collapse
is it a hybrid rom ?
@[email protected]: Kodi is of great interest to me as well, so I'll work to make sure works well.
@aniel300: No, it's pure CM. I plan to make the TV stuff accessible, but it won't be there by default.
I finally got a bootable build, but it does show more problems. The launcher and some programs lag terribly. Not locking up, but slow enough to trigger ANRs. Netflix does still crash when loading a video, hopefully that won't be hard to fix once I can read the logs. The interface still flickers, but only the interface, not videos or games or such. I'll do some more testing this afternoon and unless an even worse problem shows up, I'll release.
New build is up. It appears the netflix bug affects others things too, like youtube. Appears to be audio related, but I don't have time right away to try and track down the root cause. So, consider this another bug hunting build and not truly usable.
I've fixed an audio problem, so sound and YouTube and all that works again. Netflix is still confusing me a bit, though. It appears to be a problem with the OMX libs, but not one seen on any other Shield device. Haven't spent too much time looking the last few days.
I'm in the process of restructuring the build setup on my dev machine. Like moving the build trees to a faster spinny disk and ccache to a ssd. That should get builds going a lot faster. 4 hours per build gets old real fast. And 45 minutes for a one package change. I plan to release a new build once I get that all sorted out.
what about you try to port android m tv developer preview instead or at least cm but with all the good stuff from android tv.
It seems Forge has unlockable bootloader they posted instructions also for home images so it's a start it should be easy to flash recovery if there was one. Sorry for going little off topic but this seems more active here
New build up. Seems the OMX libs are only partially working. Youtube works, but mxplayer and kodi fall back to their software decoders. Wireless appears to finally work, but logcat messages lead me to believe it's still not completely there. Oh, and the UI flickering is still there.
So, I loaded this build up and promptly installed HALauncher and Kodi. With the controller wired in, this seems to be a pretty usable setup. As things begin to stabalize, I'll probably start to recommend that launcher as a replacement for leanback. Now if only I can find a replacement for the leanback keyboard, I won't have to include any Google blobs... Suggestions are welcome for a free and preferably open source dpad enabled keyboard.
Really good progress tonight. Barring something patentably bad happening, I should be releasing a new build tomorrow. List of progress:
1. Interface flickering is way down. Don't know if it was something I did or if upstream CM tweaked stuff. Either way, it's bearable now. I only notice it on some transitions, whereas before it was all the time on builtin android interface stuff.
2. OMX libs work. Hardware accelerated video and movies, plus game streaming and grid works now.
3. Leanback IME (controller enabled keyboard) is part of the build. It's smaller than on stock, but still usable.
Some things still need work, though:
1. Netflix still fails to play a video. At least it doesn't crash to desktop anymore...
2. Wireless controller pairing fails. The app runs and it tries to set stuff up, but seems to hit the same problem the Portable does most times. I have got the Portable to pair once or twice, though, so some people might be more lucky than me and it'll actually work.
All in all, this looks like a very usable test build, if not a daily driver for some use cases.
Hi steel01
I am planning to buy this device, pro version, but its true that the SSD storage drive has some problems about performance and response, speed, looking all around for a good review about this and nothing found yet,unbelievable, I want to be sure the 16 GB or pro version.
Counting on you,like you doing on the shield tablet,interesting approach with CM,look forward, when I get it I will install the Zulu99 full android ROM first and them....cm
Good luck on this, thank for you hard work
I haven't had any lag problem with the Pro edition, but I also haven't done anything IO intensive. So, I'm not really a good yardstick for that. However, the pro edition does have the 16GB hardware, just needs some tweaking to be able to access it. Probably could do some boot image trickery to get /system on that device. Haven't looked at that yet since CM and multirom are higher priority in that order.
Other stuff came up today, so I didn't get to test the new build. As soon as I drag it back across the house to reflash it, I'll verify the build and upload. Maybe tomorrow afternoon.
I am just a thinker, its possible to use all the best feature of CM and put it in android tv or viceversa.
I dont own yet a android tv device, but is like no to manny peoples like it, may restrictions from google, its entirely new or old UI, developers needs to port their apps to android tv platform, maybe we like the custom launcher or just the regular launcher, well its until everybodys decision.
Multirom sound good, but i like the basic and fast, what about if we can have two launcher in the GUI or UI, can be possible, there is a really need an apps to be ported to android tv platform, why google put restriction, we can sideload to get what we want, i think this is confusing android OS is android.
I think the best thing to do its going back to the basic.
Well, I didn't get to testing today either. I think I'll run another build tonight and try to get to a test tomorrow night.
@duanim: That is my end goal for my device. The Shield TV running CM with a 10 foot launcher (that isn't leanback) and everything accessible from the controller. The current build isn't too bad for that, but not all the way there. CM and HALauncher works pretty well. But the controller still needs help wirelessly.
There's one major problem with running android and android tv simultaneously. It seems the play stores are different. You either get the TV apps or the normal apps, not both. If someone knows different or a way to work around this, I'd love to hear it.
Still can't get the dumb wireless controller libs to package the way I want. So the latest build is missing some, causing the app to continuously force close, making the build unusable. I'll split it like I didn't want to and should have a releasable build tomorrow.