In Windows, are there some command lines that would make the machine understand that Android should be the next boot (for one boot only -so once I reboot from Android I fall back into Windows)?
I am working on a notebook ASUS X200CA, UEFI-based machine, dualboot: Windows 8.1 and Android 7.1 (two different partitions).
When Android is installed, I get Grub2, so at reboot I can manually choose between Windows or Android. However, I want to be able to switch OS programmatically.
Basically, I am looking for the equivalent of Linux - efibootmgr -n xxxx or grub-reboot x before using reboot - that I could implement on Windows.
I tried to use bcdedit /enum firmware to check the ID associated to Android then ran bcdedit /bootsequence {ID}. At reboot, this led to an error like:
File: \efi\Android\BOOTx64.EFI Status:0xc000000d Info: The application
or operating system couldn't be loaded because a required file is
missing or contains error
(NB: secure boot disabled, fastboot disabled)
I tried to use EasyBCD, but since this is an UEFI-based machine I
didn't get very far.
I added Android to Windows Boot Loader using BOOTMGR, restarted, got
to Windows Boot Loader, found the Android option, manually picked it
and got the same error message (see above).
I tried Grub2win, you can modify the EFI boot order with it, but it
seems that it's not for one boot only.
I know that some tablets dual boot Windows-Android have wintoand.exe that allows to switch but I am not sure what's behind. Moreover, I would prefer to not have to use any software: I want to know what command lines can achieve what I need.
If you have some ideas of how to solve this or anything to read that could guide me, Thanks for sharing in advance!
I believe Grub2Win has the function you are looking for. Documentation will be found in the Grub2Win help under keyword Reboot.
The command format is:
C:\grub2\grub2win reboot x
where x is the menu selection number. This can be run from the Windows command line or a .bat file.
You will receive a message that the reboot has been scheduled.
If you wish to cancel a previously scheduled reboot, use this command:
C:\grub2\grub2win reboot none
Hope this helps.
Dave
Phone: OnePlus 3t. Rooted. No updates.
Booting problems, so adb started from TWRP recovery screen.
Whether I enter "wm size reset" or "am size display-reset", it is telling me "/sbin/sh/: wm: not found" or "/sbin/sh: am: not found" respectively.
If I try it in TWRP terminal I get the same, except "sh:" instead of "/sbin/sh/:".
First time using adb tools, so I could be doing something basic wrong.
Can't use phone until I manage to fix the resolution issue. Grateful for any help.
That is because TWRP has no screen management. The use of certain commands in TWRP is restricted and limited.
am stands for activity manager, which is a process from the Android Operating System, but when you start on recovery mode not every layer of the OS is started.
I hope it helps.
I have (or rather had :( ) a Glass running the XE8 version of software. It did not receive any automatic updates since it was rooted (as expected).
I tried to update it to XE12 using the system image from https://developers.google.com/glass/tools-downloads/system, and now it won't boot.
I can see the screen light up for a moment when it tries to boot, but the Glass logo does not come up. Instead, it just reboots itself over and over. Sometimes the screen flashes white instead of the usual reddish-gray.
I can still boot to bootloader using the hardware method. I have tried flashing XE11 but the result is the same.
I have a couple of questions that I think could be related to the problem:
1) There is a note on the system image download page regarding a "firmware change" in XE10 that prevents installation of earlier system versions (which includes XE8). Could that be my problem? Does that refer to low-level firmware change? How is that update applied when using the OTA update mechanism and can I apply it manually?
2) There is a relatively large userdata.img file in the system image .zip, however it does not get flashed using the fastboot update method:
fastboot -w update glass_1-img-947604.zip
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: 0.5
Baseband Version.....:
Serial Number........: [device serial]
--------------------------------------------
checking product...
OKAY [ 0.002s]
sending 'boot' (4528 KB)...
OKAY [ 0.208s]
writing 'boot'...
OKAY [ 1.670s]
sending 'recovery' (5334 KB)...
OKAY [ 0.243s]
writing 'recovery'...
OKAY [ 1.797s]
sending 'system' (485525 KB)...
OKAY [ 21.414s]
writing 'system'...
OKAY [ 64.458s]
erasing 'userdata'...
OKAY [145.384s]
formatting 'userdata' partition...
Erase successful, but not automatically formatting.
File system type not supported.
OKAY [ 0.002s]
erasing 'cache'...
OKAY [102.827s]
formatting 'cache' partition...
Erase successful, but not automatically formatting.
File system type not supported.
OKAY [ 0.002s]
rebooting...
If I try to flash userdata.img explicitly I get the following error:
fastboot flash userdata userdata.img
sending 'userdata' (137046 KB)...
OKAY [ 6.049s]
writing 'userdata'...
FAILED (remote: : Sparsed Write)
Is the userdata image supposed to be written to the device?
3) Is there any way of getting the boot log using fastboot to determine what causes the crash?
Thanks.
UDPATE: I have flashed the XE8 image back and now the Glass is stuck on the empty battery screen despite being plugged in for a couple of hours. However I have had charging issues with this unit before, hopefully it gets resolved overnight.
UPDATE #2: Having been left to charge overnight the device was displaying the empty battery icon with a question mark when I got back to it in the morning, however after forced reboot it seems to have booted up fine into the old XE8 system. My next step will be to restore it to unrooted state and attempt to update it using the OTA update mechanism.
I have managed to get the update working.
If you are still running a pre-XE10 system, chances are that straight reflashing of the system image to a post-XE10 version is not going to work. My best guess is that it has something to do with lower level firmware that cannot be updated simply through flashing the boot/system partition.
So if you have a rooted pre-XE10 Glass, the way to get it to update to XE12 or later is to restore it to unrooted state by flashing the boot.img from an unrooted system image.
If you have already flashed a post-XE10 version and the device won't boot, make it boot to the bootloader using the hardware method as described here: Having issues seeing GLASS in Fastboot
and flash the whole system image of a pre-XE10 version.
The links to old pre-X10 images are no longer available on the Glass developers page, however the files are still there and can be located with a bit of googling.
I am not sure that restoring the oem lock after flashing the unrooted boot partition image is required, but I did that just in case:
fastboot oem lock
Reboot the Glass afterwards and it should be able to auto-update to the latest XE version. The check for updates can be triggered by plugging the USB cable in.
When the update is complete, just repeat the original rooting steps if you need it rooted.
I have searched but not found any queries or answers for my specific circumstance. I have a fast new machine with plenty of memory running Windows 7. I'm using the latest Eclipse and Android SDK.
When I run an app the emulator takes about 45 seconds to start (blazingly fast for the emulator!) from run initiation to running my app.
If I then change the app and re-run it on the still-running emulator, the time increases to 70+ seconds! As opposed to all other complaints people have, in my case restarting the emulator is faster than using the existing instance. I don't like that.
Here are the times:
2011-09-29 13:07:13 - hello Uploading hello.apk onto device 'emulator-5554'
2011-09-29 13:07:18 - hello Installing hello.apk...
2011-09-29 13:07:37 - hello Success!
on rerunning after changing the app to get it to reload:
2011-09-29 13:08:18 - hello Uploading hello.apk onto device 'emulator-5554'
2011-09-29 13:09:16 - hello Installing hello.apk...
2011-09-29 13:09:24 - hello Success!
As you can see, the upload to the emulator takes a mere 5 seconds when the emulator is freshly started. It takes nearly a minute with a running emulator! This is the cause of the extended re-running time. This doesn't change even when I uninstall the app on the emulator before re-running it.
Any ideas on what I could try to solve this? It appears to be some kind of communication problem, possibly with adb.
As others have posted, just clicking around in the emulator while uploading drastically improves the upload speed. I had the same problem and Googled for an answer, and trying out this trick helped me. I'm running a 2.3.3 AVD.
My new discovery is a small "hack" how you can make your upload faster. I realized that the cases when the upload was faster were caused by my interaction. So when I upload new app without active working with emulator, it is slow. But when I work with it (testing my application, exiting, opening applications list, etc.), the upload is MUCH faster - in my case approx. 15seconds instead nearly 2 minutes.
So I think, that the problem is somehow in performance settings of the emulator. When I do nothing, it thinks no big performance is needed, emulator is switched to some economic state, so also my upload is slow.
A better solution:
Go to Run -> Run Configurations... -> Target Tab -> Additional Emulator Command Line Options. Add there:
-netspeed full -netdelay none
Now close the emulator and run it again.
After doing this the time for uploading went from 2 minutes to 8 seconds.
Edit:
I have also found that quitting Skype makes my emulator upload much faster.
I have the same problem, I'm developing an android application which is like 4,6MB and it takes me like maybe 50-60 seconds to upload it on emulator and run it.I don't think this is a problem with the communication. The JVM is slow, that's why you need a time to upload your apk and run it.I don't think you can do anything about it, except you start testing your application on a device.
Play with the emulator while uploading your application. I totally agree with teepee. It reduced my waiting time from 4 minutes to 30 secs.
The fastest emulator you can get it's a VMWare machine with Android.
While developing my game, Elastic World, I was suffering from the same problem. After waiting minutes for the emulator to startup, the game was running at 20 FPS maximum. Even on low end android devices I could easily get 60 FPS. The upload speed was very slow.
So I moved to a VMWare Android machine, following the instructions from this site: http://www.android-x86.org/documents/installhowto/
The same game loop now runs at 250 FPS. (it's not playable at this speed and I have the game limited to max 60 FPS, but overriding this limitation it gives 250 FPS)
When Eclipse ends the build process I just have to wait 1 to 5 seconds for the game to appear on the virtual machine. And I'm running an old Core2Duo
This is not an issue with the AVD, it's eclipse the problem and I don't know if there is a way to change it within what we could call the jungle of parameters.
To be brief you can launch an emulator all by yourself in a console command
using the following :
emulator.exe -avd MyAVDName -netspeed full -netdelay none
Nice the parameters, why isn't Eclipse using it?
Some Eclipse coder should make it the default.
Another solution is to switch to IntelliJ IDEA. It will gloriously replace your old clunky IDE with a fresh and better one.
I know this is an old topic, but I think I actually have a solution to this issue.
First you need to boot the emulator without the netspeed arguments like follows:
emulator -avd <name>
Once it's started log in to the emulator using telnet. You can get the port from the top of the emulator window or by running adb devices and looking at the serial for the emulator which is in the form emulator-port (this is usually 5554 in most cases)
telnet localhost 5554
After you've logged in using telnet you need to issue the following command to force the emulator to use a very high network speed
network speed 500000
You can then check this setting in telnet using the following command
network status
Which should return
Current network status:
download speed: 500000000 bits/s (61035.2 KB/s)
upload speed: 500000000 bits/s (61035.2 KB/s)
If you now try to install the APK you should find the performance is dramatically increased. In my case it went from 260s to 18s.
Just thinking out loud:
I don't know this for a fact, but I'm wondering if this slow down is because Android applications each have their own instance of the Dalvik VM and run as a separate user and process. When you "think" you have closed your application, Android may be keeping the process (definitely the VM) alive in case you restart the application. This is similar to the pre-fetch behavior in windows.
When you re-run the application, after modifying the sources, Android perhaps has to destroy the cached instance. The additional delay you notice in the case of re-deployment in the same emulator instance may be because of the costs incurred in gracefully shutting down the VM and the application.
I get the same problem, but I'm convinced it has something to do with the O.S., because I uploaded the same application using a MacBook Pro and a Dell laptop, which is more powerful, given the hardware spec, however the upload time is significantly lower on the Mac.
On this Dell laptop with Windows, however, uploads to actual Android devices are way, way faster.
I thought it might be related to the "Google USB Driver package", that I haven't installed before, but after installing it, nothing really changed.
Try to set your emulator RAM to 1024.
Elaborating on what teepee said in an earlier post, I've found that if I muck with the already-running AVD during the uploading phase, it finishes MUCH quicker (5 seconds vs 60 seconds) and I'm installed and running in a fraction of the time. This is with a 4.0.3 AVD. Haven't tried the others yet.
The alternative ways:
Setting up a FTP server on your pc for hosting apk files, now you can download apk files by android emulator web browser and install app directly whitout using adb.
or
Install a samba client on android emulator and share apk files on your pc, then copy apk files to emulator and install app directly whitout using adb.
All of above ways are faster than adb install.
Silly question - did you try it on several AVDs? It is possible your one AVD is messed up in some way.
Do as much interaction with emulator as you can while uploading the apk on emulator, if you press random buttons of emulator while uploading it will upload early, before it took 5-6 mins to upload but now it take only 15 - 20 secs.
I have seen this too. Here is something that helped, assuming you've been using the same AVD.
Wipe the user data on the AVD. After doing this, it would load the app much faster again, a couple of seconds.
In a terminal/console I shell into the AVD with adb -e shell then go to the tmp directory where the apk is being uploaded cd /data/local/tmp then do ls -l to see the current file size. I've found that if I sit there and keep hitting up arrow then enter to quickly repeat the ls -l the upload speeds up dramatically. You can watch the progress as the file size increases.
This is probably similar to the effect of clicking around in the AVD others have mentioned.
I'm on a Mac. Not sure if it's the same on Windows or Linux.
This might work on windows,
start the Task manager --> processes tab--> look for emulator.exe,
right click and set priority to high
dont forget to set it to normal after your work is done.
also closing unwanted applications which require a lot of memory like chrome and firefox can be closed when not needed.
How do I get root access in order to reboot the emulator? How do I kill all unwanted processes along with the child process?
You have already root access to your emulator. To kill a process and all childs just use the device view in eclipse, select the emulator theere and chose which process you want to kill.
I have no idea on how to restart from code if you are looking for that. Rebooting the device should be easy: just close it and than boot it up again.
(I have the feeling I don't really get what you want...)
Most su binaries for Android depend on SuperUser.apk (available for free through the market). The su binary uses this apk to ask the user if it's ok to do whatever is being requested (and the user can opt to remember the answer). If you're using such a su, you need to also have that apk.
Once the pieces are in place, your application can spawn a process with the right arguments... something like argv[0]="/path/to/su", argv[1]="-c", argv[2]="(whatever command you want to run)", argv[3...n]=arguments to your command.
To kill a process in the command line, simply issue the following command line on the shell:
kill-9 YOUR_PID
If you know the name of the process, but not the pid, use
kill -9 $(pidof NAME_OF_PROCESS)
You can also use it on your code:
Runtime.getRuntime().exec("kill-9 YOUR_PID");
Check the man page for more details: http://unixhelp.ed.ac.uk/CGI/man-cgi?kill
ps-after rebooting i also wanted to kill all unwanted process except my specific app and its child process alone to run in emulator.
If that is really what you want to do - repurpose an android build as a generic embedded linux, then the way to go about it is to regenerate a ramdisk image (which android packs onto the kernel) containing an init.rc which launches your application rather than the android native services and (java-esque dalvik) android runtime. Rebuilding the ramdisk requires a unix-like OS and that arcane cpio command line which you can find in web search. I'd be tempted to leave the startup of ADB in there so you can debug the various things which will go wrong.
For testing purposes simply typing "stop" from the adb shell will shut down the android runtime and give you a UI-less virtual pocket linux box. There will still be some native services running but they may be more help than harm. Ultimately you may need to set OOM killer values on the things you add, though without the runtime up that may not be an issue in the near term if you don't consume much memory.
Or if what you want to do is have a very locked down and limited UI built on top of the android runtime, you would instead develop a custom home screen , test this on an unmodified emulator, and then deploy it on a build customized to lack any means of installing other applications.