How to debug electron production binaries - electron

I can't open devtools in the built version of my electron app. Therefore i want to find another solution to log any errors that only occur in the production version.
Is there any good way to get some console.logs from an electron application if its already built?
Obviously i can debug the “development” version (running npm run dev) of my electron app by opening the chrome dev tools. But i can’t find any way to enable them inside my production application.
I am using the newsest version of electron-vue
Thanks for any help in advance.

Here's what worked for me on Mac.
In terminal type lldb path/to/build.app
In the opened debugger type run --remote-debugging-port=8315. It should open a window of your app.
Open Chrome at http://localhost:8315/
Click on the name of the app. For example, Webpack App.
If you don't see anything in the opened tab, focus on the window of your app.

Launch your Electron application with the --remote-debugging-port=8315 flag set and navigate to chrome://inspect/#devices in Chrome 80+. Then click Configure... and add localhost:8315 as a discovery server.
Then, wait for your Electron instance to appear in the devices list and click inspect.

Enabling the Chrome devtools in production can be done in various ways:
A environment variable:
E.g. under Windows set ELECTRON_ENV=development&& myapp.exe
Pass a special parameter to your app
E.g. myapp.exe --debug
Debug mode via user settings (if you have persistent settings)
Menu entry to open the devtools
Can be combined with 1.-3. to only have that menu entry when in debug mode
You can just check if 1.-3. are set and if they are, you simply open the devtools via mainWindow.webContents.openDevTools()
Personally I use a combination of 1., 3. and 4. I simply unlock a developer menu that allows me to open the devtools or opens the userdata folder for me.
If you also want to log critical errors, then electron-log looks like a rather popular option for electron.

On Mac just run open /Applications/WhatsApp.app --args --remote-debugging-port=8315 and then open http://localhost:8315

https://github.com/bytedance/debugtron
Debugtron is an app to debug in-production Electron based app. It is also built with Electron.

