I am setting up a CI server which creates Android AVDs on the fly to run automated UI tests. This works great, but since the CI gets brand new emulators with brand new images each time a job is run, I get all of the Android welcome and first run and do you agree prompts. These break my tests.
Is there anyway to have the emulator auto-accept or dismiss all of these prompts?
Here are some examples:
After much digging and experimentation, I've figured out a way to work around both of the prompts mentioned above. There isn't a catch-all solution, but here it goes, piece by piece.
Chrome
Before starting up Chrome for the first time, run this command with adb:
./adb shell 'echo "chrome --disable-fre --no-default-browser-check --no-first-run" > /data/local/tmp/chrome-command-line'
Basically, this writes out a file to a known location which Chrome will check on boot. All of the flags specified in the command are obeyed, and those inheriently disable all of the first run prompts. This link was very helpful.
Keyboard (Gboard)
The Android shell has a tool called ime to manage the input methods available on the device. By default, on newer devices in English, the input method is LatinIME. This is the Latin implementation of Gboard, which provided the legal prompt shown above.
The easiest solution is to select another keyboard which doesn't have this prompt. I used the old SoftKeyboard:
./adb shell 'ime set com.example.android.softkeyboard/.SoftKeyboard'
You may obtain a list of available keyboards, like so:
./adb shell 'ime list -a -s'
Final Result
Related
AVD Manager installs pure android. Most of the components do nothing, except that they flood a huge amount of unnecessary information into the logs.The champion among them is com.google.android.googlequicksearchbox. It writes a lot of information to the Logcat and jobscheduler (adb shell dumpsys jobscheduler). Can i somehow remove this component, which is essentially useless and only floods?
For grins I tried:
adb shell
su
pm uninstall package com.google.android.googlequicksearchbox
The system rebooted itself and the package was there again. So no, I don't think it's possible to remove it.
What you can do in Android Studio is, in the Logcat pane, choose Show only selected application (usually on the far right of the header). Then choose your app in the box to the right of the machine selector. That will show only your app in the logcat.
I want to use vi when running adb shell. Starting "vi" is easy. However, I found that the ESC key doesn't seem to get through to it, so I can't exit insert mode.
More broadly, it doesn't appear that I'm able to send an ESC character to the adb shell at all. I've scanned the web pretty thoroughly and haven't been able to find anyone with a similar problem (much less an answer).
I'm running VRUFNK1 on a Samsung S4. On the PC end I'm running the "adb shell" command from Cygwin under Windows.
Ideas???
UPDATE: Here's are some possible clues.
The adb shell doesn't seem to be the problem. I can capture ESC in a file running
od -cb > file, so ESC seems to be getting to the program being run under the adb shell.
All commands get echoed in my "adb shell" (as if set -v was on, but it isn't).
I notice that input doesn't seem to get sent to adb shell from my cygwin shell in "raw mode" -- i.e., any text I type gets buffered locally until I hit carriage return -- then the entire line gets sent. I'm not sure why that would make ESC ineffective, but certainly vi doesn't expect to be receiving input in quite that manner and perhaps its an indication of something unusual in my environment.
Similar to #1, bash (Bash X) seems to receive it, although echoing from bash is very strange. I can use ESC to enter "edit mode" in my bash shell (Bash X) to scroll through my history (I've run set -o vi), but the experience is very strange. When I hit ESC,k, nothing changes on the screen but my location in the command history goes up one rung (as it should); subsequent presses of 'k' cause a 'k' to be echoed to the screen (instead of the relevant command from my history list). When I finally hit carriage return, the correct command from my history list is executed (!).
UPDATE 2: Progress…
I tried setting the stty value in the "adb shell" to the same as the ones in my cygwin bash shell and that didn't have any effect.
I also tried this: Avoiding escape timeout issues in vim but it didn't help.
I tried this (by reading in from a file using :so <filename>).
Unfortunately, the commands weren't recognized by "vi" (they are actually "vim" commands).
Partial Solution:
Typing a <cr> immediately after the ESC when in "vi" works -- the ESC is accepted and I can exit the editor. It's awkward, and the editing window is still unusable (as if TERM was set to the wrong value), but this is progress.
Also, things work fine when I ssh in. That shell gets started by the telnet server; similar situation as Terminal Emulator directly on the device. Ssh has its own server which then forks off the shell. In the case of the "adb shell", the shell is forked off by /sbin/adbd -- as far as I can tell, there is simply something unusual about that environment. This is a huge step for me -- at least now I have a way to do full screen editing on the device using my PC (rather than editing directly on the S4's tiny screen). Thanks to Jack Palevich for that suggestion.
I can only think of two things to try at this point:
Try running adb shell against someone's device (but the device must be running root, so that I can run Busybox's "vi") (BTW, the version of "vi" is not the problem -- it runs fine from ssh.)
As someone else to run "vi" in "adb shell" on my device, from their host (preferably someone who has succeeded in running "adb shell" and vi somewhere previously.
I'm starting to think that It Simply Doesn't Work.
UPDATE 3: Info from XDA Developers
I found some relevant posts on the XDA Developers forum. It seems to be the case that people have had problems with this for a long time (since at least 2010). I didn't find any solutions.
XDA Link 1
XDA Link 2
XDA Link 3
There is also a paragraph listing various perceived/proposed adb shell bugs that match my experience, here:
Proposed ADB Shell Bugs
You're right - it simply doesn't work under Windows or Cygwin shell. I found that the simplest way to make it work is to use PuTTYTray.
Check my answer in the linked thread for instructions and additional details.
Another solution: Use Windows PowerShell instead of cygwin. Commands like 'o', 'esc', and ':wq' work nicely here.
Actually, there is no screencap utility out of box in Amazon Kindle Fire HD. Id'like to install it to /system/bin/ via adb to call from the command line (still via adb) at the moments when I need to have a screenshot and logcat is not enough to attach the to bug description.
There are some descriptions how to use screencap utility for such purpose: http://habrahabr.ru/company/intel/blog/152122/
(see
adb shell screencap /sdcard/screen.png
adb pull /sdcard/screen.png screen.png
adb shell rm /sdcard/screen.png
)
However, it seems that my device uses Android 2.3 Gingerbread, so there is no screencap utility out of box. So, the question are 1) Is there a way to push screencap of other Android versions to /system/bin/ 2) where I can download it online?
Other approaches working with adb shell are welcome.
I don't know exactly if this will help you, but I once happened to find out several other ways of capturing a screenshot. From what I know, they do not depend on the screencap but rather on the ADB daemon. All of them require your device to have USB debugging turned on.
I would really suggest trying this simple utility out: http://www.roman10.net/a-program-for-taking-screenshot-for-android-device-from-command-line/ which essentially reimplements the DDMS screenshot functionality without the whole GUI. It automatically writes it on your computer so there's no need for push/pull. It's pure Java so it's a great bonus.
Scroll down to the download section where you can download just the binary and test it out.
Another method would be to use MonkeyRunner described here: http://developer.android.com/tools/help/monkeyrunner_concepts.html. All you need to do is write a simple script which captures the screen, which is shown on the page from the link.
Unfortunately I don't know if android-tools-adb provides MonkeyRunner.
Another tool is Android Screenshots and Screen Capture: http://sourceforge.net/projects/ashot/
It just needs the Android SDK installed and I suspect it runs on the same principle as DDMS or the first program - from Roman10.
Hope that helps!
I have many questions about Android command. I do not know where I should start But, anyway, I have put all question related Android commands. Here ;
Is subset of Linux commands come in Android by default ? Or, Are we installing something ?
In system/bin, there are lots of commands. Where can I find their meaning ? I have tried man, but man is not built in.
Can I start and stop application via start and stop command ?
Why cannot I run the reboot from terminal emulator ? The error permission is denied.
NOTE : feel free to reedit the question, if you see meaningless part.
Is subset of Linux commands come in Android by default ? Or, Are we installing something ?
A subset exists by default within the system. Things like ls, cd, mkdir, cat etc... are present. You can gain access to a wider range by installing Busy Box on a rooted device, as stated by Zac.
In system/bin, there are lots of commands. Where can I find their meaning ? I have tried man, but man is not built in.
The ADB Page is a good place to start. That covers many of the basic ADB and shell commands. It states near the bottom:
"For a complete list of commands and programs, start an emulator instance and use the adb -help command."
So you can use adb -help on an emualator or device to see a full list of the ADB and shell commands (note I think this list will be android specific commands only, it won't include things like cd,ls and other basic unix commands).
Can I start and stop application via start and stop command ?
No, it states on the ADB dev page:
start ........ Starts (restarts) an emulator/device instance.
stop ........ Stops execution of an emulator/device instance.
To start an application you'll use the am utility iirc it will look something like am start com.your.packagename It's been a while though, I might have syntax wrong. The instructions are listend if you issue the am command by itself with no params in a shell.
Why cannot I run the reboot from terminal emulator ? The error permission is denied.
The system prevents applications from rebooting the device unless they are signed with the same key as the OS. When you use the terminal emulator you are restricted to whatever permissions that application has declared. The reboot permission is not granted to any third party applications, so it won't work correctly from any terminals. You could probably do it if your device was rooted and you used su though
EDIT:
Here is another good resource that lists more of the shell commands
There are not many Linux commands included in android, however if you are rooted you can easily install busybox which has a large range of linux commands.
You need to have root access to reboot your device via the command line (to prevent any old app being able to do it)
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