Chrome remote debug mac os

Chrome Remote Debugger

Use the Chrome Remote Debugger to debug a Cast application.

Launch Chrome Remote Debugger for a particular Google Cast device as follows:

To debug Cast apps on an Android TV device, see Android TV: Debugging.

To debug a Web Receiver app on Google Cast devices, do the following:

Both the application and device must be registered in order for you to perform debugging.

Start your sender app and cast to the Google Cast device to load the Web Receiver app for debugging. Make sure your sender and Web Receiver devices are connected to the same network. Important: Debugging will not work if the this step is skipped.

There are two ways to connect to your device for remote debugging:

In the Chrome browser, enter the following in the address field to go to the Chrome inspector:

A list of Cast-enabled devices on that network appears.

Select the device for the Web Receiver app you want to debug by clicking its Inspect link.

An inspector window should open, enabling you to remotely debug the Web Receiver app.

Directly to the device’s 9222 port

In the Chrome browser, enter the following in the address field to go to the device you are debugging directly. This may be faster than the Chrome Inspector if you have many devices on your network:

The device IP address can be found by selecting the device in the Google Home app, going to settings, and looking under the Information section.

Select the session you would like to debug by clicking its Remote Debugging link.

If the Chrome Remote Debugger does not populate, select the icon to the left of the address bar and select site settings . Scroll to the bottom of the settings and change the setting for Insecure content to Allow .

In the Chrome Remote Debugger console, enable debug logging, by entering the following:

Full DOM manipulation is supported as well as the full Chrome JavaScript REPL (console), which will allow you to tinker with the running Web Receiver app.

When your Web Receiver is torn down (lifecycle ended), the debugger will become inactive with a warning message along the top. At this point you can no longer interact with the debugger. To restart debugging, you must restart the Web Receiver app and then reload the inspector.

Breakpoints

You can add manual breakpoints to your code by using debugger; within your Web Receiver code.

Local caching

Use window.location.reload(true); to perform a forced reload that flushes the cache of the Web Receiver application.

Preserving logs between sessions

You can preserve the logs between sessions by clicking the gear icon within the debugger and checking the box next to “Preserve log upon navigation”.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Remote debug Android devices

Published on Monday, April 13, 2015

Technically, I’m a writer

Remote debug live content on an Android device from your Windows, Mac, or Linux computer. This tutorial teaches you how to:

• Set up your Android device for remote debugging, and discover it from your development machine.
• Inspect and debug live content on your Android device from your development machine.
• Screencast content from your Android device onto a DevTools instance on your development machine.

Figure 1. Remote Debugging lets you inspect a page running on an Android device from your development machine.

# Step 1: Discover your Android device

The workflow below works for most users. See Troubleshooting: DevTools is not detecting the Android device for more help.

Open the Developer Options screen on your Android. See Configure On-Device Developer Options.

Select Enable USB Debugging.

On your development machine, open Chrome.

Go to chrome://inspect#devices .

Make sure that the Discover USB devices checkbox is enabled.

Figure 2. The Discover USB Devices checkbox is enabled

Connect your Android device directly to your development machine using a USB cable. The first time you do this, you usually see that DevTools has detected an offline device. If you see the model name of your Android device, then DevTools has successfully established the connection to your device. Continue to Step 2.

Figure 3. The Remote Target has successfully detected an offline device that is pending authorization

If your device is showing up as Offline, accept the Allow USB Debugging permission prompt on your Android device.

# Troubleshooting: DevTools is not detecting the Android device

Make sure that your hardware is set up correctly:

• If you’re using a USB hub, try connecting your Android device directly to your development machine instead.
• Try unplugging the USB cable between your Android device and development machine, and then plugging it back in. Do it while your Android and development machine screens are unlocked.
• Make sure that your USB cable works. You should be able to inspect files on your Android device from your development machine.

Make sure that your software is set up correctly:

• If your development machine is running Windows, try manually installing the USB drivers for your Android device. See Install OEM USB Drivers.
• Some combinations of Windows and Android devices (especially Samsung) require extra set up. See Chrome DevTools Devices does not detect device when plugged in.

If you don’t see the Allow USB Debugging prompt on your Android device try:

• Disconnecting and then re-connecting the USB cable while DevTools is in focus on your development machine and your Android homescreen is showing. In other words, sometimes the prompt doesn’t show up when your Android or development machine screens are locked.
• Updating the display settings for your Android device and development machine so that they never go to sleep.
• Setting Android’s USB mode to PTP. See Galaxy S4 does not show Authorize USB debugging dialog box.
• Select Revoke USB Debugging Authorizations from the Developer Options screen on your Android device to reset it to a fresh state.

If you find a solution that is not mentioned in this section or in Chrome DevTools Devices does not detect device when plugged in, please add an answer to that Stack Overflow question, or open an issue in the webfundamentals repository!

# Step 2: Debug content on your Android device from your development machine

Open Chrome on your Android device.

In the chrome://inspect/#devices , you see your Android device’s model name, followed by its serial number. Below that, you can see the version of Chrome that’s running on the device, with the version number in parentheses. Each open Chrome tab gets its own section. You can interact with that tab from this section. If there are any apps using WebView, you see a section for each of those apps, too. In Figure 5 there are no tabs or WebViews open.

