it is possible for the g1 to print wirelessly right?
is there a program out there that i dont know about that lets you do this? , because i've been looking but found nothing.
I guess it hasn't been created yet.......?
I would love this functionality as well since my printer is wireless. Would be great but I dont know if it will happen.
It is most definitely possible, but has not been implemented.
What you need in order to print;
install CUPS,
add application support.
If you have debian installed, you most certainly will already have the ability to print.
Note that even if CUPS was installed, you would not be able to print from ANY existing android application since they lack this functionality.
CUPS is the common unix printing system (developed by Apple). In Windows, when you buy a printer, you trust that, either the manufacturer has given you a working driver to install from a CD, or that Windows' endless array of popups will find it for you.
On unix-alikes, you toss the CD and trust that CUPS and its dependencies will have a serviceable driver already.
So no, you shouldn't have to make specific devices for each printer. They should already exist if CUPS supports them.
reviving old thread
with the ability to view PDFs and office docs as well as view and edit google docs via the browser it would be great to be able to discover networked printers and spool print jobs to them, any chance of this functionality coming around sometime soon?
innerspace said:
with the ability to view PDFs and office docs as well as view and edit google docs via the browser it would be great to be able to discover networked printers and spool print jobs to them, any chance of this functionality coming around sometime soon?
Click to expand...
Click to collapse
I found an app awhile back that will let you print wirelessly the only thing you have to do is download a file onto the pc.
thats printershare
which is an ok solution i suppose, but does require a print server app to be installed on the host pc. I'd rather have the ability to browse the network from android and choose an existing printer as a target then use cups or try to install the driver via the web. Big issue with android apps not supporting this though, probably not going to happen. bummer really.
yeah i tried out the app and installed it on my g1 and file server. after i launched the app it showed its major flaw. If security permissions are not set on the host pc your printer shows online for everyone who is running the app. i saw printers from all over the country. i thought about sending a print job but didnt
^^lol^^
I thought the same thing. Plus it just didn't work. too funny.
Until there is a solution that uses IPP and not somebody's proprietary crud, there is no network printing solution for 'droid.
Does anyone know how to make a website that can only be viewed by an android phone? Like how the iPhone has websites only viewable by iPhones & iPod Touches? If you do can you post a tutorial on how it could be done? Thanks
Check the "User-Agent" from the HTTP request.
Short php code that switch the site (not tested, should work)
PHP:
<?php
if(preg_match("/android/", $_SERVER['HTTP_USER_AGENT']))
{
header('Location: androidSite.php');
}
else
{
header('Location: normalSite.php');
}
?>
Or you use getBrowser()
And then you have just to fit the design of the design or do what you want
The only way to actually stop non-android devices from accessing the website is to force the android users to install an android-only plugin to be installed in the browser (not supported by default browser) or to use a custom browser. Said plugin will authenticate with your service using only-you-know credentials, thus preventing any non-android device from accessing it. The user agent is REALLY REALLY simple to fake.
lbcoder said:
The only way to actually stop non-android devices from accessing the website is to force the android users to install an android-only plugin to be installed in the browser (not supported by default browser) or to use a custom browser. Said plugin will authenticate with your service using only-you-know credentials, thus preventing any non-android device from accessing it. The user agent is REALLY REALLY simple to fake.
Click to expand...
Click to collapse
If you want to be absolute about it, it would not be outside the realm of possibility to reverse engineer the authentication output of the hypothesized plugin and create a workaround. Furthermore, as the plugin would likely be an arm binary library, there's probably not that much preventing it from being run (reasonably) on any arm-based system.
user-agent is probably (i'm guessing) enough for what the OP has in mind.
Here you can generate your own script:
http://detectmobilebrowsers.mobi/
For example: iPhone devices redirect to ebay for buying a android device
and Android Browsers comes in.
PHP:
include('mobile_device_detect.php');
mobile_device_detect('http://shop.ebay.com/i.html?_nkw=android&_armrs=1&_from=&_ipg=','http://website.com/android.html',false,false,false,false,false,false);
Download the PHP script for non commercial sites here:
http://detectmobilebrowsers.mobi/#download
It may be possible to reverse engineer it (not necessarily in case it is actually well designed), but even if it is, it would be non-trivial, even if implemented by an idiot. Changing the UA *is* trivial, even to a complete moron.
And who says it has to be an arm binary library? Maybe go with something in javadroid instead.... and link it to the device IMEI... using a time-based crypto function that only runs on your server, i.e. device --> server crypto service --> device with magic enabler key --> web server authentication. You can make something REALLY MESSY that nobody would bother to reverse, and something that can only run in android (i.e. dalvik). Sure dalvik can be run on other 'nix systems, but by doing so, they become quasi-droid anyways...
jashsu said:
If you want to be absolute about it, it would not be outside the realm of possibility to reverse engineer the authentication output of the hypothesized plugin and create a workaround. Furthermore, as the plugin would likely be an arm binary library, there's probably not that much preventing it from being run (reasonably) on any arm-based system.
user-agent is probably (i'm guessing) enough for what the OP has in mind.
Click to expand...
Click to collapse
When I am at work I would like to check that balance on my debitcard through my banks online services.
But to access this there needs to be installed Java on my workstation. But my employer doesn't want to have Java on their machines so I can't access my bank online service.
My question is there a website like the websites which offers anonymous surfing where the service I am looking for offers Java so I get access to my banking services???
Unfortunately, Java runs purely on the client machine, so it's not possible in the manner you request. The only way I could see it being possible is if you actually browsed the site on a remote connection. Do you leave your home PC on? If so, maybe it's worth setting up Remote Desktop, or Logmein (or similar).
Since chromecast simply get an url or data to play content already "on the cloud", it will be possibile to emulate its behaviour with a chrome extension or something like that?
I'd love to use a chromecast-like interface on my desktop pc...
p.nightmare said:
Since chromecast simply get an url or data to play content already "on the cloud", it will be possibile to emulate its behaviour with a chrome extension or something like that?
I'd love to use a chromecast-like interface on my desktop pc...
Click to expand...
Click to collapse
I'd second that. I'd love to see the ability to chrome cast TO a (widows) chrome browser.
I have a number of MCE PC's connected to HD TV's and computer with monitors throughout the house that would be great as the recipients of "casting".
At work I'd like to be able to look something up on my phone and then sent it to my nearest PC browser...
htcsens2 said:
I'd second that. I'd love to see the ability to chrome cast TO a (widows) chrome browser.
I have a number of MCE PC's connected to HD TV's and computer with monitors throughout the house that would be great as the recipients of "casting".
At work I'd like to be able to look something up on my phone and then sent it to my nearest PC browser...
Click to expand...
Click to collapse
You mean like this? - http://goo.gl/NOoel
You won't be able to push Netflix to the browser the same way, but you can certainly do so with web content.
Jason_V said:
You mean like this? - http://goo.gl/NOoel
You won't be able to push Netflix to the browser the same way, but you can certainly do so with web content.
Click to expand...
Click to collapse
Yeah kind of like that but completely integrated into he chrome cast infrastructure and APIs so that it is compatible across all apps and is just one click on the new "cast" buttons that are cropping up at the top of all my Android apps now .... (Netflix, Youtube, Google music etc.)
There has been talk of 3rd party hardware makers being encouraged to support the standard so shouldn't be too hard to do proper chrome browser integration as a target.
I can't believe no one has thought of it yet :fingers-crossed:
here
p.nightmare said:
I can't believe no one has thought of it yet :fingers-crossed:
Click to expand...
Click to collapse
Here you go github.com/dz0ny/leapcast
dz0ny said:
Here you go github.com/dz0ny/leapcast
Click to expand...
Click to collapse
awesome! I will definitely keep an eye on that :good: :good:
Nodecast is also an option
p.nightmare said:
awesome! I will definitely keep an eye on that :good: :good:
Click to expand...
Click to collapse
Beside Leapcast (which is implemented in python), there is a JavaScript-/Node.js-Port in Git-Hub available. The port was made by Sebastian Mauer, the guy who wrote Cheapcast.
I spend the last weekend exeperimenting with both Nodecast and Cheapcast. Now Nodecast runs here in a Windows 8.1 virtual machine - and I'm able to stream from other Windows and Android-devices.
I wrote a few tutorials, how to setup Nodecast on Windows (it also possible to use similar steps in Mac OS X or Linux). The tutorial is currently only in German - but Google translate shall do the job.
Nodecast setup for Windows-tutorial: http://goo.gl/2ZU5Mm
Maybe it helps
Leapcast 2.0?
Anyone still working on Leapcast now that the 2.0 SDK came out? Lots of changes like going from DIAL to mDNS for one. Leapcast was very handy for running on a PC that was already connected to the TV. Sadly, all the apps compiled against the newer SDK won't work with it. They won't even discover it as a Chromecast now.
https://chrome.google.com/webstore/...oakcolegkcddbk?utm_source=chrome-app-launcher
This was an attempt to do this but I never got it to work on my side.
Unfortunately, SDK 2.0 requires the Chromecast to calculate key using certificate issued by Google. We will probably wait a long time to see leapcast, CheapCast and NodeCast working again. It might not be even possible at all.
Johny_G said:
Unfortunately, SDK 2.0 requires the Chromecast to calcate key using certificate issued by Google. We will probably wait a long time to see leapcast, CheapCast and NodeCast working again. It might not be even possible at all.
Click to expand...
Click to collapse
Not the best news, but thanks Johny for the insight.
If all the rooted ROMs can handle SDK 2.0 and Google's new authentication, there's probably a way to get the emulators up and running with it. Just a matter of time and determination I hope. I wish Google was a bit more open on the software side for the Chromecast. Having the new SDK for sender/receiver apps is great, but allowing companie/people to recreate the piece in the middle would also benefit them I would think. It would be tough for people to beat the Chromecast's price tag, but having other options would be good.
Averix said:
Not the best news, but thanks Johny for the insight.
If all the rooted ROMs can handle SDK 2.0 and Google's new authentication, there's probably a way to get the emulators up and running with it. Just a matter of time and determination I hope. I wish Google was a bit more open on the software side for the Chromecast. Having the new SDK for sender/receiver apps is great, but allowing companie/people to recreate the piece in the middle would also benefit them I would think. It would be tough for people to beat the Chromecast's price tag, but having other options would be good.
Click to expand...
Click to collapse
I wouldn't hold my breath. The ROMs get the upgrade essentially "for free" as it's part of the stock ROM code. Maybe the desktop players can take advantage of that, probably not, especially if it's a binary or relying on some kind of TPM or other function in the Chromecast hardware itself.
Having options is good for the consumer, but for a manufacturer, more options = more competition = more mouths to feed = lower margins = more work to keep competitive. One of the reasons Apple is so aggressive about protecting the exclusivity of its platform.
Warning! TL;DR below!
The point is, that every single Chromecast device has its unique ID, its unique MAC Address, and its (unique?) signed certificate. Also, it might have some kind of ID generated when you set the device up (similar to Push ID used in Google Cloud Messaging). Some of those (maybe all of them) have to play together to calculate the key. As soon as you pull the certificate out and put it in different environment, the result of the calculation won't match the SDK's expectations. So there is pretty good chance, that bypassing the key might be completely impossible without modifying the SDK itself (and it would require the developers to actually invest some effort to support these alternatives) and maybe the Chromecast device software as well. But who knows, the guys involved in those "emulators" are way smarter than most of us and might figure something out .
This is the biggest issue. The other one is, that everything has changed in the new SDK/API, and all of the methods used in those emulators are now deprecated and need to be implemented all over again in a different fashion to work with 2.0. This might actually be a good thing, since developers involved in testing of the way-too-rushed 1.0 seemed not to have a lot of kind words to say about it. I have attended one Chromcast block on a local conference, and it was basically 2 hours of swearing.
I've stumbled upon these issues today (and a bit of yesterday), trying to get my app working in the office (I forgot my Chromecast at home - again), and here are some sources if you are more interested in the topic:
https://plus.google.com/+SebastianMauer/posts/83hTniKEDwN
https://github.com/dz0ny/leapcast/issues/29#issuecomment-37288608
https://github.com/dz0ny/leapcast/issues/96
As a developer, I have to say, that Google is making things awfully difficult lately, and the "don't be evil" policy seems to slowly fade away. They put way too much effort into marketing decisions, and have no time to properly test APIs and SDKs before they spit them out . Mostly, when trying some new Android-related technology (to be honest, its mostly Google Play Services technology these days, so AOSP starts to be completely useless), I spend most of the time working around things that nobody thought of (i.e. the Translucency API in KitKat was obviously tailored for Google Now Launcher, and is a huge PITA tu be used elsewhere) and fixing the broken samples that come with them. It might seem weird, but sometimes (say hello to Play Games Services and in-app billing v1+v2!) the sample is inseparable part of the final implementation, so you have to fix their rushed code anyway. I shouldn't be complaining, since things like that raise the value of developers willing to go through all of this in their spare time, but the change of philosophy still bugs me a lot. Google and Android used to be strongly community-oriented, and now the marketing is pulling it all away.
Should the goal really be to emulate a Chromecast or should the effort be geared toward supporting DIAL protocol?
I would think the latter is the better option because you could support whatever the hardware supports without the limitations imposed on us from CCast Hardware.
Maybe I'm wrong but I always looked at DIAL as an extension of UPnP and separate from the CCast itself and the Chromecast SDK as not much more than a kit to add DIAL support to Android (and iOS) not meant to build anything on the CCast side at all.
Other companies like Roku are planning some DIAL support and I doubt highly they will have a CCast ID and Certificate.
In the end I think we will get something similar to this functionality from a player app like VLC on PC and MAC, or perhaps in Chrome itself.
Cause I think (and I may be totally wrong here) that it isn't the Apps we use that checks the Whitelist and IDs it is the CCast itself that when invoked to load a player app to stream it also checks the whitelist and tests security before it plays.
SO if someone created a program for PC that made the PC announce itself as a DIAL capable device that when connected to loads the app into Chrome, I bet most of it would work.
Might not work with any of the DRM sites like Netflix and Hulu but for things like local content and unprotected streams I see no reason why it wouldn't.
In fact I bet the trouble some are having with Channels in Plex and others would go away because a PC Chrome instance would be able to play many more Transport types than a CCast can currently.
Asphyx said:
Should the goal really be to emulate a Chromecast or should the effort be geared toward supporting DIAL protocol?
I would think the latter is the better option because you could support whatever the hardware supports without the limitations imposed on us from CCast Hardware.
Maybe I'm wrong but I always looked at DIAL as an extension of UPnP and separate from the CCast itself and the Chromecast SDK as not much more than a kit to add DIAL support to Android (and iOS) not meant to build anything on the CCast side at all.
.......
Click to expand...
Click to collapse
I agree with you. I could actually care less about emulating the specifics of what's in the Chromecast hardware. What I do want is the ability for those unrestricted apps (ie not Netflix) to be able to use their Cast button to find, connect to, and use whatever the emulator is. The new CC SDK doesn't use DIAL to do the initial search any longer. It now uses mDNS. All of the previous apps (YouTube, Pandora, etc.) are still using the old API and DIAL discovery which appears to be backward compatible with the new Chromecast stick software. If you look at the debug logs of the stick, both the v1 and v2 APIs are accounted for. As for Roku, my guess (I haven't started digging in on what they're up to yet) is that they have an app that is using DIAL for discovering the Roku and then just acting as a remote control for all the box functions. Chromecast was a bit more unique since it could basically load up anything from the web as a receiver/playback client since the software is just basically a Chrome browser with some wrappers around it. That's what made it much more dynamic without having to load "channels" in the box within a custom framework like Roku does.
And Bhiga, as for economics on Google providing the software to other hardware makers, I think it it would actually be in their best interest. The Chromecast right now has to be either close to at cost for them or a loss leader. If they can get the Cast API to become a default standard on new consumer devices, that would help them take over that space. To me, that is such a better proposition for them than trying to get the complexities of something like GoogleTV into TVs.
Averix said:
And Bhiga, as for economics on Google providing the software to other hardware makers, I think it it would actually be in their best interest. The Chromecast right now has to be either close to at cost for them or a loss leader. If they can get the Cast API to become a default standard on new consumer devices, that would help them take over that space. To me, that is such a better proposition for them than trying to get the complexities of something like GoogleTV into TVs.
Click to expand...
Click to collapse
mDNS actually makes discovery a lot easier - mDNS = Bonjour = what Apple and TiVo use for discovery already.
I agree with you that adoption of the API and protocols is the goal. At this stage an Android emulator probably would help adoption, but my point was that a desktop emulator doesn't necessarily add to the rate. If someone starts looking to using a desktop because they think they don't need a Google Cast device, they'll likely runs across Plex and Miracast and may decide they don't need Google Cast at all.
bhiga said:
I agree with you that adoption of the API and protocols is the goal.
Click to expand...
Click to collapse
I wish Google agreed with us.
Averix said:
I wish Google agreed with us.
Click to expand...
Click to collapse
I bet anything there are some at Google who do agree with us but when your as BIG a company as Google is it takes forever to get everyone on board and thinking along the same lines enough to manifest it into an end product.
In the end what all if this really tells us is how much DLNA Consortium has failed to standardize Media Distribution by not going far enough and thinking of it from the end user ergonomic experience.
If this discovery and launch capability was more fleshed out in the DLNA specs we might not be talking about DIAL and mDNS right now.
At some point all these protocols (DLNA, UPnP, DIAL) should be merged into one standardized protocol that any platform can use.
Probably years away though...
Asphyx said:
If this discovery and launch capability was more fleshed out in the DLNA specs we might not be talking about DIAL and mDNS right now.
At some point all these protocols (DLNA, UPnP, DIAL) should be merged into one standardized protocol that any platform can use.
Probably years away though...
Click to expand...
Click to collapse
My concern is that unless Google is willing to push this as a standard rather than just apps for one dongle, it will only be a matter of time before the giant (un)friendly fruit company swoops in and AirPlay becomes the defacto standard that all TV makers, set top makers, and anyone else are forced to build in. It's not quite the same as how DLNA and UPnP have become sort of irrelevant, but it could pan out that way for the Google Cast API without more hardware devices having the capability built in. Time and market pressure will tell I guess.
my question is that How does google home communicates with devices? Please reply I'm a newbie and got stuck here. Your help will be highly appreciable and it will mean a lot to me.
Hello Manishthakur,
1) you should specify your Q more. Why do you ask?
2) to communicate with Chromecast in your TV it uses Wi-Fi network (802.11b/g/n/ac (2.4GHz/5Ghz))
3) to stream music to other (BT) speakers it uses Bluetooth 4.1
source
Hi chrnec,
My question was how does google home communicates with compatible devices? What is the process?
Can u give an example of that compatible device? I still cant get where you heading to.
Maybe you want to know if connection is direct (local) or if cloud and internet is used?
Yes my question is to know if connection is direct (local) or if cloud and internet is used?
And if a self made product is there how we can make that device communicate with google home? this is second and last question.
Unfortunately my knowledge is not sufficient for this. Mybe someone else will help us to understand this.
But read this:
At I/O, Google rolled out a developer kit similar to what C by GE uses so more companies can enable setup in the Google Home app. This Local Home kit could also make your smart home faster. Instead of communicating with the cloud of every third-party device, the kit allows your smart speaker to store cached versions of certain commands. They can then process the command locally and communicate with the device directly over Bluetooth and Wi-Fi.
Click to expand...
Click to collapse
Everything You Need To Know About Google Home
Andrew Gebhart - https://www.cnet.com/how-to/everything-you-need-to-know-about-google-home/
Also you should lear smt about IFTT, if your DIY device will have web interface control page you can use IFTT to connect it with your Google Home device.