I am working flashing a custom ROM on a new device. Through a bit of research, I've found that I am able to completely circumvent the need to port Clockworkmod by simply using UniFlash on my Windows based laptop. From there, I am left with needing to port the ROM I desire, Cyanogenmod 12, to my device.
I've come to learn that I do not need to build from source, rather I can tailor an existing recovery to fit my device. I am unsure if that is true, so that may need to be cleared up. I went ahead and installed ADB and found a porting guide on the Cyanogenmod Wiki. This is where I am running into problems. I do not seem to have ADB permissions for my device.
When attempting to grab my build.prop, I get this return:
user#mypc:~$ adb pull /system/build.prop
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
error: insufficient permissions for device
After realizing my computer may not see the device, I tried to see which were connected:
user#mypc:~$ adb devices
List of devices attached
???????????? no permissions
It seems I do not have any access to the device at all. USB Debugging is connected, it is a rooted device, and it is set show as a USB Storage. I'm sure if I can at least get this fixed, I should be able to find my way through the rest of the guide myself.
Thank you for any help I can receive!
EDIT 01-
So, I decided to do more digging, and I guess I needed to START the server as super user, and not just run commands in super user.
After running this command, I was able to use my others with permission:
user#mypc:~$ sudo adb start-server
Now, I am running into a problem in which my device is offline:
user#mypc:~$ adb pull /system/build.prop
error: device offline
After referring to this (set up device for development (?????? no permissions)) thread, I seem to get a new response:
user#mypc:~$ adb pull /system/build.prop
error: device not found
I feel it's safe to say I should remove 51-android.rules from my ~/rules.d/.
Edit 02:
It seems I have answered my own question with research. I guess I just needed to update to the newest version because Android 4.2+ requires bridge authorization to complete tasks, and my version did not know to do that! I was successfully able to pull my build.prop!
The reason is that when you connect the USB device it shows a popup asking if you want to allow your pc access the device. You have to accept that manually from the device.
Something like this
http://www.gihosoft.com/android-recovery/img/allow-usb-debugging.png
Related
I'd like to change the device ID string which can be seen when I type 'adb devices' at command prompt.
If I type 'adb devices' at command prompot then I can see below msg,
D:\>adb devices
List of devices attached
5A3C000600000001 device
Is there anyone who knows how the device ID(5A3C000600000001) string generated?
And how can I change the device ID string?
If you have root access, you can enter this to a terminal emulator:
> su (to gain superuser access)
> getprop net.hostname (this should display the current network name)
> setprop net.hostname <newhostname>
Disconnect then reconnect from the network to refresh.
I was on a Samsung Galaxy Note on ICS. Worked like a charm...
In android go to Settings > Applications > Development and tap on Device Hostname. You can then change the name and it should show up when attached to adb.
Another solution can be found here: http://forum.xda-developers.com/showthread.php?t=1462320. You will need to get root access and install a terminal client and do some low level hacking to get it fixed.
Another option is to use the Hosts app mentioned in http://www.thriveforums.org/forum/toshiba-thrive-networking/3157-how-do-i-change-device-name.html, though I haven't been able to find the app he is referring to.
Best option I think is just install Cyanogenmod on your devices. It's the most stable custom android rom and has lots of helpful other features that aren't in stock android.
I have several identical development systems (Odroid A) which report the same device code, thereby preventing me from using more than one on the same host PC with adb. Unfortunately there doesn't seem to be a way of changing this from the gingerbread GUI on this platform as previously suggested.
The device serial number (as reported by 'adb devices') appears to be set in the kernel, under arch/arm/plat-s5p/devs.c (look for 'device_serial'). This may be different for your device, I'd suggest a grep through the kernel sources for the device ID that is reported by adb devices. Change the string, rebuild the kernel and flash it on...
Looks to be different on ICS by the way...
You can set persist.usb.serialno property. I checked it on Galaxy S4/S4 mini and it's persistent, but you need root access:
adb shell
su
setprop persist.usb.serialno Phone1_GalaxyS4
exit
adb reboot
Than in adb devices you'll have
C:\Users\amdc2452>adb devices
List of devices attached
Phone1_GalaxyS4 device
I was also facing the same issue.where two device connected were showing same id in adb devices.
I found this link which solved my issue. Just downloaded the adb from the following link and replaced my original adb.
adb got two same serial numbers when connected to two smart phones
Hello StackOverflowers,
I am eager to try out some Android programs on my tablet in the early phase. However, I do not have root access to the Linux machine I am using (OpenSUSE 12.1). Due to this, I am having trouble to let the system find my device.
This tutorial http://developer.android.com/tools/device.html, as well as almost every post I can find online, do not mention ways to walk around the 51-android.rules setting without root. Some post even mention that, to find the device, the adb command should be run with root.
Does this mean I have no hope of on-device debugging? Thanks in advance!
I dont think you need root access for adb. Though for the device to be detected, AFAIK you need to add device details in rules.d .
If you have device and the computer on the same network, you could use adb over wifi. But to put the device in tcp mode , you need root access on phone or another computer where device can be detected.
Your device doesn't have to be rooted. After you add your device in 51-android.rules, make sure you restart adb server by using these commands:
adb kill-server
adb start-server
And one more thing, make sure you turn On Debugging Mode
So here's the thing. I use MyPhoneExplorer in USB mode which uses ADB to communicate with the phone. Whenever my phone is connected (using MyPhoneExplorer) and try to test an app in eclipse on my EMULATOR, ADB crashes, rendering both MPE and the emulator useless.
My question is: Is there any way to prevent adb from accessing one phone from multiple sources? (In this case its trying to access the phone for both Eclipse and MPE).
Weird/Confusing question I know, but would really appreciate some help.
I haven't tested this, but how about directing ABD at a given device with this:
adb -s <serialNumber> <command>
http://developer.android.com/guide/developing/tools/adb.html#directingcommands
Use adb devices to find out the serial number of your emulator.
But from what you describe it might be that ADB's device detection that's breaking things.
I am developing for android on a linux machine and I have already created a udev rule for android and it works. After a while if I unplug the device and plug it back in again, adb doesn't recognize the device if I run lusb or dmesg to get information about the device. I tried reload the udev rules and it does not work, I even tried to kill the adb process but it still does not work.
Can someone help?
Anyway, thank you.
This appears to be a real problem on linux, at some point in time a device will no longer be seen by the ADB. What I should really say is almost never be seen by the ADB. In my case I have a Samsung Galaxy Tab 10.1 that was given to attendees of Google I/O 2011. My Ubuntu 10.10 development system was working just fine with this device. Sometime near September 19th the ADB stopped seeing the device! In fact there have been breif moments in time when the device was detected by the ADB. What needs to be made clear about the problem that I and I believe pharaoh are having is not the permissions issue where executing
$adb devices
returns ?????????? for a device. The device simply does not show up in the list. One more important fact is that at no point in time has this device not been detected on my Windows based development machines.
It appears to me that the mechanism that the ADB uses to determine if a device on the USB is in fact a adb_device is fragile and some change in either our devices or our development systems has broken this detection.
Due to some reason sometimes adb gets disconnected, so in that case you have to restart the adb.
Go to DDMS->Devices and you will see Reset adb option in View Menu besides Screen Capture option.
I usually have this problem due to I have installed the adb plugin on Chrome. If I close Chrome and re-connect the device, it appears listed with adb. Hope this helps.
I just had this problem as well with my OnePlus 2.
It was working the previous day. I had then set up port-forwarding using the 'device inspector' dialog in Chrome DevTools. It's supposed to be kept open for it to work, so I kept it open in a tab permanently.
The next day when I connected my device via USB, adb devices didn't list anything. I closed the device inspector dialog in my devtools and suddenly adb recognized my device again. I re-enabled port forwarding after this, but my device is stll being detected.
tl;dr: Close your port-forwarding dialog in Chrome DevTools if it had been kept open even after you removed your device.
I've had this happen before. I disable, and then re-enable debugging on the phone (Setting -> Applications -> Development -> USB debugging, uncheck, then re-check) to get it recognized by adb again.
Try adb kill-server to stop the adb and use another command 'adb devices' to restart it. It should work and it should detect your device again. ( For those who can edit my post: any other commands will start the server not just adb start-server, so don't edit without to leave a comment at least)
May be stupid, but I have been had similar problem right now and after an hour I noticed that the problem was that my USB hub, in which such devices are connected, were not actually connected to the PC.
In fact, the USB wire WAS connected, but they may not being doing good contact for some reason, so it failed randomly from time to time.
Same problem here, using mac os. However connected devices are recognized by Android File Transfer application. It all started with S3 phone (rooted), I thought something wrong with the phone, because Nexus 7 (stock) worked as intended. After 3 days of connecting/reconnecting it stopped being recognized by adb too. Tried to perform a hard reset - didn't help.
adb list - empty list
android file transfer - works perfectly
I'll run out of devices soon
Same problem observed on ubuntu, I tried the following and it worked:
Reference: link
Use the command udevadm from the above reference for ex:
"sudo udevadm test --action="SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="[vendor_id]", ENV{ID_MODEL_ID}=="[model_id]" MODE="0666", SYMLINK+="[Device_Name]"" $(udevadm info -q path -n /dev/bus/usb/001/[DevNum])"
This seems to fix some link files and that solved the problem of adb not detecting device after a while.
I was using earlier adb to debug Android applications over wifi, usb - it was great.
Right now I am wondering if it is possible to connect phone with adb via bluetooth.
I did a quick research but didn't find anything - have you tried it already ?
It is not supported by the current adb software, however you could probably make it possible if you have a rooted device (or possibly even if not - see below) either by modifying adb or by using bluetooth to tunnel a channel it does support, such as tcp.
You would need to obtain the source for the adb program - the same source is used to build both the PC and the device versions. First step is to just build it with unmodified functionality, which may take a fair amount of build system modification unless you do so as a part of a complete android source build (the way it was intended to be done)
Then you would modify it to add a bluetooth channel as an option and install it on the device (why you need root) and in your path on the PC. You'd think you could run it from an alternate location on the PC, and you likely can as long as you use it from the command line, but if your fire up DDMS it may kill off the running adb server and launch a new one using the default in the path, so ultimately you'll have to put your modified version there.
IF you can already get your device to accept adb connections over tcp (possible with root, perhaps possible in some cases without) there is another option, which is to not modify ADB (or at least not modify the device side) and instead come up with something running on the device which accepts bluetooth connections and forwards the traffic via local loopback to the tcp port on which the stock adb is operating. This would save the trouble of having to rebuild adb.
If you have some kind of tethering or similar network-over-bluetooth solution, you might even be able to leverage that to carry adb-over-tcp-over-bluetooth without writing any code.
Finally note that it is not 100% essential that the adb daemon run as a more privileged userid or be installed in place of the official one - you can run an adb daemon as an ordinary application and do many of the expected things with it. However, whichever adb daemon is running first will grab the unix domain java debug socket, and so only that adb daemon will be able to provide the full java debug services. More primitive things like logcat, shell, running process list, push/pull, etc will at least partially work without this, provided that your adb daemon doesn't quit (modification may be required) when it is unable to claim the debug socket. If you can kill the official adb daemon and exploit a race condition, you may be able to get an unofficial one started before it restarts - you would probably need to have a script or program to do this and run it with setsid from the official adb shell, meaning you'd need to connect via USB first. At that point, you'd also be able to start your unofficial adb daemon running as the same userid as the official one.
You may want to spend some time estimating or testing if the performance (speed) will be satisfactory before investing in a lot of time setting this up for real.
I know this is a bit old but I seem to have found a post that does this. All credit goes to the author of fomori.org for finding this and making the information available. Today it helped me, maybe tomorrow I'll help you by making it easier to find.
Source