Develop Reference

Android as an UVC Camera

I'm stuck at home with a rather bad webcam. I was considering upgrading, but then it struck me: phones these days have really good cameras embedded in them. So why not use it as a webcam?
However, as I was researching this further I was really disappointed with the available apps for this. As far as I was able to find, we have Android apps that work roughly as follows:
Present phone camera as a network attached camera. Then you can use local software to use that feed as a webcam. See e.g., IP Webcam. This may be sufficient, but it's a complicated setup, and network latency makes this far from ideal.
The Android app sends the camera feed to an custom host application that in turn creates a virtual web camera. See e.g., DroidCam. This mostly solves the latency problem, but it is still rather complicated, and requiring us to install a specific third party application is troublesome in regard to user privacy. Especially since the applications are closed source.
So, I took the engineering approach and tried to see if it was even possible to improve the situation. As far as I was able to find, Android supports being used as a custom USB accessory. And looking over the USB video class documentation, it strikes me that it should be possible to create an Android app that presents the phone as a generic UVC webcam, such that we do not have to resort to tricks such as the ones above.
Ideally, I would have liked Android to add another USB device option ("Use USB connection as webcam") in addition to debug mode, file-transfer, etc. This seems quite unlikely to happen in the short term however.
So, my question is this: Does an application that does the above already exist? My searching thus far haven't yielded any results, but I might be missing something as googling for this turned out a bit harder than I expected.
Alternatively, am I wrong in my assumption above, such that there is some fundamental issue why an Android application cannot be made to work in that way?

There does not seem to be any complete app yet as of 2020-10, but the parts are mostly there:
https://github.com/tejado/android-usb-gadget has code to switch the Android device into gadget mode (but no UVC yet)
https://git.ideasonboard.org/uvc-gadget.git feeds v4l2 into the uvc gadget output
Sources:
http://www.davidhunt.ie/raspberry-pi-zero-with-pi-camera-as-usb-webcam/
https://www.raspberrypi.org/forums/viewtopic.php?t=148361
https://www.reddit.com/r/androiddev/comments/iabc2o/can_i_use_my_android_as_wired_camera_ie_as_a/g1nrijl/

It appears Google has started to take notice on this issue and are currently working on a "DeviceAsWebcam" service, which is exactly the solution to this problem, as seen in the Android review below:
https://android-review.googlesource.com/c/platform/system/sepolicy/+/2410788
Naturally though, this is a Android 14 feature, so it will like take a while before this is usable on a lot of devices. Hopefully, someone is able to backport this feature to older versions of Android.

If android / the version of Android that comes on your target phone provides / permits use of the USB gadget driver, then libguvc,
https://developer.ridgerun.com/wiki/index.php?title=USB_Video_Class_Gadget_Library_-_libguvc
can be used to "make an application appear as a USB webcam".
Potentially relevant to get you started would be https://stackoverflow.com/search?q=Android+USB+gadget (other SO references to the use of the USB gadget driver on Android).

Hardware Access

I've always liked cheap smartphones ($ 50) because with little money I can have a powerful system with lots of sensors and things like that. So I wondered if it was possible to use the hardware without using the very limited android APIs, programming it at a low level then, of course with the root. In particular I wanted to see how the LTE module worked and experiment with this having full control, the Android API does not allow it to do much.
UPDATE: I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.

The first layer of software for the phone is the bootloader. It tells the processor what partition to load into memory for executing the kernel. This is the level that is usually blocked by manufacturers because of greedy corporate reasons that are beyond the scope of this site.
The second layer of the phone is the linux kernel. Rooting is the process of gaining root user access to this layer. Root is the main administrator user account that has permission to do anything to the device. Accessing this layer is what most people refer to rooting. A large portion of the kernel is written in C, with other parts in c++. What happens at this level is where all the magic is. For most phone this is where the code for the modem resides. Talking to this can usually be done via at commands of serial. Sensors are also programmed at this level and communicate via drivers. Root access is not normally needed to read sensor data, its just a case of permissions usually.
The next level is the android operating system, the java instance runs on top of that, which in turn executes the android operating system. This is the portion that most users will see and is primarily written in java. In reality you can run any kind of user interface at this level.
A very brief view of android apps.
The android api provides a way for java developers to write "apps" that communicate with the kernel and access different parts of the phone's hardware. These apps can also be written using c++. Only until recently has google integrated c++ into android studio, but the most common and still most effective method of doing so is using the QT framework.

It's a bit problematic.
Hardware manufacturers do that actually.
Take into account that Android is Linux much like other distributions.
The manufacturers develop hardware and then compile a version Android that sits on top of it. Each Android compilation is specifically tailored to the hardware and equipped with drivers that enable the main OS access to the different hardware capabilities.
For example, some tables will tweak the Android OS to not support cellular communication because they decided to cut costs and deliver the tablet without a cellular module.
From here you have 2 options:
To hack a specific hardware and understand how the OS communicates with the hardware.
Find hardware manufacturers that release some/all of their Android OS code. This is a much simpler way as you can both learn and extend the Android OS for that specific device.
An example of the 2nd way is Sony who has AOSP that allows low-level access to some of the Sony devices.
Also, there is always the Android NDK which gives you a more low-level access to Android but you are still constrained by the KIT API so I'm not sure it will help you.

I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.

Market share of Android devices with Bluetooth LE Peripheral feature?

