I try to start an android sdk emulator, but when I press the back button this error appears:
INFO | Critical: Failed to load https://maps.googleapis.com/maps/api/mapsjs/gen_204?csp_test=true: The 'Access-Control-Allow-Origin' header has a value 'qrc://' that is not equal to the supplied origin. Origin 'qrc://' is therefore not allowed access. (qrc:/html/js/common.js:0, (null))
INFO | Critical: Failed to load https://maps.googleapis.com/maps/api/mapsjs/gen_204?csp_test=true: The 'Access-Control-Allow-Origin' header has a value 'qrc://' that is not equal to the supplied origin. Origin 'qrc://' is therefore not allowed access. (qrc:/html/js/common.js:0, (null))
I use Ubuntu and try to start the emulator through terminal, I use the avdmanager of the google cmdline-tools (latest version) and this is the AVD that I try to use:
Name: my_avd_29ii
Path: /home/user/.android/avd/my_avd_29ii.avd
Target: Google APIs (Google Inc.)
Based on: Android 10.0 (Q) Tag/ABI: google_apis/x86
Sdcard: 512 MB
The best option would (Needs to be done for every emulator you install)
Windows
%USERPROFILE%\.adnroid\avd\<Emulator Name>.avd
Edit config.ini
Change hw.keyboard=no to hw.keyboard=yes
Mac
~/.adnroid/avd/<Emulator Name>.avd
Edit config.ini
Change hw.keyboard=no to hw.keyboard=yes
The answer is based on this article
After looking around I found that there were two ways to push hardware events to the emulator:
First method
This method uses telnet, like so:
telnet 127.0.0.1 5554
auth <auth-key>
event send EV_KEY:KEY_BACK:0
event send EV_KEY:KEY_BACK:1
This is going to simulate the pressing down (0) the releasing (1) of a button.
Second method
This method uses adb, like so:
adb shell input keyevent KEYCODE_BACK
Ok so what?
After trying both, I realized that telnet didn't work but adb did work. I also checked the source code of emulator and saw that telnet relies on the same set of functions that are used by the tool-window. So it's probably a bug, and we can wait for the update to fix it, or...
In the meantime
I downloaded the source code, wrote a janky workaround, and built it. Basically instead of using the keypress method, I use the adb method. If you want here it is. It's quite voluminous so be patient. I included a small script to automatically replace the emulator, just run:
$ chmod +x replace
# ./reaplace path-to-android-sdk
This adds a new flag -use-adb-toolwindow to emulator. When you activate it it will use adb (successfully) for most of keyboard inputs, and home, back, apps and power buttons. Like I said it's a quick fix, but for me it works fine.
Note:
I have no clue where the bug is, so I didn't do any report, hopefuly as more people get this issue it will become clearer.
Related
I am using Google's Datastore (which is Firestore's support for the GCP) and the emulator to handle storage locally. Everything works fine as far as storing data. But there does not appear to be any way of actually viewing the data in the browser. I have a feeling that this is not yet implemented because the emulator is still in beta. Has anyone been able to view data in their browser? It should be stressed that this is the emulator provided by the Google Cloud Platform SDK and not the one that Firebase uses for its products. The emulator is started with:
gcloud beta emulators datastore start
As of January 2022
Debugging
Setting up Firebase Datastore Emulator (FDE)
The Firebase Datastore Emulator (FDE) emulates the Google Datastore in App Engine. This is meant to run on Java 8 platforms. When correctly setup, any Datastore operations are done locally and stored to a file called local_db.bin.
The documentation for using the Firebase Datastore Emulator can be found at:
https://cloud.google.com/datastore/docs/tools/datastore-emulator
It should be noted that this documentaton contains errors and is missing some important settings. To use Firebase Datastore Emulator, install the emulator by running the following command from a terminal:
gcloud components install cloud-datastore-emulator
Start the emulator in a terminal:
gcloud beta emulators datastore start --data-dir=fbdatastore --host-port=localhost:8100
The official documentation does not indicate to use the --host-port flag. If you leave this flag out, a random port will be selected. But experience has shown that letting the port be randomly selected can result in exceptions generated by the client library used to access the local datastore - even when the port is correctly set in the environment variables.
The --data-dir flag indicates the directory where the local database file is stored. Here, it is specified as fbdatastore but you can use any folder located anywhere. You should make sure that the folder already exists before you start the emulator. In the example shown here, no path is included. This means that when you start the emulator, the directory specified by --data-dir should be in the same folder where you are launching the emulator.
The emulator will only create the local_db.bin file when you initially write data to it. If you don't write any data, it will not be created. Even it isn't created, the client APIs will still work correctly when reading from it, typically returning null values for any entities that you attempt to access. No exception will be thrown if the database file does not exist.
If the --data-dir is set to fbdatastore as used here, the local_db.bin file will be created under:
fbdatastore/WEB-INF/appengine-generated/local_db.bin
After the emulator has started, you can verify that it is running but opening a browser window and navigating to the url:
http://localhost:8100
This will only display the text "ok".
Before you can start debugging the app, several environment variables need to be set. You need to open a new terminal window and execute the following commands to set several variables:
export DATASTORE_DATASET=[project-id]
export DATASTORE_EMULATOR_HOST=localhost:8100
export DATASTORE_EMULATOR_HOST_PATH=localhost:8100/datastore
export DATASTORE_HOST=http://localhost:8100
export DATASTORE_PROJECT_ID=[project-id]
export DATASTORE_USE_PROJECT_ID_AS_APP_ID=true
The client libraries for the Datastore expect the app id to be used. But it was found that using only the app id didn't work. The environment variable DATASTORE_USE_PROJECT_ID_AS_APP_ID needs to be set as well. This is not specified in the documentation.
It should be noted that the official docs show the following:
export DATASTORE_DATASET=my-project-id
export DATASTORE_EMULATOR_HOST=::1:8432
export DATASTORE_EMULATOR_HOST_PATH=::1:8432/datastore
export DATASTORE_HOST=http://::1:8432
export DATASTORE_PROJECT_ID=my-project-id
For MacOS, this is wrong. The variables with values set to ::1 is wrong. Using this will cause exceptions and probably prevent the emulator from even loading. The ::1 needs to be replaced with localhost, as shown above.
You can just copy the 6 lines shown above and paste them into a terminal and hit Enter. But it is easier to just place these into a bash file and execute it. These need to be set before the local development server is started. The following bash file will set the environment variables and then start the development server:
export DATASTORE_DATASET=[project-id]
export DATASTORE_EMULATOR_HOST=localhost:8100
export DATASTORE_EMULATOR_HOST_PATH=localhost:8100/datastore
export DATASTORE_HOST=http://localhost:8100
export DATASTORE_PROJECT_ID=[project-id]
export DATASTORE_USE_PROJECT_ID_AS_APP_ID=true
java_dev_appserver.sh --address=0.0.0.0 --port=8080 --disable_update_check --jvm_flag=-Xdebug --jvm_flag=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 build/exploded-website
Replace [project-id] with the project id shown in your Googel Cloud Platform console (don't include the square brackets).
The address parameter for java_dev_appserver.sh is set here to 8000. You will need to set this in your IDE. Also, the port for java_dev_appserver.sh is set to 8080. You can set this to whatever works on your system and doesn't conflict with any existing ports used elsewhere. The last parameter for java_dev_appserver.sh is the location of your war files, which is the compiled app. Here, it is located at build/web-site. Replace this with the location of your own build files.
To view the datastore locally in your browser, navigate to:
http://localhost:8080/_ah/admin/datastore
Details on the command parameters used to start the emulator can be found at:
https://cloud.google.com/sdk/gcloud/reference/beta/emulators/datastore/start
As far as I can understand what you want to do is to add data in the Datastore emulator running on your console and be able to see this data in the UI right?
Vieweing the data in the UI actually incurs in expenses for you because Datastore have to query the data to be able to display it on the UI.
I can still recommend you to create a Feature Request if you want to be able to see the entries form the Datastore emulator for free in the UI
I am trying to run AOSP(oreo 8.1) build on emulator.
I used following commands to build AOSP.
source build/envsetup.sh
lunch aosp_arm-eng
make -j4
my build was successful. Now i'm trying to run on emulator using following command.
emulator
emulator is started with following warning message.
Could not automatically detect an ADB binary. Some emulator functionality will not work until a custom path to ADB is added in the extended settings page.
After successful boot "System UI isn't responding" message is displaying on the emulator, also emulator is running real slow.
Any help in resolving this issue is greatly appreciated.
emulator screenshot: system ui isn't responding
emulator: WARNING: system partition size adjusted to match image file (2050 MB > 200 MB)
emulator: WARNING: encryption is off
main-loop: WARNING: I/O thread spun for 1000 iterations
It often occurs - especially on slow machines running CPU-consuming emulations, that an emulator would initially load into a state where a System UI isn't responding alert shows. It does not necessarily mean the device isn't working; Often enough, the alert can be dismissed and the device will be completely functional from that point on.
I'm not sure what the exact issue to solve here is. Nevertheless, assuming you're running on CI and - besides the emulator's sluggishness, wish to overcome the System UI isn't responding alert appearing upon boot completion (as suggested by the title) -- may I suggest this bash script (gist):
#!/bin/bash
echo ""
echo "[Waiting for launcher to start]"
LAUNCHER_READY=
while [[ -z ${LAUNCHER_READY} ]]; do
UI_FOCUS=`adb shell dumpsys window windows 2>/dev/null | grep -i mCurrentFocus`
echo "(DEBUG) Current focus: ${UI_FOCUS}"
case $UI_FOCUS in
*"Launcher"*)
LAUNCHER_READY=true
;;
"")
echo "Waiting for window service..."
sleep 3
;;
*"Not Responding"*)
echo "Detected an ANR! Dismissing..."
adb shell input keyevent KEYCODE_DPAD_DOWN
adb shell input keyevent KEYCODE_DPAD_DOWN
adb shell input keyevent KEYCODE_ENTER
;;
*)
echo "Waiting for launcher..."
sleep 3
;;
esac
done
echo "Launcher is ready :-)"
The script awaits for the launcher to become ready and in-focus, and automatically dismisses system responsiveness alerts, coming its way.
It in no way addresses the emulator's sluggishness, however.
See this answer from another question to fix the ADB error. However, this will likely not fix the responsiveness of your emulator.
The emulator tends to function extremely slowly if you are compiling aosp for a different architecture than your host machine. If you are building on an x86 machine an x86 build will result in a significantly faster emulator that won't eat up all of your machine's resources.
May be this answer could be helpful for someone who have made a mistake like me and could save his time.
I faced this issue on my physical device as i used an app icon of very large size (2100x2100). I resolved it by using an app icon of low size(512x512).
I am using Google Chrome 63.
In DevTools in Performance tab there are three CPU throttling settings: "No throttling", "4x slowdown" and "6x slowdown".
Is it possible to set custom throttling, for example "20x slowdown"? It could be via setting some flag in chrome.exe file or programmatically via NodeJS library.
I found that Lighthouse library has kind of helpful function but if I change the default value inside it (CPU_THROTTLE_METRICS seems to be equal to 4) from 4 to (for example) 20 and run it, how can I be sure it really is 20x slowed down?
Also, I would like to know, if it is possible to do such simulated "slow down" to the GPU in similar way?
Thanks for any advice.
Custom values for Emulation.setCPUThrottlingRate can be set right in Chrome, but you need to open a Dev Tools window on the Dev Tools window to change the setting programatically.
Open Dev Tools; make sure it is detached (open in its own window).
Open Dev Tools again on the Dev Tools window from step 1 using the key combination Cmd-Opt-i (Mac) or Ctrl-Shift-i (Windows).
Run the following in the Console tab: await Main.MainImpl.sendOverProtocol('Emulation.setCPUThrottlingRate', {rate: 40});
This example will throttle Chrome performance by 40x. NOTE: Passing 1 for rate turns off throttling.
The first Dev Tools window created in Step 1 may be re-docked after creating the second Dev Tools window.
Lighthouse uses Emulation.setCPUThrottlingRate command in the Chrome DevTools Protocol:
https://chromedevtools.github.io/devtools-protocol/tot/Emulation#method-setCPUThrottlingRate
You can monitor the protocol this way:
https://umaar.com/dev-tips/166-protocol-monitor/
You'll see this command in the protocol log when you switch with the throttling setting in the performance panel.
If you're asking how to be sure if it works - here is the implementation from Chromium source code:
https://github.com/chromium/chromium/blob/master/third_party/blink/renderer/platform/scheduler/util/thread_cpu_throttler.h#L21
// This class is used to slow down the main thread for
// inspector "cpu throttling". It does it by spawning an
// additional thread which frequently interrupts main thread
// and sleeps.
Hope this helps.
On Linux you can use cpulimit
sudo apt-get install cpulimit
# -l 5 means 5% , or 20x slowdown
cpulimit -l 5 chromium-browser
This is the error message that I have every time I run myTest.js. This happens after I installed the my IE driver in my VirtualBox so that I can test from IE browsers.
cor03rock at Rockys-MacBook-Pro in ~/Desktop/Jalekoo on dev*
💩 dalek myTest.js -b chrome
/Users/cor03rock/Desktop/Jalekoo/node_modules/dalekjs/lib/dalek.js:333
this.driverEmitter.emit('killAll');
^
TypeError: Cannot call method 'emit' of undefined
at Object.Dalek._shutdown (/Users/cor03rock/Desktop/Jalekoo/node_modules/dalekjs/lib/dalek.js:333:24)
at process.EventEmitter.emit (events.js:95:17)
at process._fatalException (node.js:272:26)
Jalekoo is my Dalek folder.
It would probably help if you could post a reduced test case & what DalekJS, NodeJS version your on, as well as your operating system. Maybe your projects directory layout could also help spotting the error.
You are also talking about having installed the IE driver & your example call shows -b chrome. So do you might have mistaken that.
Also, does that error occur with other browsers (PhantomJS for example) or only for IE (Chrome?).
Would love to help you out, but I need some more information to be able to.
I am looking for assistance with the proper GDB / OpenOCD initializion and running commands (external tools) to use within Eclipse for flash and RAM debugging, as well as the proper modifications or additions that need to be incorporated in a makefile for flash vs RAM building for this MCU, if this matters of course.
MCU: STM32F103VET6
I am using Eclipse Helios with Zylin Embedded CDT, Yagarto Tools and Bins, OpenOCD 0.4, and have an Olimex ARM-USB-OCD JTAG adapter.
I have already configured the ARM-USB-OCD and added it as an external tool in Eclipse. For initializing OpenOCD I used the following command in Eclipse. The board config file references the stm32 MCU:
openocd -f interface/olimex-arm-usb-ocd-h.cfg -f board/stm32f10x_128k_eval.cfg
When I run this within Eclipse everything appears to be working (GDB Interface, OpenOCD finds the MCU, etc). I can also telnet into OpenOCD and run commands.
So, I am stuck on the next part; initialization and commands for flash and RAM debugging, as well as erasing flash.
I read through several tutorials, and scoured the net, but have not been able to find anything particular to this processor. I am new to this, so I might not be recognizing an equivalent product for an example.
I'm working with the same tool chain to program and debug a STM32F107 board. Following are my observations to get an STM32Fxxx chip programmed and debugged under this toolchain.
Initial Starting Point
So at this point you've got a working OpenOCD to ARM-USB-OCD connection and so you should be all set on that end. Now the work is on getting Eclipse/Zylin/Yagarto GDB combination to properly talk to the STM32Fxxx through the OpenOCD/Olimex connection. One thing to keep in mind is that all the OpenOCD commands to issue are the run mode commands. The configuration scripts and command-line options to invoke the OpenOCD server are configuration mode commands. Once you issue the init command then the server enters run mode which opens up the set of commands you'll need next. You've probably done it somewhere else but I tack on a '-c "init"' option when I call the OpenOCD server like so:
openocd -f /path to scripts/olimex-arm-usb-ocd-h.cfg -f /path to targets/stm32f107.cfg -c "init"
The following commands I issue next are done by the Eclipse Debug Configurations dialogue. Under the Zylin Embedded debug (Native) section, I create a new configuration, give it a name, Project (optional), and absolute path to the binary that I want to program. Under the Debugger tab I set the debugger to Embedded GDB, point to the Yagarto GDB binary path, don't set a GDB command file, set GDB command set to Standard, and the protocol to mi.
The Commands Tab - Connect GDB to OpenOCD
So the next tab is the Commands tab and that's where the meat of the issue lies. You have two spaces Initialize and Run. Not sure exactly what the difference is except to guess that they occur pre- and post-invocation of GDB. Either way I haven't noticed a difference in how my commands are run.
But anyway, following the examples I found on the net, I filled the Initialize box with the following commands:
set remote hardware-breakpoint limit 6
set remote hardware-watchoint-limit 4
target remote localhost:3333
monitor halt
monitor poll
First two lines tell GDB how many breakpoints and watchpoints you have. Open OCD Manual Section 20.3 says GDB can't query for that information so I tell it myself. Next line commands GDB to connect to the remote target at the localhost over port 3333. The last line is a monitor command which tells GDB to pass the command on to the target without taking any action itself. In this case the target is OpenOCD and I'm giving it the command halt. After that I tell OpenOCD to switch to asynchronous mode of operation. As some of the following operations take a while, it's useful not to have OpenOCD block and wait for every operation.
Sidenote #1: If you're ever in doubt about the state of GDB or OpenOCD then you can use the Eclipse debug console to send commands to GDB or OpenOCD (via GDB monitor commands) after invoking this debug configuration.
The Commands Tab - Setting up the User Flash
Next are commands I give in the Run commands section:
monitor flash probe 0
monitor flash protect 0 0 127 off
monitor reset halt
monitor stm32x mass_erase 0
monitor flash write_image STM3210CTest/test_rom.elf
monitor flash protect 0 0 127 on
disconnect
target remote localhost:3333
monitor soft_reset_halt
to be explained in the following sections...
Setting up Access to User Flash Memory
First I issue an OpenOCD query to see if it can find the flash module and report the proper address. If it responds that it found the flash at address 0x08000000 then we're good. The 0 at the end specifies to get information about flash bank 0.
Sidenote #2: The STM32Fxxx part-specific data sheets have a memory map in section 4. Very useful to keep on hand as you work with the chip. Also as everything is accessed as a memory address, you'll come to know this layout like the back of your hand after a little programming time!
So after confirming that the flash has been properly configured we invoke the command to turn off write protection to the flash bank. PM0075 describes everything you need to know about programming the flash memory. What you need to know for this command is the flash bank, starting sector, ending sector, and whether to enable or disable write protection. The flash bank is defined in the configuration files you passed to OpenOCD and was confirmed by the previous command. Since I want to disable protection for the entire flash space I specify sectors 0 to 127. PM0075 explains how I got that number as it refers to how the flash memory is organized into 2KB pages for my (and your) device. My device has 256KB of flash so that means I have 128 pages. Your device has 512KB of flash so you'll have 256 pages. To confirm that your device's write-protection has been disabled properly, you can check the FLASH_WRPR register at address 0x40022020 using the OpenOCD command:
monitor mdw 0x40022020
The resulting word that it prints will be 0xffffffff which means all pages have their write protection disabled. 0x00000000 means all pages have write protection enabled.
Sidenote #3: On the subject of the memory commands, I bricked my chip twice as I was messing with the option bytes at the block starting at address 0x1ffff800. First time I set the read protection on the flash (kind of hard to figure out what your doing if you do that), second time I set the hardware watchdog which prevented me from doing anything afterwards since the watchdog kept firing off! Fixed it by using the OpenOCD memory access commands. Moral of the story is: With great power comes great responsibility.... Or another take is that if I shoot myself in the foot I can still fix things via JTAG.
Sidenote #4: One thing that'll happen if you try to write to protected flash memory is the FLASH_SR:WRPRTERR bit will be set. OpenOCD will report a more user-friendly error message.
Erasing the Flash
So after disabling the write protection, we need to erase the memory that you want to program. I do a mass erase which erases everything, you also have the option to erase by sector or address (I think). Either way you need to erase first before programming as the hardware checks for erasure first before allowing a write to occur. If the FLASH_SR:PGERR bit (0x4002200c) ever gets set during programming then you know you haven't erased that chunk of memory yet.
Sidenote #5: Erasing a bit in flash memory means setting it to 1.
Programming Your Binary
The next two lines after erasure writes the binary image to the flash and reenables the write protection. There isn't much more to say that isn't covered by PM0075. Basically any error that occurs when you issue flash write_image is probably related to the flash protection not being disabled. It's probably NOT OpenOCD though if you're curious you can take enable the debug output and follow what it does.
GDB Debugging
So finally after programming I disconnect GDB from the remote connection and then reconnect it to the target, do a soft-reset, and my GDB is now ready to debug. This last part I just figured out last night as I was trying to figure out why, after programming, GDB wouldn't properly stop at main() after reset. It kept going off into the weeds and blowing up.
My current thinking and from what I read in the OpenOCD and GDB manuals is that the remote connection is, first and foremost, meant to be used between GDB and a target that has already been configured and running. Well I'm using GDB to configure before I run so I think the symbol table or some other important info gets messed up during the programming. The OpenOCD manual says that the server automatically reports the memory and symbols when GDB connects but all that info probably becomes invalid when the chip gets programmed. Disconnecting and reconnecting I think refreshes the info GDB needs to debug properly. So that has led me to create another Debug Configuration, this one just connects and resets the target since I don't necessarily need to program the chip every time I want to use GDB.
Whew! Done! Kind of long but this took me 3 weekends to figure out so isn't too terribly bad I think...
Final sidenote: During my time debugging I found that OpenOCD debug output to be invaluable to me understanding what OpenOCD was doing under the covers. To program a STM32x chip you need to unlock the flash registers, flip the right bits, and can only write a half-word at a time. For a while I was questioning whether OpenOCD was doing this properly but after looking through the OpenOCD debug output and comparing it against what the PM0075 instructions were, I was able to confirm that it did indeed follow the proper steps to do each operation. I also found I was duplicating steps that OpenOCD was already doing so I was able to cut out instructions that weren't helping! So moral of the story: Debug output is your friend!
I struggled getting JLink to work with a STM3240XX and found a statement in the JLink GDB server documentation saying that after loading flash you must issue a "target reset":
"When debugging in flash the stack pointer and the PC are set automatically when the target is reset after the flash download. Without reset after download, the stack pointer and the PC need to be initialized correctly, typically in the .gdbinit file."
When I added a "target reset" in the Run box of the debugger Setup of Eclipse, suddenly everything worked. I did not have this problem with a Kinetis K60.
The document also explains how to manually set the stack pointer and pc directly if you don't want to issue a reset. It may not be the disconnect/connect that solves the problem but the reset.
What i use after the last sentence in the Comannd Tab - 'Run' Commands, is:
symbol-file STM3210CTest/test_rom.elf
thbreak main
continue
The thbreak main sentence is what makes gdb stop at main.