I've rooted my android device because I'm trying to make it detect ad-hoc wifi.
I installed BusyBox pro and then I typed in the adb shell:
su -c "/system/bin/wpa_cli -p /data/misc/wifi/"
in order to start the wpa_cli shell it returned
/system/bin/sh: wpa_cli: not found
and I'm really confused. I wonder on what I missed. Can anybody help?
The wpa_cli shell is only needed to operate and monitor wpa_supplicant. If the WPA system is already configured, wpa_cli is not needed at runtime. Many manufacturers remove the wpa_cli executable from their systems to prevent users from changing how wifi is working. The Google Nexus devices include wpa_cli in their eng and userdebug builds, and may even include it in the user builds.
I would find the exact OS version on your device, check out an AOSP sandbox branched to that same version, and then build wpa_cli. This can be done by using lunch to select your device, and then do an "mma" in external/wpa_supplicant_8. You can then push wpa_cli from $OUT/system/bin onto your device at /system/bin, and it should run.
You should use wpa_supplicant instead of wpa_cli.
Make sure you have wpa_supplicant first by ls /system/bin | grep wpa
Related
I want to set the SELinux (Security Enhanced Linux) mode to Permissive or (0) on android 4.4.4 (and above if possible). I use the following command: setenforce 0, setenforce permissive and setenforce Permissive under root (my device is rooted). But the output of getenforce is always Enforcing. Now I am exhausted with this problem.
Can any one give me a solution? Thanks in advance.
Depending on how your device was rooted and what Android ROM your running will determine how you can disable it. The first thing to try is:
adb shell su 0 setenforce 0
This is NOT the same as:
adb shell setenforce 0
The execute on su causes a domain transition from shell (which cannot setenforce) into the su domain (which can call setenforce). For instance, run:
$ adb shell id -Z
context=u:r:shell:s0
compared to:
$ adb shell su 0 id -Z
context=u:r:su:s0
This may fail for three reasons:
You do not have the su executable
The su executable has the wrong label
The su domain rules were not compiled into the bootimage
To correct issue 2, you can (assuming adb is root):
adb remount
adb shell chcon /system/xbin/su u:object_r:su_exec:s0
This might fail, which will likely indicate issue 3. To fix issue 3, you need to recompile a boot.img that contains the su policy files. If you're compiling AOSP, just lunch a userdebug or eng variant of your device.
Another approach, would be to remove the functionality from init.c, and like issue 3, requires a recompile of the boot.img. Go into system/core/init/init.c (or .cpp) and remove all calls to security_setenforce().
Additionally, XDA has an application that may help automate this process and make it easier, however, I cannot speak to the quality of the application:
http://www.xda-developers.com/easily-change-your-android-selinux-mode/
Apparently Google has removed the CONFIG_SECURITY_SELINUX_DEVELOP kernel flag from many of their Stock kernels. Thus the standard trick mentioned by William (below) probably doesn't work. An example of these devices is the Samsung Note 4 (SM-N910F) running AOS 4.4.4.
The link above states:
CONFIG_SECURITY_SELINUX_DEVELOP aka global permissive mode, is useful for
when you are first developing device-specific policy for a board (add
'androidboot.selinux=permissive' to BOARD_KERNEL_CMDLINE). It also
permits transient setenforce 0 in -userdebug or -eng builds, which can
be helpful for developers.
If the bootloader is locked, then you can't modify the kernel cmdline
"Also, the code in the init program for processing the
androidboot.selinux= option is only compiled in -userdebug and -eng builds, so even aside from bootloader locking, you cannot use
androidboot.selinux=permissive on a -user build."
The way to check what build type you have is:
$ getprop ro.build.type
user
MUST BE ROOTED! Not sure if this works on KitKat (it should) but I use this on my Nexus 6. Run following in terminal or ADB Shell:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "echo 0 > /sys/fs/selinux/enforce" >> /system/su.d/permissive.sh
chmod 755 /system/su.d/permissive.sh
And check it after reboot by this:
su
/system/bin/getenforce
I rooted my unlocked Galaxy S3 (SGH-T999)
Now, I'm trying to run adb root from Windows Command Prompt, however, I'm getting adbd cannot run as root in production builds error. So, the very first thing I checked was whether my phone was really rooted?
So I tried the following:
Open Command prompt
$adb devices // lists my device
$adb shell //goes to shell
$su // opens a 'SuperSu' prompt on my phone and I 'Grant' permission
# // Before following the rooting instructions, I was getting 'no su command found' in the previous step. So, I believe my phone is ROOTED. **Correct me if I'm wrong.**
However, when I do adb root, I get adbd cannot run as root in production builds error.
So, I thought, I might have to do some additional stuff beyond what I did above. I tried all the solutions in the following SO questions:
Launch a script as root through ADB
adb remount permission denied, but able to access super user in shell -- android
Unable to run 'adb root' on a rooted Android phone
None of the above worked for me. All they do is give the ROOT access INSIDE of SHELL. I want adb root to work so that I can execute various adb commands WITHOUT going into shell.
By design adb root command works in development builds only (i.e. eng and userdebug which have ro.debuggable=1 by default). So to enable the adb root command on your otherwise rooted device just add the ro.debuggable=1 line to one of the following files:
/system/build.prop
/system/default.prop
/data/local.prop
If you want adb shell to start as root by default - then add ro.secure=0 as well.
Alternatively you could use modified adbd binary (which does not check for ro.debuggable)
From https://android.googlesource.com/platform/system/core/+/master/adb/daemon/main.cpp
#if defined(ALLOW_ADBD_ROOT)
// The properties that affect `adb root` and `adb unroot` are ro.secure and
// ro.debuggable. In this context the names don't make the expected behavior
// particularly obvious.
//
// ro.debuggable:
// Allowed to become root, but not necessarily the default. Set to 1 on
// eng and userdebug builds.
//
// ro.secure:
// Drop privileges by default. Set to 1 on userdebug and user builds.
In some developer-friendly ROMs you could just enable Root Access in Settings > Developer option > Root access. After that adb root becomes available. Unfortunately it does not work for most stock ROMs on the market.
I ran into this issue when trying to root the emulator, I found out it was because I was running the Nexus 5x emulator which had Google Play on it. Created a different emulator that didn't have google play and adb root will root the device for you. Hope this helps someone.
I use for enter su mode in abd shell
adb shell "su"
I have a rooted Samsung Galaxy Trend Plus (GT-S7580).
Running 'adb root' gives me the same 'adbd cannot run as root in production builds' error.
For devices that have Developer Options -> Root access, choose "ADB only" to provide adb root access to the device (as suggested by NgaNguyenDuy).
Then try to run the command as per the solution at Launch a script as root through ADB.
In my case, I just wanted to run the 'netcfg rndis0 dhcp' command, and I did it this way:
adb shell "su -c netcfg rndis0 dhcp"
Please check whether you are making any mistakes while running it this way.
If it still does not work, check whether you rooted the device correctly.
If still no luck, try installing a custom ROM such as Cyanogen Mod in order for 'adb root' to work.
You need to replace the adbd binary in the boot.img/sbin/ folder to one that is su capable. You will also have to make some default.prop edits too.
Samsung seems to make this more difficult than other vendors. I have some adbd binaries you can try but it will require the knowledge of de-compiling and re-compiling the boot.img with the new binary. Also, if you have a locked bootloader... this is not gonna happen.
Also Chainfire has an app that will grant adbd root permission in the play store: https://play.google.com/store/apps/details?id=eu.chainfire.adbd&hl=en
Lastly, if you are trying to write a windows script with SU permissions you can do this buy using the following command style... However, you will at least need to grant (on the phone) SU permissions the frist time its ran...
adb shell "su -c ls" <-list working directory with su rights.
adb shell "su -c echo anytext > /data/test.file"
These are just some examples. If you state specifically what you are trying to accomplish I may be able to give more specific advice
-scosler
adbd has a compilation flag/option to enable root access: ALLOW_ADBD_ROOT=1.
Up to Android 9: If adbd on your device is compiled without that flag, it will always drop privileges when starting up and thus "adb root" will not help at all.
I had to patch the calls to setuid(), setgid(), setgroups() and the capability drops out of the binary myself to get a permanently rooted adbd on my ebook reader.
With Android 10 this changed; when the phone/tablet is unlocked (ro.boot.verifiedbootstate == "orange"), then adb root mode is possible in any case.
If you really need to have ADB running as root, the quickest and easiest way is to install Android Custom ROMs and the most popular is CyanogenMod for it has the Root Access options in developer options menu where you can choose to give root access to apps and ADB. I used CM before but since it wasn't developed anymore, I tried looking for some solutions out there. Although CyanogenMod is still a good alternative because it does not have bloatware.
One alternative I found out from a friend is using adbd insecure app which you could try from here: https://forum.xda-developers.com/showthread.php?t=1687590. In my case, it works perferct with an Android custom kernel, but not with the Android stock ROM (vanilla android only). You may try other alternatives too like modifying boot.img of the Android ROM.
in my case, ( device is rooted )
linux$ adb shell # in linux shell
mobile$ su root #=> notice the $ will become #
mobile# whoami #=> root
if you installed "adb root" module in Magisk, you still have to manually switch to root by su root, otherwise, it just LOOKS LIKE you are root, but actually you are NOT root.
I have a Samsung Galaxy Tab S2 running Android 7.0.
Here's how I rooted it today:
Root the device using Odin
Read Alex P.'s answer in this thread regarding editing system\build.prop file.
download onto your tablet: v1.3.9 System Tools Android: All-In-One toolbox
run the app; under "System Utilities" confirm your Odin root worked using "Root Check"
in the same app goto "Root Manager" and use the "Build.prop editor" to effect the changes in the system\build.prop (as specified by Alex P.).
Final Confirmation:
C:\Android\sdk\platform-tools>adb shell
gts28vewifi:/ $ whoami
shell
gts28vewifi:/ $ su
gts28vewifi:/ # su root
gts28vewifi:/ # whoami
root
Upvote Alex P.'s answer.
Further info
and here
and here too
Root Access in Windows Command: adb shell su
Root Access in MacOS Command: ./adb shell su
How to auto boot a rooted android phone when it is dead and connected to the charger?
I know many people think its not possible as when the device is OFF and ADB isn't running. But it turns out that it is possible to write an application for rooted device.
There is an application for the same #playstore to do just that.
I just want to make similar app. Any ideas or pointers?
I am researching for the same problem (Android 2.3, htc wildfire s), this are my investigation results:
It works! Unfortunaly it works, if you connect the phone without accumulator and after that insert the accu- now its autoboots. Connecting the phone with inserted accu or insert the accu in the unconnected phone does not work.
Not the result I hoped for but maybe a hint for a pointer.
And I found a script solution: https://android.stackexchange.com/questions/39899/auto-boot-when-charger-connected-for-htc-magic
echo "echo skipping chargemon" > chargemon.script
adb pull /system/bin/chargemon chargemon.backup
adb push chargemon.script /sqlite_stmt_journals
adb shell
$ cd /sqlite_stmt_journals
$ su
# mount -o remount,rw /dev/block/mtdblock0 /system
# cat chargemon.script > /system/bin/chargemon
# chmod 755 /system/bin/chargemon
# reboot -p
You should google a bit
i guess your looking for something
similar to this?
https://android.stackexchange.com/q/39899
Mostly you will have to check the boot-sequence of multiple devices and code accordingly as each device will have different setups
for example the app you posted in your question works only for samsung devices
I'm running Ubuntu 10.10 64 bit. I have ia32-libs installed along with Android Debug Bridge version 1.0.26.
My problem(s):
adb devices >>> ???????????? no permissions
sudo adb devices >>>> sudo: adb: command not found
adb shell >>> error: insufficient permissions for device
I guess these are all related. Here's the relevant info.
$ echo $PATH
/home/me/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/android-sdk-linux_x86/tools:/opt/android-sdk-linux_x86/platform-tools
$ which adb
/opt/android-sdk-linux_x86/platform-tools/adb
$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
???????????? no permissions
$ sudo adb devices
sudo: adb: command not found
$ adb shell
error: insufficient permissions for device
I get the same results with a rooted Moto Droid running CM6.1 and a rooted G-Tab running a CM7-based ROM.
I have reviewed the following related posts:
http://forum.xda-developers.com/archive/index.php/t-522827.html
http://ubuntuforums.org/archive/index.php/t-1164359.html
adb command not found in linux environment
I tried most (not all) of the suggestions and I have not been able to resolve my issue. The things I didn't try seemed inappropriate. I would appreciate a few more tips and I'll keep troubleshooting.
One thing I didn't try was editing /etc/udev/rules.d/70-android.rules. Is that likely to be the issue? I can't see how that would cause "sudo: adb: command not found". Maybe my problems are not all related. Anyway, at this point I think I need some input from other people because I don't believe I have a path problem or the other common problems discussed in those other posts.
EDIT: SOLVED thanks to EboMike and RivieraKid. This was actually two different problems:
Item #2 above (sudo: adb: command not found) was solved by making a symlink as follows:
$ sudo ln -s /opt/android-sdk-linux_x86/platform-tools/adb /usr/local/sbin/adb
That allowed me to then do as EboMike suggested and use this solution. Doing that was required for my Moto Droid. (Running adb as sudo was not required for my Viewsonic G-Tablet, however.)
My other two items were resolved by implementing the udev rule as RivieraKid suggested (from this link).
One thing I didn't try was editing
/etc/udev/rules.d/70-android.rules. Is
that likely to be the issue?
Any particular reason why you didn't do that? To answer the question - YES! The udev rules are what informs Ubuntu what your device is and allows user-space tools to therefore access it.
You will not be able to use adb without correctly following the instructions.
With that in mind however, you don't say what version of Ubuntu you're using but I had issues with 10.10 - let me know if you need me to post the contents of my rules file.
Don't worry about running adb via sudo, you don't need it. The MODE="0666" from the udev rule allows you to access the device as any user.
EDIT:
Don't forget to reload the rules:
sudo udevadm control --reload-rules
EDIT #2:
As #Jesse Glick correctly points out, if adb is already running in daemon mode, you'll also need to restart it for this to work:
sudo adb kill-server
I've used sudo here, since that will guarantee that adb will be killed , and it's the officially supported method to stop the server. It will be automatically restarted the next time adb is used, but this time with the correct environment.
You need to restart the adb server as root. See here.
On my Gentoo/Funtoo linux system I am having similar problems:
I gotting always not the correct device description and insufficient permissions:
# sudo ./adb devices
List of devices attached
???????????? no permissions
# ./adb usb
error: insufficient permissions for device
For me helps the howto from Google.
In my case I needed to add the udev rule:
# cat /etc/udev/rules.d/51-android.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev"
and setting up the filesystem rights
# chmod a+r /etc/udev/rules.d/51-android.rules
After replugging my smartphone the access to the phone was successful, it also appears now in Eclipse' Android Device Chooser:
# sudo ./adb devices
List of devices attached
3XXXXXXXXXXXXXC device
# sudo ./adb usb
restarting in USB mode
You also have to check the membership of your user to the plugdev-group.
Every answer I've read indicates the SUBSYSTEM=="usb". However, my (perhaps ancient) udev needed this to be changed to DRIVER=="usb". At last I can run the adb server as a non-root user... yay.
It can be instructive to look at the output of udevmonitor --env, followed by the output of
udevinfo -a -p <DEVICE_PATH_AS_REPORTED_BY-udevmonitor>
Please note that IDEs like IntelliJ IDEA tend to start their own adb-server.
Even manually killing the server and running an new instance with sudo won't help here until you make your IDE kill the server itself.
restarting the adb server as root worked for me. see:
derek#zoe:~/Downloads$ adb sideload angler-ota-mtc20f-5a1e93e9.zip
loading: 'angler-ota-mtc20f-5a1e93e9.zip'
error: insufficient permissions for device
derek#zoe:~/Downloads$ adb devices
List of devices attached
XXXXXXXXXXXXXXXX no permissions
derek#zoe:~/Downloads$ adb kill-server
derek#zoe:~/Downloads$ sudo adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
derek#zoe:~/Downloads$ adb devices
List of devices attached
XXXXXXXXXXXXXXXX sideload
I fixed this issue on my debian GNU/Linux system by overiding system rules that way :
mv /etc/udev/rules.d/51-android.rules /etc/udev/rules.d/99-android.rules
I used contents from files linked at :
http://rootzwiki.com/topic/258-udev-rules-for-any-device-no-more-starting-adb-with-sudo/
HTC One m7 running fresh Cyanogenmod 11.
Phone is connected USB and tethering my data connection.
Then I get this surprise:
cinder#ultrabook:~/temp/htc_m7/2015-11-11$ adb shell
error: insufficient permissions for device
cinder#ultrabook:~/temp/htc_m7/2015-11-11$ adb devices
List of devices attached
???????????? no permissions
SOLUTION: Turn tethering OFF on phone.
cinder#ultrabook:~/temp/htc_m7/2015-11-11$ adb devices
List of devices attached
HT36AW908858 device
I just got the same situation, Factory data reset worked well for me.
We are able to run instrumentation tests of Android from the command line on Windows by launching:
adb shell
am instrument -w <package.test>/android.test.InstrumentationTestRunner
This gives us good results.
Using the same architecture, we are unable to run the same in Kubuntu.
We have the same setup in Kubuntu.
Can someone let us know, if there are packages with same name.. Then what package will the adb shell point?
How will the emulator connect with adb shell from cmd line?
DO we need to do any changes to do so in Kubuntu ?
You need to explain what errors you are seeing.
If you have the same setup under Kubuntu, i.e. the Android SDK is installed, with tools like adb accessible in your path, then everything should work fine.
In response to your individual points (and these answers are the same on Windows, Mac or Linux):
It is not possible to have more than one Android package installed on a device or emulator with the same package name.
You can connect to the emulator — the same as for any device — by calling adb shell, e.g.:
adb -d shell if you have a single USB-attached device
adb -e shell if you have a single emulator running
adb -s emulator-5554 shell to specify a particular emulator (or device serial number)
You don't need to change anything between operating systems. The difference would be with setting up a device, as you need to modify udev rules on Linux, and install the USB driver on Windows