Figure 4. A connected remote device

In the Open tab with url text box, enter a URL and then click Open. The page opens in a new tab on your Android device.

Click Inspect next to the URL that you just opened. A new DevTools instance opens. The version of Chrome running on your Android device determines the version of DevTools that opens on your development machine. So, if your Android device is running a very old version of Chrome, the DevTools instance may look very different than what you’re used to.

# More actions: pause, focus, reload, or close a tab

Below the URL you can find a menu to pause, focus, reload or close a tab.

Figure 5. The menu for pausing, reloading, focusing, or closing a tab

# Inspect elements

Go to the Elements panel of your DevTools instance, and hover over an element to highlight it in the viewport of your Android device.

You can also tap an element on your Android device screen to select it in the Elements panel. Click Select Element on your DevTools instance, and then tap the element on your Android device screen. Note that Select Element is disabled after the first touch, so you need to re-enable it every time you want to use this feature.

# Screencast your Android screen to your development machine

Click Toggle Screencast to view the content of your Android device in your DevTools instance.

You can interact with the screencast in multiple ways:

• Clicks are translated into taps, firing proper touch events on the device.
• Keystrokes on your computer are sent to the device.
• To simulate a pinch gesture, hold Shift while dragging.
• To scroll, use your trackpad or mouse wheel, or fling with your mouse pointer.

Some notes on screencasts:

• Screencasts only display page content. Transparent portions of the screencast represent device interfaces, such as the Chrome address bar, the Android status bar, or the Android keyboard.
• Screencasts negatively affect frame rates. Disable screencasting while measuring scrolls or animations to get a more accurate picture of your page’s performance.
• If your Android device screen locks, the content of your screencast disappears. Unlock your Android device screen to automatically resume the screencast.

Last updated: Monday, April 13, 2015 • Improve article

Источник

Remote debugging web apps running locally (in Chrome OS)

“Wait, what… What do you mean ‘remote debugging apps running locally, how is that remote in any way?’” you might ask.

Well, it (sort of is). Did you know that Chrome OS can run Android apps, and, starting with Chrome OS 69, you can install Linux support? Search for “Linux” in Settings, tap Install, and in a couple minutes you’ll have a terminal window.

From then on, you can install use the same familiar development tools you’re using on Mac OS or Linux: Node, npm, VS Code, Android Studio and so on. Linux support is still in beta, but (almost) anything you can apt install works fine. The umbrella term for Linux application support in Chrome OS is Crostini, and you can read more about it on the Crostini page.

Chrome OS has gone from being the operating system with (perhaps) the fewest apps you could run, back in 2011 (just web apps and some Chrome apps), to the one that can run the most — Android, Linux, and web apps. This works thanks to a container/VM architecture that has only a small overhead, and no emulation while running Linux or Android apps.

For web app developers, this means that you can develop on Linux, then test on Android browsers running natively, on the very same machine, locally. Hence, local/remote debugging.

To do that, there are a few steps.

1. Set your Chromebook to Developer Mode: press Esc + ⟳ + Power. A yellow exclamation point (!) or “Please insert a recovery USB stick” is displayed. Press Ctrl+D to begin developer mode, then Enter.
2. Enable Google Play Store from Settings
3. Settings -> Google Play Store -> Manage Android preferences
4. Enable Developer Options in Android (tap About -> Build number 7 times)
5. In the newly accessible Developer options menu, enable ADB debugging (this is what requires Chrome OS to be in Developer Mode)
6. Download Android SDK latform-Tools for Linux
7. Install ADB: open the downloaded ZIP file, copy the platform-tools directory, and paste it in the Linux files folder
8. Open a terminal, then cd platform-tools; chmod +x adb
9. Run adb connect 100.115.92.2 (per https://developer.android.com/topic/arc/studio#running_locally) and accept the Allow USB debugging prompt.
10. Launch the Play Store and install Chrome Dev for Android. (We’re choosing Chromium Dev so that its icon is easy to distinguish from other Chrome instances we’ll be running on the Chromebook).
11. Open a terminal and run ip addr show . The 100.115… number is the IP of the Linux container.
12. Launch your web app server in that terminal window
13. Run Android Chromium Dev from the launcher and open your web app by navigating to the 100.115… IP and the port your server is listening to
14. In another terminal window (Ctrl+Shift+N), install Chromium for Linux: sudo apt install chromium
15. Launch Chromium (from the launcher, or by typing chromium in the terminal). It’s necessary to run a Linux Chrome/Chromium rather than the OS Chrome, because the ADB bridge is established between the Linux container and the Android container.
16. In Chromium, go to chrome://inspect. You should see your web app’s tab in the list of targets.
17. Click inspect. You should see something like this (the screencast shows the Squoosh app).

Troubleshooting

If you see “Pending authentication: please accept debugging session on the device” in Chromium DevTools, reboot the Chromebook. We’re working on a fix!

More about developing on Chrome OS

To learn more about what Chrome OS can do for web developers, check out my talk at Chrome Dev Summit ’18.

Источник