Related
As the title says, I heard it was "almost done" like 3 months ago. Anyone hear anything about it?
I have heard that it was almost done a couple of times. People saying that it is a silverlight issue and it will not stream on Linux have obviously never used a ROKU before. It is a linux media center type box that streams Netflix fine. But if you look at the source it says that it contains MS code, etc, etc.
If someone was smart enough they might be able to take the ROKU source and make it work, but it is probably not possible.
Anyway more than likely MS wants to get Netflix streaming on its own platform before Android to help drive sales. Once they feel like letting Google use their code they will try to license it to them. Google may not want to pay this license. Otherwise Google would have to write it from scratch which they are probably trying to do. I have seen several Linux and Android video streaming jobs posted over the last year or so.
Your best bet will probably be Skyfire. If they ever add Silverlight storage then it will probably work. They have even said on thier forums that they know what to-do to make it work but they are not there yet. Lets just hope if they ever make it work Netflix does not block them like Hulu keeps doing.
I have Silverlight for Mac, so I would think MS would not have a problem with a Silverlight for Android - the give the client away to encourage server side development.
There was an article on CNET a few months back that pegged the launch of Silverlight on Android for the Professional Developer Conference in Las Vegas. Hopefully a Netflix app would be released alongside.
Bjd223 said:
I have heard that it was almost done a couple of times. People saying that it is a silverlight issue and it will not stream on Linux have obviously never used a ROKU before. It is a linux media center type box that streams Netflix fine. But if you look at the source it says that it contains MS code, etc, etc.
If someone was smart enough they might be able to take the ROKU source and make it work, but it is probably not possible.
Anyway more than likely MS wants to get Netflix streaming on its own platform before Android to help drive sales. Once they feel like letting Google use their code they will try to license it to them. Google may not want to pay this license. Otherwise Google would have to write it from scratch which they are probably trying to do. I have seen several Linux and Android video streaming jobs posted over the last year or so.
Your best bet will probably be Skyfire. If they ever add Silverlight storage then it will probably work. They have even said on thier forums that they know what to-do to make it work but they are not there yet. Lets just hope if they ever make it work Netflix does not block them like Hulu keeps doing.
Click to expand...
Click to collapse
silverlight for android was already announced, or if you're real impatient, we can move to something more open-source friendly like Moonlight
There is a Netflix streaming app for iOS, which is also linux based I believe. So I don't know that this is the issue.
argolfermd said:
There is a Netflix streaming app for iOS, which is also linux based I believe. So I don't know that this is the issue.
Click to expand...
Click to collapse
iOS is not linux based. it is BSD (which is a *NIX-like environment) based, just like OS X and Darwin. development may be similar, but won't be the same (which is why you can't just run an OS X application on linux). silverlight for mac already existed for a while, meaning MS already had development of a BSD version of silverlight that could be ported over to iOS in a similar fashion.
and while it's been shown that some tools can work cross-platform between iOS and android (look at the modifications to flash for android for iOS to get Frash), that was a framework/plugin that was very buggy at best.
to the best of my knowledge, there is no TRUE port of silverlight for linux based systems. the closest we have is the moonlight open source project (incorporated with the Mono project, open source version of .NET for linux). I haven't used Netflix on either the iPad or iPhone, so I can't say for certain if they even USE silverlight in those platforms. They may have just encoded everything as variable bit-rate mp4's which are compatible on almost every smartphone and the application is just a front-end to tie to your account for DRM purposes.
Whats your BIG Chromecast idea? More potential than a "traditional" A/V streamer?
So I've seen many people, developers and users alike, swarming the ideas of the expected basic usages of this wonderful device.
Examples: Out-of-Box expected usage (streaming from qualified providers), mirrored A/V from PC/Phone/Tablet, other connectivity proof of concepts (IE: emulators), ect…
So my question is: What's your big idea to extend the usage of this device beyond "traditional" implementation?
I’ll start by sharing mine (actually 2 product idea’s, that could become 1 at some point in time).
1. All-in-one media station. Taking the concept of a HTPC/XBMC build, and extending it to have the Chromcast as the “presenter”, and the PC/Phone/Tablet as the “remote”. The software package would include a “media server” run on a compatible PC on the same network, accompanied by the “remote” app on the Phone/Tablet (web-based control for PC remote).
I intend to also include the ability to queue/control presentation files such as PPT, PDF, ect… I’d like to have the package useful to both home and business clients/users.
One of my favorite parts of this idea resides in the remote app. Upon selection of the media you intend to cast, use a 2-finger up gesture to begin casting (makes me think of the scene in IronMan2 when he takes over the monitors in the courtroom by using a similar gesture on his “phone”, lol) It’s the little things that get me excited haha.
2. A home automation/security media point. On demand or automated view of automation/security enabled objects in your environment. Example: You have a security system with camera’s in your home, specifically, one is mounted at your front door. Someone appears at your door (motion-trigger), and/or rings the doorbell (another available trigger). HDMI-CEC enabled TV’s would switch the input to the Chromcast and display the camera at your front door.
My brain begins to hurt as all the possibilities for automation and security integration pile up. But hopefully, you get the point.
I’d love to hear from some of the other inventive people on this forum, and interested in the Chromcast. Again, what’s your idea?
Android stick with a BT android remote with cheapcast
Low power consumption httpd, ircd, VPN, or ssh.
Sent from my One true love.
The one thing I'd love to see the chromecast do is be able to connect directly to my phone and use it's 4g for streaming. I would figure something like this should be possible since it's basically what it does during initial setup.
Due to the layout of where I work (big concrete building), I get great signal with my phone in the window, but no signal anywhere else. i'd love to be able to plug the chromecast into the tv during breaks and stream from the phone.
evelbug said:
The one thing I'd love to see the chromecast do is be able to connect directly to my phone and use it's 4g for streaming. I would figure something like this should be possible since it's basically what it does during initial setup.
Due to the layout of where I work (big concrete building), I get great signal with my phone in the window, but no signal anywhere else. i'd love to be able to plug the chromecast into the tv during breaks and stream from the phone.
Click to expand...
Click to collapse
No during initial setup the chromecast generates its own wifi hostpost. Ofcourse this hotspot has no internet access and so would be useless for anything but setting up.
But why not make a hotspot with your phone? That would do the same thing.
I just want miracast support
Chromecast ideas
Chromecast supports multiple connections so could do things like a card game where player cards need to be private. The screen shows the playing field and each player sees just their cards on phone/tablet/computer. Is a simple example but there may be other uses to have multiple game play or interaction to same screen.
Chromecast and DIAL protocol are free to license so could be put into any consumer electronics device - SmartTV, refrigerators, home thermostat, etc.
xenokc said:
Chromecast supports multiple connections so could do things like a card game where player cards need to be private. The screen shows the playing field and each player sees just their cards on phone/tablet/computer. Is a simple example but there may be other uses to have multiple game play or interaction to same screen.
.
Click to expand...
Click to collapse
That is quite an awesome idea! Granted, I see it as a similar setup that the WiiU has tried to do with some of their games. And MS also with the "second screen" for xbox and such.
But why shouln't google get in on this tech as well? I'm very interested to start investigating this idea myself. Mind if I borrow your idea xenokc? lol
Unholyfire said:
That is quite an awesome idea! Granted, I see it as a similar setup that the WiiU has tried to do with some of their games. And MS also with the "second screen" for xbox and such.
But why shouln't google get in on this tech as well? I'm very interested to start investigating this idea myself. Mind if I borrow your idea xenokc? lol
Click to expand...
Click to collapse
Go for it!
Unholyfire said:
So I've seen many people, developers and users alike, swarming the ideas of the expected basic usages of this wonderful device.
Examples: Out-of-Box expected usage (streaming from qualified providers), mirrored A/V from PC/Phone/Tablet, other connectivity proof of concepts (IE: emulators), ect…
So my question is: What's your big idea to extend the usage of this device beyond "traditional" implementation?
I’ll start by sharing mine (actually 2 product idea’s, that could become 1 at some point in time).
1. All-in-one media station. Taking the concept of a HTPC/XBMC build, and extending it to have the Chromcast as the “presenter”, and the PC/Phone/Tablet as the “remote”. The software package would include a “media server” run on a compatible PC on the same network, accompanied by the “remote” app on the Phone/Tablet (web-based control for PC remote).
I intend to also include the ability to queue/control presentation files such as PPT, PDF, ect… I’d like to have the package useful to both home and business clients/users.
One of my favorite parts of this idea resides in the remote app. Upon selection of the media you intend to cast, use a 2-finger up gesture to begin casting (makes me think of the scene in IronMan2 when he takes over the monitors in the courtroom by using a similar gesture on his “phone”, lol) It’s the little things that get me excited haha.
2. A home automation/security media point. On demand or automated view of automation/security enabled objects in your environment. Example: You have a security system with camera’s in your home, specifically, one is mounted at your front door. Someone appears at your door (motion-trigger), and/or rings the doorbell (another available trigger). HDMI-CEC enabled TV’s would switch the input to the Chromcast and display the camera at your front door.
My brain begins to hurt as all the possibilities for automation and security integration pile up. But hopefully, you get the point.
I’d love to hear from some of the other inventive people on this forum, and interested in the Chromcast. Again, what’s your idea?
Click to expand...
Click to collapse
#1 will be done when Plex enables Chromecast functionality.
Hey im new to this chromecast. I can see my chrome browser on the pc but not on android, how can I do that? Sijce here are very experienced users oj chromecast can someone describe the full working potentials this device has?
Sent from my GT-N8013 using xda app-developers app
You cant do squat with Chrome on Android yet for some odd reason.
Tab casting from Chrome uses the host CPU to re-encode the video and stream it to the Chromecast on-the-fly. Tablet and phone CPUs don't have enough processing power. That's why there's no Chromecast extension for Chrome on your portable device.
Well that sucks bc there is possibilities with this chromecast. I downloaded the allcast and obviously updated my google services. I cast a picture and it doesnt show normal, shows rotated to the left. Can you cast from the gallery vids and photos?
Sent from my GT-N8013 using xda app-developers app
The man problem is the fact that Android Chrome does not support Chrome Apps and Extensions.
Something I'm told Google is working on...
Asphyx said:
The man problem is the fact that Android Chrome does not support Chrome Apps and Extensions.
Something I'm told Google is working on...
Click to expand...
Click to collapse
Yea they better be working on it, this has been out couple months now they need to update more
Sent from my GT-N8013 using xda app-developers app
Google is working on a way to mirror your android screen to the chromecast and we know this because on kitkat roms theres an option to cast screen but isn't quite working yet. Its only been coded in but thats it.
Sent from my SPH-L710 using Tapatalk
tooblackforjack said:
Google is working on a way to mirror your android screen to the chromecast and we know this because on kitkat roms theres an option to cast screen but isn't quite working yet. Its only been coded in but thats it.
Click to expand...
Click to collapse
KitKat roms have Miracast, a different protocol.
Supported by HTC and Samsung since 2012 with their private dongles.
Not new, sorry.
EarlyMon said:
KitKat roms have Miracast, a different protocol.
Supported by HTC and Samsung since 2012 with their private dongles.
Not new, sorry.
Click to expand...
Click to collapse
Yeah ik, i was just informing in case he didn't know sorry.
Sent from my SPH-L710 using Tapatalk
EarlyMon said:
KitKat roms have Miracast, a different protocol.
Click to expand...
Click to collapse
Yes, but Google has renamed it to Cast Screen. Clearly, they will be adding support for casting to Chromecasts directly inside of Android. Otherwise, renaming it to match the Chromecast nomenclature makes no sense.
bozzykid said:
Yes, but Google has renamed it to Cast Screen. Clearly, they will be adding support for casting to Chromecasts directly inside of Android. Otherwise, renaming it to match the Chromecast nomenclature makes no sense.
Click to expand...
Click to collapse
Because MiraCAST isn't confusing enough?
I'm aware that a number of blogs not familiar with Miracast are spreading that rumor. I think it's wishful thinking but we'll see, won't we?
http://www.howtogeek.com/177145/wir...ed-airplay-miracast-widi-chromecast-and-dlna/
http://readwrite.com/2013/11/07/android-kitkat-developers-users
A side note, Android 4.4 KitKat devices can now be certified by the Wi-Fi alliance as being Miracast compatible. That is a big step for Android in being able to stream content from a device to a television by supporting more streaming standards. Now only if the Chromecast supported Miracast.
Click to expand...
Click to collapse
http://www.androidpolice.com/tags/miracast/
So, you believe that WiFi Direct is coming to the existing Chromecast?
Or that in addition to Miracast, they'll be providing a second protocol for phones, with a server (like Koush did)? And people will be able to figure out the two casting options on their devices?
I think that it's far more likely that rather than put both protocols on a phone or into the existing Chromecast, it's more likely that DIAL support plus Miracast *might* appear in a Chromecast 2.
Miracast dongles already exist, it's February and the SDK libraries still aren't out, and in July, Chromecast will be a year old.
Apple TV costs $100 with this feature, a Belkin Miracast dongle is $80, an HTC Media Link HD is $100, the Samsung Allshare Cast Hub was a hundred, is $65 on Amazon now.
It's possible that Google is going to pump this in to the existing Chromecast for the faithful for free, but I'm just not feeling it.
Either way, so far KitKat includes Miracast, not DIAL.
EarlyMon said:
Or that in addition to Miracast, they'll be providing a second protocol for phones, with a server (like Koush did)? And people will be able to figure out the two casting options on their devices?
I think that it's far more likely that rather than put both protocols on a phone or into the existing Chromecast, it's more likely that DIAL support plus Miracast *might* appear in a Chromecast 2.
...
It's possible that Google is going to pump this in to the existing Chromecast for the faithful for free, but I'm just not feeling it.
Either way, so far KitKat includes Miracast, not DIAL.
Click to expand...
Click to collapse
First part:
Since it's (Android) device mirroring functions appear to be in the SDK, but are limited only to OEM developers, my best-guess is that what we'll see is any Chromecast device mirroring will have to be "cooked" into a ROM rather than a loose bit (makes sense - that's how Samsung's AllShare Cast works too).
Hopefully the UX engineers win and make it so the Screen Mirroring option at least combines Google Cast and Miracast device options together, rather than having separate options for Screen Mirroring (Miracast) and Screen Mirroring (Google Cast).
Second part:
Yeah, not going to hold my breath. As I keep saying, screen mirroring is not the core competency of Chromecast.
bhiga said:
First part:
Since it's (Android) device mirroring functions appear to be in the SDK, but are limited only to OEM developers, my best-guess is that what we'll see is any Chromecast device mirroring will have to be "cooked" into a ROM rather than a loose bit (makes sense - that's how Samsung's AllShare Cast works too).
Hopefully the UX engineers win and make it so the Screen Mirroring option at least combines Google Cast and Miracast device options together, rather than having separate options for Screen Mirroring (Miracast) and Screen Mirroring (Google Cast).
Click to expand...
Click to collapse
Both together sounds like a bit much, but it's possible.
Samsung is likely going their own way.
http://www.slashgear.com/samsung-an...ultiscreen-and-overlay-capabilities-28303309/
Second part:
Yeah, not going to hold my breath. As I keep saying, screen mirroring is not the core competency of Chromecast.
Click to expand...
Click to collapse
Agree.
If you ask me any attempt to make CCast work like a Miracast would be a big waste, Even a downgrade!
No need for Direct Connection for Mirroring as Mirror over IP is far more flexible and less problematical. Not to mention requires no special software support like Miracast does. If they really wanted Miracast type direct mirroring all it would take is some additions to the rom cause hardware wise, the CCast has everything it needs
It may not be part of why the CCast was developed but I don't see Google being as smart as they are leaving that market open to Miracast dongles when they know full well the only thing inhibiting CCast from doing it (and better) is their lack of developing an App that does it for Mobile...
As for the Casting support in the SDK for OEM use I suspect that is more generic in nature and just an exposure of the display system to support Miracast, Perhaps CCast Mirroring and any other 2nd screen tech that comes down the pipe.
I think mirroring feature is a bit overrated myself, it's good for an audience but not for an operator's use.
It's easier to do than what CCast is trying to do because there is no need for a control protocol...Just a simple transcoder for Video and Audio the rest is all done on the Master Display device.
As for that Samsung option I don't expect it to take off due to proprietary concerns. It's meant for Samsung SmartTVs and I bet LG and Sony won't support it. Samsung would be better off building that capability directly into the TV itself.
DIAL is still in its infancy and I expect the protocol to expand as support and adoption of it grows...
Whatever lessons they learned from Chromecast I expect to be addressed whenever they get around to making the second gen CCast.
Wired Networking or at minimum 5Ghz Wireless support is to be expected as would a more robust Video playback Compatibility.
It's not likely that any app that adds CCast support is going to remove it in the future which means as the Apps list grows so too does the chance we have of seeing this supported without the need for a dongle at all.
TV over the Web will work the way it was supposed to and remove the biggest hurdle to achieving full IPTV to date...
The Navigation and Channel Guide no one could figure out how to do....
And who knew the Web Browser was the answer all along.
Samsung is still the largest supplier of flat screen TVs in North America, is it not?
Besides, they've never been shy about adding interfaces to support the future. I have a Samsung TV with a specialized iPod interface as proof. (And I believe that the article did say clearly that Samsung was going to build the new casting into their TVs.)
And none of the TV makers think twice about adding fragmenting features, and Samsung certainly doesn't for their mobile devices.
As for the claim that it's just about making a mobile app and declaring victory for screen casting, you might want to review the API changes that have been evolving for months.
Doing that without library support and not differentiating DRM vs non-DRM cast calls may seem simple to you but it doesn't to me.
Last published, Netflix and YouTube accounted for over 50% of North American broadband traffic.
Screen casting may be an emerging market, or it could just be a flash in the pan.
EarlyMon said:
Samsung is still the largest supplier of flat screen TVs in North America, is it not?
Besides, they've never been shy about adding interfaces to support the future. I have a Samsung TV with a specialized iPod interface as proof. (And I believe that the article did say clearly that Samsung was going to build the new casting into their TVs.)
And none of the TV makers think twice about adding fragmenting features, and Samsung certainly doesn't for their mobile devices.
As for the claim that it's just about making a mobile app and declaring victory for screen casting, you might want to review the API changes that have been evolving for months.
Doing that without library support and not differentiating DRM vs non-DRM cast calls may seem simple to you but it doesn't to me.
Last published, Netflix and YouTube accounted for over 50% of North American broadband traffic.
Screen casting may be an emerging market, or it could just be a flash in the pan.
Click to expand...
Click to collapse
Well I guess Samsung is the largest supplier of Flat Screens in NA just like Apple is the biggest supplier of Smart Phones in NA...
Until you realize combine all the NOT Samsung Models into an US vs THEM and they are not the Majority by any means...Same with Apple vs Android as opposed to Apple vs Samsung itself.
As for the DRM you forget that DIAL doesn't care and leaves using or not using up to the content provider. It's there if you want it and if not you only have to support the DIscover and Launch capabilities.
Is Sony (who owns a majority of content compared to Samsung) going to cut out DIAL for Samsung's proprietary system?
Doubtful!
And since the CCast and DIAL supports ANY TV with HDMI input it has a far better chance of being adopted as a standard than Samsung's device is.
IMO most of the current desire for screencasting is really a "backup plan" for content that is currently not supported via DIAL. "___ isn't supported so I want to mirror my screen/tab."
So the mainstream correct solution would be to get the desired content providers on-board with Google Cast.
That would leave non-"canned" content for screen mirroring (games in a second screen model, general browsing, presentations, Skype, etc).
I'd love to see a native Skype for Chromecast using the microphone and controls on my tablet/phone with video on the TV but keeping it in sync might be nontrivial engineering on the Skype end.
Asphyx said:
As for the DRM you forget that DIAL doesn't care and leaves using or not using up to the content provider. It's there if you want it and if not you only have to support the DIscover and Launch capabilities.
Click to expand...
Click to collapse
I can only invite you, again, to look at the actual casting API rather than rely on assumptions.
It's NOT the same as that last July and it absolutely, positively does recognize casting DRM content.
Start here -
https://groups.google.com/a/chromium.org/forum/m/#!topic/apps-dev/emlKA4C-c90
And then Google for what's happened since, along with Koush's commentaries.
Is Sony (who owns a majority of content compared to Samsung) going to cut out DIAL for Samsung's proprietary system?
Doubtful!
And since the CCast and DIAL supports ANY TV with HDMI input it has a far better chance of being adopted as a standard than Samsung's device is.
Click to expand...
Click to collapse
Did you even read the article to discover that Samsung is using a superset of DIAL and support by Sony, LG, and Panasonic TV sets is expected?
---------- Post added at 04:14 PM ---------- Previous post was at 04:07 PM ----------
bhiga said:
IMO most of the current desire for screencasting is really a "backup plan" for content that is currently not supported via DIAL. "___ isn't supported so I want to mirror my screen/tab."
So the mainstream correct solution would be to get the desired content providers on-board with Google Cast.
That would leave non-"canned" content for screen mirroring (games in a second screen model, general browsing, presentations, Skype, etc).
Click to expand...
Click to collapse
Have you checked out what Vbukit is planning on supporting with Chromecast?
Pretty interesting, I think.
Not sure about getting Skype sorted out.
It seems like every time Skype updates, it's a step backwards, but that's just my off-topic opinion.
EarlyMon said:
Have you checked out what Vbukit is planning on supporting with Chromecast?
Pretty interesting, I think.
Not sure about getting Skype sorted out.
It seems like every time Skype updates, it's a step backwards, but that's just my off-topic opinion.
Click to expand...
Click to collapse
Yes, Vbukit is a little rough around the edges, but I can definitely see it being useful for presenters and educators especially.
Agree with you on Skype...
Back on-topic, there isn't a lot of technical copyright/DRM concern regarding casting anything you see on the screen - after all, if you can see it on the screen, you've seen it already. It's just that the legal types are not technical, highly likely to make crazy conclusions and assumptions, and get paid no matter what they do - so it's in their best interest to make issue of little things. I've personally seen warnings from the copyright hunters complete with ISP traces down to the router endpoint too, so they are watching and waiting to pounce.
I still hope an optimized device mirroring comes as something deeper within the Android OS itself.
Something akin to RemoteX in the Windows space, which is a "remote render" or offload of the graphic drawing functions. Anything that's not reliant upon a local bitmap could be rendered on Chromecast, rather than sent as large/inefficient bitmap data or CPU-intensive compressed data. That would make some "twitchy" games playable, especially if Chromecast has enough memory/storage to cache bitmaps that it does end up needing. Full-screen video, of course, doesn't benefit, nor does typical FPS games since the entirety of the screen is being updated with bitmaps.
For fun, I played a video on my phone and watched it on my computer (no audio) via TeamViewer. It took me back to the early 90's.
We've waited for apps and other optimized content this long, let's see what Google delivers.
Content providers have been successfully inhibiting HDMI and MHL output from their apps running on Android devices.
I believe that the casting API changes may have them in mind, but that's pure conjecture on my part.
I think it's ridiculous but so long as people check the boxes and agree to the terms of service, they're free to enforce it.
Hello i'm kind of new to this so please don't be to harsh .
To run Android TV, android 5.0 would need to be ported first thus me titling this "Is it Possible to Android 5.0 / Android TV on Raspberry Pi 2?" However my main subject / me making this post is to see if Android TV on Pi 2 is feasible.
I was thinking would be possible to run Android TV on the new Raspberry Pi? I ask this because the specs of the new Pi 2 are quite impressive and I can totally see this becoming popular as I can imagine a lot of people would go out and buy a Pi just to run android tv on it (me being one of them) . This would be great as not only would it provide a large install base for Android TV (which in turn up the developer support) it would make it so almost anyone can have a cheap chrome cast type of device with a functional GUI. I don't know if this is possible but doing some research I can't see any reason why it would't work and it would make for such a cool and inexpensive android tv box! :good:
Possible short comings would be:
Lag due to low clock speed
Lack of a remote (possible use of a bluetooth controller or a smart phone app to control the box using wifi)
Poor Gaming capabilities?
Probably a few more.
Thomas_Bam said:
Hello i'm kind of new to this so please don't be to harsh .
To run Android TV, android 5.0 would need to be ported first thus me titling this "Is it Possible to Android 5.0 / Android TV on Raspberry Pi 2?" However my main subject / me making this post is to see if Android TV on Pi 2 is feasible.
I was thinking would be possible to run Android TV on the new Raspberry Pi? I ask this because the specs of the new Pi 2 are quite impressive and I can totally see this becoming popular as I can imagine a lot of people would go out and buy a Pi just to run android tv on it (me being one of them) . This would be great as not only would it provide a large install base for Android TV (which in turn up the developer support) it would make it so almost anyone can have a cheap chrome cast type of device with a functional GUI. I don't know if this is possible but doing some research I can't see any reason why it would't work and it would make for such a cool and inexpensive android tv box! :good:
Possible short comings would be:
Lag due to low clock speed
Lack of a remote (possible use of a bluetooth controller or a smart phone app to control the box using wifi)
Poor Gaming capabilities?
Probably a few more.
Click to expand...
Click to collapse
My research indicates this would be difficult, however, if a Chromecast type Media Center is what you're looking fo, I have good news. There are 2 OS downloads that are essentially XBMC ports for Pi 2.
http://www.raspberrypi.org/downloads/
I bought a Pi 2 today and am waiting for them to provide a delivery date. I intend to use it with one of these XBMC OS'S.
Thomas_Bam said:
Hello i'm kind of new to this so please don't be to harsh .
To run Android TV, android 5.0 would need to be ported first thus me titling this "Is it Possible to Android 5.0 / Android TV on Raspberry Pi 2?" However my main subject / me making this post is to see if Android TV on Pi 2 is feasible.
I was thinking would be possible to run Android TV on the new Raspberry Pi? I ask this because the specs of the new Pi 2 are quite impressive and I can totally see this becoming popular as I can imagine a lot of people would go out and buy a Pi just to run android tv on it (me being one of them) . This would be great as not only would it provide a large install base for Android TV (which in turn up the developer support) it would make it so almost anyone can have a cheap chrome cast type of device with a functional GUI. I don't know if this is possible but doing some research I can't see any reason why it would't work and it would make for such a cool and inexpensive android tv box! :good:
Possible short comings would be:
Lag due to low clock speed
Lack of a remote (possible use of a bluetooth controller or a smart phone app to control the box using wifi)
Poor Gaming capabilities?
Probably a few more.
Click to expand...
Click to collapse
Probably the same conclusion as this:http://forum.xda-developers.com/hardware-hacking/raspberry-pi/rd-android-4-4-4-t2816952
XBMC for RPi already supports CEC through the HDMI... So most of your remote problems are solved there. A wireless Bluetooth keyboard/touchpad also solves the problem.
Yes, I can confirm that, I'm using osmc(aka raspbmc) for more that one and a half years and the performance is a quite good, even if I have allot of other things running on my pi...
CEC is supported, but be careful if you own a LG webos tv you should not us this, cause will slow down your tv and make it unresponsive, as far as I know only webos TVs are afected(2014 models).
But anyhow if raspbmc has a good performance on the old rpi B, I think should perform way faster on the new pi2.
I'm planning also to upgrade my pi..
From what is being reported on the Kodi forums, the Pi2 does very well with it. There is already a branch of OpenElec for it, and I think also one for RaspBMC/OSMC with a lot of the add-ons under recompilation during this week to give full support. But it's certainly getting full support from the dev community there, which is great.
But as noted even the Pi1 does very well anyway with Kodi, my overclocked B+ with OpenElec 5.0.1 works fine with it and no issues at all that I encounter day to day. Nice and smooth, and fully supports CEC from my (dumb) LG HDTV. And if you prefer, there's decent remote control for Android/iOS (Yatse) and web-based remote built into Kodi itself.
I'd certainly recommend it as an excellent alternative to AndroidTV.
The Android porting issue is the lack of graphics chip support
I'm wanting to see this as well, namely because Android TV also offers direct support for Netflix, Hulu, Plex, and others. While you can potentially get these with an xbmc based build, it will not work well with remotes.
Rakeesh_j said:
I'm wanting to see this as well, namely because Android TV also offers direct support for Netflix, Hulu, Plex, and others. While you can potentially get these with an xbmc based build, it will not work well with remotes.
Click to expand...
Click to collapse
The Pi supports CEC, so if you've got a suitable TV and the two are connected by HDMI then you're fine to go. I run my OpenElec set-up on my Pi1 using the remote of my LG dumb TV, and it's a doddle. It does have a wireless keyboard and mouse connected to it for it's other life as a Raspbian programming box for the kids (Scratch/Minecraft/Python) but I don't recall the last time I took up either when it was running in its OpenElec identity...
There is certainly an implementation of Plex for OpenElec. Not sure about the others, as I don't use any of them.
DarrenHill said:
The Pi supports CEC, so if you've got a suitable TV and the two are connected by HDMI then you're fine to go. I run my OpenElec set-up on my Pi1 using the remote of my LG dumb TV, and it's a doddle. It does have a wireless keyboard and mouse connected to it for it's other life as a Raspbian programming box for the kids (Scratch/Minecraft/Python) but I don't recall the last time I took up either when it was running in its OpenElec identity...
There is certainly an implementation of Plex for OpenElec. Not sure about the others, as I don't use any of them.
Click to expand...
Click to collapse
That isn't the problem. The remote itself works ok, and the device can see the events. The problem is the individual applications require different key bindings. I've done all of that crap where you configure different profiles and whatnot to bind different remote presses depending on the app, but it breaks all the time and maintaining it sucks balls.
Not doing that again. It's better just to have one cohesive interface that each app responds to identically. Android TV provides exactly that.
Two years ago, tried a hand at Android 2.3 on the Raspberry Pi after seeing an article on Cnet.
:silly:
Utterly terrible failure. They have then proceeded to pulled the article down.
YES, it's possible, GUI at 10-15fps with SW rendering. Slow but useable.
confused
I don't understand. Broadcom has released the sourcecode for the gpu including register-level documentation.
http://blog.broadcom.com/chip-desig...ves-developers-keys-to-the-videocore-kingdom/
The downloads are at the bottom of the http://www.broadcom.com/support/ page.
ddfault said:
I don't understand. Broadcom has released the sourcecode for the gpu including register-level documentation.
http://blog.broadcom.com/chip-desig...ves-developers-keys-to-the-videocore-kingdom/
The downloads are at the bottom of the http://www.broadcom.com/support/ page.
Click to expand...
Click to collapse
Actually, the problem is not that(the stack was adapted to GNU/Linux, see github.com/simonjhall/challenge but with memcpys), it is just that it depends on a Linux 3.0 kernel driver for full functionnality(HW layers). That driver is still not ported to modern kernels(the official RPi kernel is 3.19!)
It is fully doable. On IRC with the primary developer of Replicant, he said that porting Mesa/VC4 with adding Android support would take a few time with mostly buildsystem changes .(he ported llvmpipe)
CFP with a comment
I would like to use Android version 4.2.2 Jellybean! on my RP2+, Please understand i don't really quite understand everything you guys are saying, I just would like a straight answer, can it be done? My pi is version 2+ 512MB ram not the four core version.
THANKS!
Clancey A
tyrian869 said:
I would like to use Android version 4.2.2 Jellybean! on my RP2+, Please understand i don't really quite understand everything you guys are saying, I just would like a straight answer, can it be done? My pi is version 2+ 512MB ram not the four core version.
THANKS!
Clancey A
Click to expand...
Click to collapse
No. Check back in 6 months, maybe someone will have Lollipop running on it by then!
Android TV on Raspberry Pi 2... That's a dream...
Well, I have a question...
Got the Raspberry Pi 2 with 512MB of ram, and I've tested the beta Android found here, and it's usable (just usable, it has lag, and many things can be done to it to became perfect). Why doesn't anyone try to port that Android on Raspberry Pi 2? Now we have a 900Mhz Quad Core CPU and double the ram...
Could you please provide mode details?
What' the issue with the Wi-Fi?
How is the general performance of the Lollipop?
Do you have Play Store installed?
khrystyan27 said:
Could you please provide mode details?
What' the issue with the Wi-Fi?
How is the general performance of the Lollipop?
Do you have Play Store installed?
Click to expand...
Click to collapse
"not worth much without hardware acceleration", i would say its totally useless.
Hi everyone, first time poster so I'm sorry if this isn't the right forum to post in, but I felt like it was the closest I could think of.
I'm trying to find a way to mimic how the chromecast causes a tv to switch to the input of the chromecast dongle. I have an Android Box that came rooted and has HDMI-CEC capability. What I'm looking to do is somehow use Tasker to trigger the CEC-switch activity/intent/whatever to have my tv (turn on) and switch to the HDMI source of the Android Box (the box will be left on 24/7 and tasker will continually run as background service on the box). Basically, I'm trying to imitate the chromecast's cast action to bring me to my Android Box's input and ultimately it's home screen.
That's where I'm stuck at the moment. Things I've thought might work:
1. Wake-On-Lan (Doesn't seem to wake the box, even when I've checked to make sure the power button made the box sleep and not perform a full shutdown) Tried-Unsuccessful
2. AutoCast to have the box cast to itself, but it doesn't have chromecast/miracast/etc built-in as far as I can tell according to the specs and see anything about cast ability while browsing through its menus.
3. Using Android's HDMI-CEC library in a Java Action in Tasker to imitate the CEC switch sources intent/activity. However, I just recently learned that Google decided to lockdown their API for HDMI-CEC interactivity, so that scrubs that idea.
4. The best bet, and what gave me the idea to post here, is this App Cast Receiver that was created by another user on these forums that seems to accomplish something close to what I'm trying to do in allowing an android device to imitate a chromecast device. If I were able to use this couldn't I then use the AutoCast app I mentioned above to have the Android Box cast to itself, then stop the AutoCast app a few seconds later (after giving the box's CEC capability enough time to make the tv switch sources)? But, unfortunately it appears the app has since been deserted and won't work with the newer chromecast sdk. Maybe someone has an alternative app?
Since this is my first Android Box I'm not quite sure how Tasker actions function when ran from the box. Example: Would a Wake Screen Action trigger a switch of HDMI inputs?
So, after exhausting all my ideas after coming up with nothing in my searches I figured I'd ask the community here since this seems to be a pretty dev/mod-heavy community (and I love it). I'm not sure if this would be better suited for the Tasker or AMLogic Android Box forums on here. If so, I'll happily move the post if a mod cannot do so for me.
TL;DR: Looking for some way, be it app or otherwise, to imitate chromecast behavior (utilizing CEC) in order to make tv switch source to a running Android Box's homescreen.
Hey! tell me more about 3, I was looking to have a Raspberry Pi act as a go-between to simulate CEC with a non-CEC TV by receiving my remotes IR codes and sending either CEC codes to the ChromeCast or using the CC API to pause/stop play - but only reverse engineered versions are available on Pi.
The Pi has built-in CEC support so you can use `apt-get install cec-tools` and then play with the `cec-client` to do some interesting stuff. The ChromeCast in my case has an invalid address so I don't seem to be able to activate pause play. (I see a logical address of 4 but also an address of `f.f.f.f`, ie invalid).
Anyways, it may be worth playing with a Pi and seeing if HDMI-CEC will do what you want, and then seeing if you can get a CEC library for android and just recreate the Pi work. Less hoops to jump around.
I don't know enough about the Android side. The CC API has an Android implementation so I would think you'd be able to do everything you want, iff it does the switching. I've done very little development on Android (a meteor app and an Android native camera library work), unfortunately. (If the Pine64 supports CEC I may end up going down this route).
I've posted more about my interest here: on reddit /r/Chromecast/comments/5znpuk/i_want_to_use_a_raspberry_pi_to_control_the/
jlongman said:
Hey! tell me more about 3, I was looking to have a Raspberry Pi act as a go-between to simulate CEC with a non-CEC TV by receiving my remotes IR codes and sending either CEC codes to the ChromeCast or using the CC API to pause/stop play - but only reverse engineered versions are available on Pi.
The Pi has built-in CEC support so you can use `apt-get install cec-tools` and then play with the `cec-client` to do some interesting stuff. The ChromeCast in my case has an invalid address so I don't seem to be able to activate pause play. (I see a logical address of 4 but also an address of `f.f.f.f`, ie invalid).
Anyways, it may be worth playing with a Pi and seeing if HDMI-CEC will do what you want, and then seeing if you can get a CEC library for android and just recreate the Pi work. Less hoops to jump around.
I don't know enough about the Android side. The CC API has an Android implementation so I would think you'd be able to do everything you want, iff it does the switching. I've done very little development on Android (a meteor app and an Android native camera library work), unfortunately. (If the Pine64 supports CEC I may end up going down this route).
I've posted more about my interest here: on reddit /r/Chromecast/comments/5znpuk/i_want_to_use_a_raspberry_pi_to_control_the/
Click to expand...
Click to collapse
Here's the link to Android's documentation for the HDMI-CEC Control Service. But, like I said it's been locked down and only allows system-level access now.
I don't have any Pi at my disposal (plus my Android Box also has built-in CEC-capability/functionality) and since my situation doesn't actually involve chromecast I never thought to look at their api/sdk. But, I was able to finally solve my problem with a painfully simple, yet not that intuitive or logical method. The way my box's os/firmware appears to work is by firing the cec signal to switch inputs only on its boot_complete and wake_from_standby procedures. My solution just simulates pressing the Standby button twice in a row via Shell command (with Root option checked) from within Tasker. Logically, I thought after the first press the box wouldn't respond to the second press due to already being in standby mode (because of the first button press). But, it turns out both simulated presses occur (maybe keyevents are queue?), allowing me to put the box in standby momentarily and immediately bring it out of standby, which triggers the wake_from_standby procedure and in turn causes the input to switch (or my tv to turn on then input to switch).
My thought with the Pi and CC API was that you would use the PI to monitor the HDMI-CEC bus as the output is controlled by the CC - assuming it switches the input to itself but my TV doesn't support HDMI so maybe that's a bad assumption - and then use that knowledge to replay using the Android HDMI-CEC API. And not understanding what you meant by the API being locked down. That kind of sucks - I was hoping Android would be another bridge platform if the Pi failed me.
Well congrats on a working solution. Cheers!