The way to do this is using the --remote-debugging-port flag.
Using Signal as an example, take the following steps:
start the application from the CLI
signal-desktop --remote-debugging-port
Open the debugging URL in a Google Chrome browser (in this case http://localhost:39733/), this will open a page with the app name on it .
Click the to open a screen were you can click around to use the app and see output in the devtools
Alternatively, you can open chrome://inspect/#devices in the Google Chrome browser and click "inspect" (underneath the app name) to open the same window

In my case, I had a runtime error crashing Electron before the web view was even shown. Chrome dev tools were not useful for debugging this kind of error.
Even stranger, the app loaded fine using the lldb commands:
lldb ./dist/mac/electron-quick-start-typescript.app
run --remote-debugging-port=8315
I managed to solve by writing the Node.js console log/error to a file. So I could see the console output:
import fs from 'fs';
import util from 'util';
// use a fixed path, to ensure log shows outside Electron dist
const logPath = `/Users/username/Sites/electron-server/debug-${isDev ? 'dev' : 'prod'}.log`;
const logFile = fs.createWriteStream(logPath, { flags: 'w' });
const logStdout = process.stdout;
console.log = function(...args) {
logFile.write(util.format.apply(null, args) + '\n');
logStdout.write(util.format.apply(null, args) + '\n');
}
console.error = console.log;
I found the error was a relative path issue. When the app is started in production mode the relative path did not point to the correct location.
I solved by using an absolute path, with Electron getAppPath() method:
- './renderer'
+ app.getAppPath() + '/renderer'

In the main/index.js at the end of section app.on('ready') just add:
mainWindow.webContents.openDevTools();
Just for debugging, when electron opens an empty window, but the development version works fine, this way is very helpful for me.

The answers above don't help for me. ( those with -remote-debugging-port)
put this code into your main.js or similar file, it will automatically open the dev-tool when started.
mainWindow.webContents.openDevTools()

June 2022 UPDATE:
Devtools can be explicitly enabled through on the BrowserWindow object.
mainWindow = new BrowserWindows({
...,
webPreferences: {
...,
devTools: true,
}
}
And then you can manually open it on load.
mainWindow.on('ready-to-show', () => {
if (!mainWindow) {
throw new Error('mainWindow is not defined')
}
mainWindow.show()
mainWindow.webContents.openDevTools()
})

Related

How to debug Electron main process after packaging?

I have created an Electron App(say MyApp). I have used electron-packager to pack the App. I installed the app in my local machine and I can see MyApp in the start menu. When I click on the Icon It launches the app but I am not able to debug it.
I can see the devtool
Electron version : "^5.0.7"
Electron Packager: "^12.2.0"
OS: Windows
Thanks in advance
I think the best way debug your main process would be to do so during development, i have found the information here on the Electron docs to be very useful https://electronjs.org/docs/tutorial/debugging-main-process
Also my Code Editor of choice is VSCode so i was able to use this link
https://electronjs.org/docs/tutorial/debugging-main-process-vscode
Its also good practice to have a Crash Reporter setup, Electron has the default one https://electronjs.org/docs/api/crash-reporter which also work great, but you can add other third party libraries like Bugsnag, Sentry or Backtrace.io.
Default Electron Crash Reporter
const { crashReporter } = require('electron')
crashReporter.start({
productName: 'YourName',
companyName: 'YourCompany',
submitURL: 'https://your-domain.com/url-to-submit',
uploadToServer: true
})
Using Sentry "You need an account for this option"
//You need to call init in your main and every renderer process you spawn.
import * as Sentry from '#sentry/electron';
Sentry.init({dsn:'https://<your-key-here>#sentry.io/15...5'});

--enable-precise-memory-info is not working on Mobile Chrome

Under the:
chrome://flags
I didn't find
--enable-precise-memory-info
Trying to run with:
ChromeOptions options = new ChromeOptions();
options.AddArguments("--enable-precise-memory-info");
also had no success, values are rounded.
Is it even possible?
Let me know if you need more details on this issue
Note: it's not about desktop, mobile chrome browse only!
One way of doing this is with adb
adb -s $deviceId shell am start -n com.android.chrome/com.google.android.apps.chrome.Main argv --args='--enable-precise-memory-info'
to obtain device id:
adb devices
But it wouldn't save flag for the next session, and if you are trying to open it with SeleniumWebDriver probably it should be done with DesiredCapabilities through adding ChromeOptions... but it's still a question how to do it
Currently an Appium 1.7.1 issue.
Follow fix progress here:
https://github.com/appium/appium/issues/9838

Error in using UIAutomatorviewer for testing Android app in Appium

I have to automate an Android application, I am doing the same through Appium.
The problem I am facing is after launching the Appium server, the app is getting installed in the emulator 4.4.2. To inspect the element I am using UIAutomatorviewer which comes default with SDK. But while inspecting the element of the app, I am getting the error:
Error obtaining UI hierarchy
Reason:Error while obtaining UI hierarchy XML file.com.android.ddmlb.SynchException.Remote object doesn't exist.
I tried to find the solution so that I can inspect the element so that I can script, but in vain.
Can someone please tell how to fix the issue so that I can inspect elements?
Is there any other way I can inspect element in the app apart from using UIAutomator viewer?
After my tryst with the uiautomator viewer i came to know that we get the error only when:
appium server is running and we try to capture the screenshot using uiautomatorviewer.
So, whenever you want to use uiautomatorviewer make sure that server is in stopped state.
I fixed the same issue by using following methods.
(1) Connect your Android device to your development machines;
(2) Go to command line in terminal or DOS command line for Windows;
(3) Using "adb shell" into your Android devices;
(4) Change the user to root by input "su root" in command line;
(5) Change the access right to /data/local/tmp by input "chmod 777 /data/local/tmp";
(6) Go back to uiautomatorviewer and do screen shot again, the error should be gone;
I guess there are some file can't be access if it doesn't own right in /data/local/tmp.
Make sure everything on your screen is static. And flashing input cursor is also not allowed. Any painting actions will stop uiautomator from dumping current UI.
You can test by using following adb command:
adb shell uiautomator dump /data/local/tmp/uidump.xml
if the message ERROR: could not get idle state. appears, you are suffering from this issue.
See lines 87 & 101 of DumpCommand:
try {
...
uiAutomation.waitForIdle(1000, 1000 * 10);
...
} catch (TimeoutException re) {
System.err.println("ERROR: could not get idle state.");
return;
}
Easiest solution..
Restart the device. Restart uiautomatorviewer.
Worked like a charm for me .... :P
Stop the Appium Server. Then try again. It works.
I had the same problem because I used "adbd insecure". So I just disabled "adbd insecure", and reload uiautomatorviewer, everything is OK.
In case of rooted devices: Enable the root access in developer options for adb. Restart adb as root
I have spent over a week to resolve this issue. When you connect your device and using ASM 3.0, when screen is projected open the UIAutomator to capture the current android screen. Without Appium it should capture. For use Android Studio instead of android sdk. Uninstall and reinstall Android Studio. It is working perfect for me now.
Answer to your question #2
You can inspect Android app directly from your real Android device.
You need to:
Connect Android device to your computer/laptop
Go to Android device Settings -> Enable Developer Options and Android debbuging
Please see here:
Start the app you wish to inspect in your Android device
Open up the Chrome browser on your computer/laptop and do a right click -> More Tools -> Inspect devices -> Click on your device -> (Click on Android device OK to authorize) -> Click Inspect
Please see here:
That's it. Hope it helps!
I got also the same issue (Also if Appium Server was not running). After switch, OFF / ON USB-Debugging was working for me.
I got it resolved
I closed the Appium Server running on my machine and opened it again.
Later open uiautomater, and it worked for me
The one that works is in this path:
Android/Sdk/tools/bin/uiautomatorviewer
Paste this in your terminal and it will run automator that works
we have to use device which has API level morethan 17 or jelly bean
Way to bypass the ERROR:
could not get idle state.
By using uiautomator to get uix and screenshot.
public class DeviceMethods extends UiAutomatorTestCase {
public void dump(){
try {
getUiDevice().dumpWindowHierarchy("window_dump.uix") ;
getUiDevice().takeScreenshot(new File("/data/local/tmp/window_dump.png"));
} catch (Exception e) {
}
}
you need to create the uiautomator jar and push it to /data/local/tmp
use this tutorial on how to use uiautomator
after you get the files just open them in uiautomatorviewer
What worked for me:
stop appium
open an emulator device (tested with Android 7.1.1)
go into settings > developer options > Enable view attribute inspection
open a shell on the computer, cmd or terminal depending on your OS
enter the following commands:
adb shell
su
cd /data
cd /local
chmod 777 tmp
start uiautomatorviewer
take an xml screenshot
"su chmod 777 /data/local/tmp" didnt work for me so I drilled down and it worked. I assume that you have to do this in an emulator and not a physical device unless the device is rooted. ¯ \ _ (ツ)_/¯
Lotsa Luck!
This happens because adb is using port and it's blocked by appium server.
I have found out best solution for this
Kill the adb.exe from taskbar processes and try launching uiautomatorviewer again
Check whether you have enabled these under "developer options" in the phone.
Verify apps via USB
View attribute inspection
USB debugging
1) stop appium Server
2) open an emulator device
3) go into settings > developer options > Enable view attribute inspection
4) developer options in invisible? Go into settings > Tap on About device/phone > Scroll down till the last option(Build number) > Continuously Tap on "Build number" for 7 times > you should get an Toast message "You're a developer" > come back from that screen > Go back into settings > Now you should see developer options Tap on it > Enable view attribute inspection
5) You should no more get this error message
Why don't you use appium inspector instead? You can download it and follow instructions from here
try switching Off and then ON the USB debugging option.. this work for me

