Hi
I am providing an application to client, now the client requires is that Wifi, bluetooth and USB port of android devices should be disabled permanently, so that the users cannot do any communication from the device. So how do these can be disabled in an android device permanently.
Related
I'm working to develop an application to use a rooted Nook STR as a handheld data input platform, which then sends the data to another Android device (tablet or phone; TBD) acting as a hub. From what I've been able to determine, the options for communications between the devices are:
Bluetooth
-Possibly available using a dongle, USB OTG cable, and enabling USB host mode as described here. This doesn't seem practical within the time/budget/scale of our application.
Wi-Fi
-Wi-Fi Direct would be ideal, but requires either Android 4.x or a patch/hack to enable it, which I haven't seen anyone working on (correct me if I'm wrong about this)
-Separate Wi-Fi hub to manage communications between the devices
Is there an alternative, implementable within reasonable time and cost, to facilitate device-to-device communications wirelessly and without additional separate hardware? My research hasn't turned up any solutions that aren't extremely awkward, but I'm relatively new to this, so hopefully someone has a better idea or knows of an obvious possibility that I'm missing.
Dear Friends,
I am working with an android app which uses Hid keyboard. I was not able to find any support in API 17, i tried to use USB Host and USB accessory but my nexus tab doesnt recognize it in my app. When i connect usb device the android app detects it using USB Host. Although the device detects it as a keyboadrd. My problem is i have to take input from the Hid keyboard and it will be used for authentication purpose in my app. What seems to be the problem. Please help me with this.
Thanks.
I have: 1) An embedded device with a Bluetooth connector that I use with BlueZ, and 2) I have an Android phone that I am writing an application on.
Goal: I want to make sure that when these two devices are near each other, they quickly detect each other and establish communication. Unfortunately, I'm running in to complications of what is feasible on Android and power efficient.
Initial Design: Originally, I've been thinking and implementing the following
Embedded Device: Constantly in discoverable mode, creates a service with an RFCOMM server running to accept multiple connections.
Android Phone: Listen for Broadcast intents that would tell me when the embedded device (discoverable) is nearby, and then create an RFCOMM client socket to it.
The difficulty I am having with this design is that I do not get intents when I would expect them. Even if I turn the embedded device on and cycle the Android phone's Bluetooth adapter to off/on ... none of these Broadcast intents are received:
Code:
BluetoothDevice.ACTION_FOUND
BluetoothDevice.ACTION_ACL_CONNECTED
BluetoothDevice.ACTION_BOND_STATE_CHANGED
The only thing that seems to work is to periodically either have the phone try to connect to the Bluetooth device's RFCOMM socket, or to periodically trigger Bluetooth scans (both power inefficient). This will trigger ACTION_FOUND and ACTION_ACL_CONNECTED. If i shutdown the embedded device, I will receive ACTION_ACL_DISCONNECTED. The issue, again, is that none of these are received if I do not explicitly have the phone try to initiate a socket connection. This is bad for power efficiency on the phone.
-----
Do I have this logic backwards? Should the embedded device keep track of Bluetooth MAC addresses that it has paired with and be the RFCOMM client, whereas the Android application creates a service and is the RFCOMM server just hanging around and waiting for a connection? This seems logically backwards, though... I wouldn't think the Android phone would create a service or be the server to make this happen.
If I go in to my car, it almost immediately manages to establish a connection with my phone. So, I know this is possible!
The concrete questions I have are two-fold: 1) Is there something I am doing wrong with my "initial design" to make it more effective, and 2) Is the 2nd logic I propose what things like cars use to establish quick communication and poll frequently? (since the battery power of the car is not a concern...). I am thinking of putting a server on the Android app that the Embedded device just tries to keep connecting to, and when successful, it's used as a notification to the Android app to try and connect to the embedded device's server. That would keep most current structure in place.
Hi,
I was constantly annoyed by the poor wifi signal when I had my devices connected to the computer, so I wondered why I could not use my computer's Internet connection on the Android devices when they were already connected via a USB cable. Extensive Google and XDA searches only showed solutions that would not work with recent Android versions, did not work with all Operating Systems, only worked sporadically or required the Android device to be rooted. I finally decided I had to develop my own solution.
I started to investigate, learned TCP, spent hours fixing nasty networking bugs, and finally, here is ReverseTethering NoRoot. The app runs on all Android versions starting from ICS. It does require a server program on the host computer, though that is available for Windows, Mac and Linux, and it does not have to be installed, it runs as a portable app without touching your registry or system files.
As the app does not require root permissions, there is no danger that it might mess up your system. The worst thing that might happen is that you have to reboot.
Because it implements its own network layer and does not rely on any system command line tools on the host, it works on the widest possible range of computers.
There is one drawback though: As with other reverse tethering solutions, some apps only check for a Wifi or 3G connection, so they might not recognize ReverseTethering's connection. Unfortunately, this applies to recent versions of some Google apps. E.g. while downloading apps from Google Play via the reverse tethered connection works on Android 4.1 on a Galaxy Note 8, it does not on Android 4.3 or Android 6.0.
Although untested, the workarounds for this issue that work for other reverse tethering solutions should also work for this solution.
I have opened a dedicated thread for the app in the Applications forum over here: http://forum.xda-developers.com/android/apps-games/app-reversetethering-noroot-t3316716
TL;DR: A reverse tethering app that works on Android 4.0+, all host OS and does not require root
Let me know if you have any questions, feedback or suggestions! :laugh::fingers-crossed:
Hi! I originally posted this question in the Android Auto section- however its not really related to Android Auto since its more about networking - or internet sharing capability of android.
If I connect a "car-stick" such as https://www.onlineshop-skoda.de/index.php/carstick.html, the car (a Skoda Kodiaq) should be able to provide a wifi-hotspot.
I could simply enable internet sharing using my Samsung S9, but I guess the signal would be better if the cars built in wifi-hotspot capability was used.
The phone is connected via USB to the car.
Could the phone be configured in some way which would enable it to present the type of network interfaces similar to what the earlier mentioned car-stick presents?
//Erik
Your question is 100% not clear.
A recent broadband dongle is just a cellular phone w/o keyboard and display that shares the connection via USB networking.
Practically the same thing that an android Phone does when you enable the USB tethering.
The only relevant difference is that the former does that by default, while the latter requires a manual input.
BTW you can automate the usb tethering using tasker or some dedicated apps available on the store