Fixed
Status Update
No update yet.
Comments
il...@gmail.com
Allowing Printer Attachment via USB would make Android a viable platform for
"industrial" mobile apps
"industrial" mobile apps
[Deleted User] <[Deleted User]>
Cups for network printers over wifi would be a good start.
en...@google.com
en...@google.com
yeah, i'd like my lexmark S305 work with android via wireless
en...@google.com
CUPS support in Android would make it more attractive for netbooks and other places
that need more full featured applications. CUPS ability to see other CUPS servers on
the local network would make it excellent for auto-discovery when moving from network
to network.
that need more full featured applications. CUPS ability to see other CUPS servers on
the local network would make it excellent for auto-discovery when moving from network
to network.
[Deleted User] <[Deleted User]>
Cups will add more values in terms of product features
il...@gmail.com
In the last few days about 3 people commented on this issue. I guess, google is
currently more biased towards their cloud printing. I expect them to show no interest
in this issue any more. Btw, if I understand correctly, Android is OSS. Why can't we
add CUPS support without Google's help? Can someone more knowledgeable throw some
light on issues involved in adding cups to Android by an entity other than Google?
currently more biased towards their cloud printing. I expect them to show no interest
in this issue any more. Btw, if I understand correctly, Android is OSS. Why can't we
add CUPS support without Google's help? Can someone more knowledgeable throw some
light on issues involved in adding cups to Android by an entity other than Google?
il...@gmail.com
I would like cups on my hero
il...@gmail.com
Would really like to see this happen. I use my G1 for a lot of note taking and would love to directly print to my print server (WPS54G).
en...@google.com
For your information, we are OESF Lab in Vietnam (www.oesf.biz ) are working to port CUPS to Android.
After porting CUPS, some printing applications (print manager, print job) will be added.
This is a ready hard work. Any help or contributor into this project are welcome!
TQSang (tqsang@oesf.biz)
After porting CUPS, some printing applications (print manager, print job) will be added.
This is a ready hard work. Any help or contributor into this project are welcome!
TQSang (tqsang@oesf.biz)
en...@google.com
I would love CUPS support. Google's cloud printing is great if you have complete control of a private printer (ie on your desktop), but it is ineffective if your school/business has dozens of network printers, and is unwilling/unable to install custom printing software on each device.
The network I operate on is one such network that utilizes hundreds old copiers/printers directly attached to the network; it would be infeasible for them to upgrade all their printers to new ones compliant with not-yet-released cloud software, and frankly not cost-effective, as the vast majority of devices printing there (and everywhere) are not Android phones/ special chrome netbooks. Having simple CUPS/Windows printing support would enable android to coexist peacefully and cost-effectively with network technology: quite a huge step away from Apple's forcing its ecosystem on others.
Furthermore, the iPhone/iPad may (probably will) never support cups or windows printing, so this would give the android another huge leg over the competition. Please add it!
The network I operate on is one such network that utilizes hundreds old copiers/printers directly attached to the network; it would be infeasible for them to upgrade all their printers to new ones compliant with not-yet-released cloud software, and frankly not cost-effective, as the vast majority of devices printing there (and everywhere) are not Android phones/ special chrome netbooks. Having simple CUPS/Windows printing support would enable android to coexist peacefully and cost-effectively with network technology: quite a huge step away from Apple's forcing its ecosystem on others.
Furthermore, the iPhone/iPad may (probably will) never support cups or windows printing, so this would give the android another huge leg over the competition. Please add it!
ok...@gmail.com
I would love to see IPP printing added to an app on the android. Don't limit it to WiFI, as the Android supports VPNs. Since CUPS handles all the printer drivers, there would be no need to add driver support to the Android device itself.
At the very least, print to GhostScript or PDF, so we can have a file to upload to CUPS. (Please)
At the very least, print to GhostScript or PDF, so we can have a file to upload to CUPS. (Please)
sa...@gmail.com
I reiterate support for this for the G2.
ok...@gmail.com
CUPS support would be awesone.
sa...@gmail.com
it is ery cool to add Cpus to android. We are working on it.I hope I can do it
Description
Instead of leaking platform-specific behavior into application code, we could load the transitive dependencies automatically.
lo_dlopen(), found at
- Searches where the shared object in question is. It searches a set of directories passed to it by the Java code. The Java code looks at LD_LIBRARY_PATH and adds the app's lib directory to that.
- Opens the found shared object file and reads the ELF structures in it . Not all, but just enough to find out what shared objects it needs (the DT_NEEDED ones as displayed by arm-linux-androideabi-readelf -d). It calls itself recursively on the needed shared objects.
- Only after that, i.e. after making sure that all needed other shared objects have been loaded, it calls the real dlopen() on the found full pathname to the shared object.
A few gotchas that the code handles:
- You should not call dlopen() unless you are sure it will succeed. The Bionic dynamic linker "helpfully" remembers if a dlopen() call has failed and refuses to even try again dlopening the same library a second time, even if you after the first attempt have loaded the required dependencies that caused the failure the first time. I.e. it is not a good idea to just try dlopen() first and if it fails, parse the dlerror() message...
- The wrapper needs to remember what libraries it already has loaded to avoid infinitely looping when libraries have circular dependencies (which they do have).
Benefit: Improved portability for application or library code (versus having to add Android-specific workarounds for System.loadLibrary()).