console.log not working in phonegap when built for ios (plugin is installed)

I'm pulling my hair out on this one. I'm using phonegap 3.4 to build an iOS app. When I build the project and run in the simulator, I want to view the output of console.log in the xcode debug window, but it's not working. I've installed the org.apache.cordova.console plugin, but no luck. I see some normal debug output like "Resetting plugins due to page load" but none of my console.logs appear. Any ideas?
And this did not solve my issue: console.log is not working in iOS Phonegap App even after adding the console plugin
try alert();
it is basically the same as console.log();
but you need to install different plugins: org.apache.cordova.dialogs
i dont have iphone nor mac so i can't guarantee it will work on them. But in one android device that i tried, when the console.log() fails. Alert() succeeds.
There are 2 types of alert:
alert('text'); //this is actually javascript
navigator.notification.alert(message, alertCallback, [title], [buttonName]) //this is phonegap function
In my case. i have only need to use the first one.
further documentation on the second alert function is below:
https://cordova.apache.org/docs/en/3.0.0/cordova_notification_notification.md.html#notification.alert
i hope it will work on xcode too.
Make sure you install the console plugin. While Android is able to do this out of the box, logging to console is otherwise not supported on iOS:
https://github.com/apache/cordova-plugin-console/blob/master/doc/index.md
The solution is: call logger.__onDeviceReady function from your deviceready listener function:
function onDeviceReady() {
if (window.cordova.logger) {
window.cordova.logger.__onDeviceReady();
}
}
document.addEventListener('deviceready', onDeviceReady, false);
Try to use "document.write" instead.

PhoneGap + Sencha2 screen blank

I've started a project in PhoneGap which will utilise Sencha Touch 2.
I tried to change the app name from 'app', since I've heard that conflicts with PhoneGap on Android devices. I altered app.js to main.js and that worked, but then I tried changing the Ext.application.name. All I got was a white screen after the loading splash, even with the old name Sencha. Debug console shows nothing at all happening, and the document <body> was empty. This happens with both sencha-touch-all.js and sencha-touch-all-debug.js. Test device is an iPad 1G running iOS 4.3.5.
Aside: To debug this issue, I set up weinre on my Mac and added the appropriate <script> tag to index.html. After making that change, though, the app didn't even launch. It hung on the PhoneGap splash png and I got this message from gdb-remote:
error: failed to launch '<app URI>' -- failed to send the qLaunchSuccess packet
The only reference to that message besides its definition in gdb-remote source that I can find is here, and it's unrelated. I managed to get the issue to go away by restarting the iPad and removing build intermediates.
SOLVED: The issue here was a missing value in the Ext.application definition (key with no associated value), so the whole app definition probably tanked as a result of that. Hence blank screen.

Resources