I'm working on an app using bluetooth LE technology. I am trying to build a bi-directional communication between two devices, and first thought Bluetooth LE was the perfect choice at first.
But then the more I learn about it the more disappointed I became, because it looks like not enough devices support the peripheral feature, even though this has been introduced a long time ago.
I know the central role is possible in most cases, but for my app to work, I need to make sure there are enough devices out there that support (and will support) the peripheral role as well.
But I'm really not sure what the situation is because I couldn't find any reputable source which has a list of devices that support the peripheral feature. And due to the fragmented nature of the ecosystem I have no idea if this is something hardware vendors are planning on dropping or if the coverage will increase.
Can anyone share some insights?
Edit: I have already read another answer suggested as a duplicate (Chipsets/Devices supporting Android 5 BLE peripheral mode) as well as almost everything I could find on Stackoverflow about this topic. But I have yet to come across a definitive list of what devices support this feature, and what the future of this feature is. It's extremely frustrating not knowing whether I should even rely on this API or not because while they say it depends on the hardware vendor, NO hardware vendors include this information in their device spec, which is why I asked this question.

A good rule of thumb seems to be that devices which have Bluetooth chips with version 4.1 or above have proper support for the peripheral role.
Otherwise all Bluetooth devices and their features are listed on https://www.bluetooth.org/tpg/listings.cfm. Note that you might have to search for the model number and not brand name, like LG-H790 instead of Nexus 5X. Then press >> DISPLAY ICS DETAILS >>.
But maybe you can use Bluetooth classic? Android - communicating between two devices

JavaCard 3 in real world?

I'm currently working on my diploma work. Part of the work includes development of JavaCard applet for regular SIM cards. First option is to use JavaCard2.X API and use APDU commands to communicate with the applet. This might be very tricky as I need to develop client-app for android (which will be communicate with this applet) and that is so far possible only trough special - not so user friendly - API called Seek-for-android. (if I'm wrong, please correct me)
However, I also came across JavaCard3 Connected Edition, which provides much more options - for example web applets. Using webapps, deployed on SIM card and accessing them through browser in mobile device would be very convenient (of course developing such applet would be much easier as well). Problem is, that I can't find any mentions of Javacard3 being used in real life, or even on real SIM cards. I can't even find any mentions of possible date of release of such cards. Actually, there is almost no information on this topic.
So, my question is - do you know anything useful about this platform? Anything about real-life usage? Which card supports Javacard3? Are there any developers smart-cards, which are "JC3 enabled"? Will there be SIM cards with this platform in the future?
Thanks a lot for answers!!!

At JavaOne 2012 Moscow representatives of the JavaCard Oracle team demonstrated a prototype device with support for Java 3 Connected Edition based on Portable Security Token ES.

It's 2018 when I am writing this and I think this question needs a new answer.
Java Card 3 Connected Edition is dead in the water. It requires a large amount of RAM, which is still expensive even in the latest editions of the chips. SRAM takes large amounts of memory, and high end chips often still contain 8-10KiB of RAM max.
Furthermore, it was generated with the idea that web-developers would easily connect with it. This doesn't seem to have happened and it is questionable if a security device should be programmed by web-devs at all.
The additional overhead of the TLS protocol adds a heavy overhead without apparent benefit. The TLS protocol also requires a weird connection with the browser / end user. The idea that you can enter a PIN or password on a chip generated web page certainly has failed.
The idea of adding hardware support for browsers in general has failed. Before there were Java applets running in the browser, and the browser largely depended on add-ons. This has all gone away and it is very unlikely to return.
So even if RAM (or FRAM, MRAM, XCross or whatever hybrid memory solution will exist) ever comes cheap on a secure smart card processor, it is unlikely that JC 3 Connected will again see the light of day. Meanwhile Java Card Classic is still going strong although it is far from sexy at the moment - the OTN forum on Java Card is as good as dead (although OTN and sexy themselves are so far apart that they might as well exist on different poles, I certainly prefer SO).

There is no card in the field with JavaCard 3 right now. Everything under development.
But I recommend you to have a look to JSR 177. If Android supports it you can communicate with your applet by normal APDU commands.

Is possible to Install Android in other phone? Like the SH004 or other OEM Phones

I'm wondering if is possible to install/use Android with other phones? Will be nice to have it on such a piece of hardware like the new SH004.

Mobile phones are generally very hardware independent of each other and require a serious amount of hacking in order to do any sort of "moding".
I can barely find any information on the SH004, but I think it will have to be out for a few months before you will even start to hear people of moding it, yet alone installing another Operating system.
Your best bet is to find specialised forums such as CellPhoneHacks, (There are better around, but not sure if I should link to).

Android is actually designed to be portable, and to provide source code for most of the generic pieces. However, the possibility of running it on a consumer device intended for a different operating system/framework depends on three things:
1) The hardware must have sufficient capability - likely meaning it was originally designed to have comparable capabilities under whatever OS it shipped with.
2) Sufficient low-level documentation must be published or reverse engineered to adapt a Linux kernel, flash memory driver, user I/O drivers (touchscreen, etc), and anything communication related (wifi, mobile, etc) and optionally any extras (accelerometer, gps, etc)
3) It must be possible, either by design or by finding an exploit, to run arbitrary code on the device - ie, boot an image which has not been signed by an approved party such as the OEM.