Does android support USB host?

by » Tue, 28 Apr 2009 11:29:32 GMT

Sponsored Links
 Dear all:
We have a task of making pc cam useable when it plug into a device
which runs android. So we have some questions as below:
1. Does android support USB host?
2. If so, does android include driver for video class device?
3. If so, does android offer SDK for video class device?

Thanks a lot.


Other Threads

1. Horizontal & Vertical Scroll View

I need to be able to have a view which scrolls both horizontally and
vertically (e.g. like a browser view).  I have seen several posts
where people have put a horizontal scroll view inside a vertical
scroll view.  I have tried to do that, but I only get vertical
scrolling.  The following is the code I am using:

public class ScrollTest extends Activity {
    /** Called when the activity is first created. */
    public void onCreate(Bundle savedInstanceState)

        ScrollView sv = new ScrollView(this);
        HorizontalScrollView hsv = new HorizontalScrollView(this);
        ImageView iv = new ImageView(this);

        int id = getResources().getIdentifier(getPackageName() +
":drawable/level1", null, null);

        if (id != 0)

        hsv.addView(iv, new ViewGroup.LayoutParams(1000, 1000));
        sv.addView(hsv, new ViewGroup.LayoutParams(1000, 1000));


Note that if I create just a HorzontalScrollView or just a ScrollView,
they both work independently.  When I combine them, I only get a
vertical scroll.  Does anyone have an Idea about what is wrong here?



2. the problem with android kernel

Android and the Linux kernel community
As the Android kernel code is now gone from the Linux kernel, as of the
2.6.33 kernel release, I'm starting to get a lot of questions about what
happened, and what to do next with regards to Android. So here's my opinion
on the whole matter...

First off, let me say that I love the Android phone platform. [Until last
week][^1], I used my developer G1, that I bought, every day. It worked
wonderfully for me, and as a user, I was more than happy.

I'm also very happy about Android from a technical perspective. It's amazing
that Google has taken the Linux kernel, and nothing else from a
"traditional" Linux system, and created a portable and robust phone
platform. It's so different that you can drop in a "real" Linux system image
on top of the Android system, and they both work just fine with no changes

Android also solves the problem that the phone manufacturers had been having
for many years: a free version of Java, and a unified application layer that
programmers can write to that will work on all phone platforms that
integrate it. Because of this, all of the existing "Linux Phone Consortium"
groups are doomed and will probably close up silently very soon now, if they
haven't already.

What's wrong?

So, what happened with the Android kernel code that caused it to be deleted?
In short, no one cared about the code, so it was removed. As I've stated
before, code in the staging tree needs to be worked on to be merged to the
main kernel tree, or it will be deleted.

But there's a much bigger problem here.

The Android kernel code is more than just the few weird drivers that were in
the drivers/staging/android subdirectory in the kernel. In order to get a
working Android system, you need the new lock type they have created, as
well as hooks in the core system for their security model.

In order to write a driver for hardware to work on Android, you need to
properly integrate into this new lock, as well as sometimes the bizarre
security model. Oh, and then there's the totally-different framebuffer
driver infrastructure as well.

This means that any drivers written for Android hardware platforms, can not
get merged into the main kernel tree because they have dependencies on code
that only lives in Google's kernel tree, causing it to fail to build in the tree.

Because of this, Google has now prevented a large chunk of hardware drivers
and platform code from ever getting merged into the main kernel tree.
Effectively creating a kernel branch that a number of different vendors are
now relying on.

Now branches in the Linux kernel source tree are fine and they happen with
every distro release. But this is much worse. Because Google doesn't have
their code merged into the mainline, these companies creating drivers and
platform code are locked out from ever contributing it back to the kernel
community. The kernel community has for years been telling these companies
to get their code merged, so that they can take advantage of the security
fixes, and handle the rapid API churn automatically. And these companies
have listened, as is shown by the larger number of companies contributing to
the kernel every release.

But now they are stuck. Companies with Android-specific platform and drivers
can not contribute upstream, which causes these companies a much larger
maintenance and development cycle.

What would be needed to get the Android core code merged?

When the Android code was merged into the staging tree, a number of kernel
developers reviewed the code and pointed out places that needed to be
cleaned up, and changed, in order for it to be accepted. A number of these
changes will affect the kernel/userspace boundry, so some changes to the
Android userspace logic would also need to be changed if these kernel
changes are made, preventing anyone except a Google employee from making the
changes necessary.

So, what to do?

I really don't know. Google shows no sign of working to get their code
upstream anymore. Some companies are trying to strip the Android-specific
interfaces from their codebase and push that upstream, but that causes a
much larger engineering effort, and is a pain that just should not be


I do hold out hope that Google does come around and works to fix their
codebase to get it merged upstream to stop the huge blockage that they have
now caused in a large number of embedded Linux hardware companies.

I've privately offered in the past to help this work get done, and am doing
again here publicly. But I need the help of the Google developers to make it
happen, without them, nothing can change.

The good news is that it looks like all of the kernel/userspace api changes
will have no affect at all on any Android code higher up the stack (like
applications), so all of this work can be done with no problem in the
overall system.

As for me, I think I'll look into getting a Nokia N900. It looks much more
open, with the code mostly all upstream, and a much more active developer

[^1]: footnote text goes here

posted Thu, 09 Dec 2010 in [/linux]

-- ~ things left unsaid


3. resultCode in onActivityResult returns 0

4. Kecewa dgn SS atas penjualan journey

5. Android bluetooth api connect to multiple devices at the same time

6. CM 6.1.1 New Market

7. teathering di jurney kok gak jalan