Jugg Wiki

English

简体中文

English

简体中文

Appearance

Report an issue ​

Report an issue packages the current Jugg logs and device error logs, then uploads them to an issue-reporting service. Use it when incremental compilation or deployment fails, or when runtime results are unexpected. Manual reports prefer the currently available Jugg backend and use Jugg's public service when no backend is available.

A team backend can also enable automatic failure-log uploads. Automatic uploads go only to the currently available backend, omit adb logcat, and do not show a confirmation window.

IMPORTANT

Public packages from GitHub Releases and JetBrains Marketplace do not bundle a Jugg backend server list. Without a configured Custom Server, issue reporting does not upload any data by default. It connects to the public service and submits a redacted bundle only when the user explicitly selects Upload logs in the report window; saving locally does not upload anything. “Automatically selected backend” below refers only to an internal build that bundles a server list. If the user configures a Custom Server in a public package, reports can send original logs to that backend, and its configuration may enable automatic failure-log uploads.

Where to open it ​

Use either of these entry points:

  • Press Shift twice in Android Studio, then search for and select Report Jugg Issue.
  • Open Jugg Running Panel and click Report Issue.

You can also open it from a Jugg Run Configuration:

  1. Open Edit Configurations....
  2. Select the current Jugg configuration.
  3. Click Report issues.

When no backend service is available, after the report window opens:

  1. Review and select the diagnostic files. Jugg logs are selected by default and cannot be cleared. Project snapshots are selected by default but can be cleared.
  2. Select Upload logs, or select Save locally without uploading to create a local diagnostic bundle.
  3. After the upload finishes, copy the Report ID. If the upload fails, click Retry Upload, or give the retained ZIP file to the maintainer.

The confirmation window shows the public upload address https://jugg.sickworm.com/report_issue. When saving locally, the system file manager selects the newly generated ZIP file.

When a backend service is available, clicking the report entry skips the file and destination confirmation window. Jugg uploads the previously default-selected diagnostic content directly to that server's /report_issue. You cannot clear project snapshots or choose local-only saving in this flow. Backend uploads allow HTTP or HTTPS; HTTP does not protect the content with TLS. An invalid destination or failed upload is not forwarded to the public service. The result window still lets you retry the same destination. Whether the upload succeeds or fails, click Save to local in the result window to open the containing folder and select the ZIP used for this upload. This ZIP matches the upload bundle and retains the original logs in backend reports. The result window stays open so you can continue copying the result or retry a failed upload.

After a successful upload, the result window shows an 8-character lowercase hexadecimal Report ID. Send it to the maintainer together with the reproduction steps. A copied backend result also has a Server Url line identifying the server that was used.

What is uploaded ​

The uploaded content is intended to diagnose the current Jugg behavior:

  • Jugg compilation and deployment logs.
  • A structured environment and project summary.
  • Cancelable IDE, Gradle, and included-build project snapshots that are selected by default.
  • Cancelable error logcat for the target device.
  • Optional hook debug logs.
  • A manifest.json describing the actual ZIP entries.

Project snapshots include the existing project_infos.json and gradle_project_infos.json files, plus the include_build_*_gradle_project_infos.json files for current included builds. Redacted copies are stored under diagnostics/project-info/ in the bundle. Diagnostic information such as applicationId and whether a field exists is preserved. Signing credentials, keystores, key aliases, Manifest placeholders, APT/KAPT arguments, and common sensitive field values are replaced. Snapshots that cannot be parsed, stale included-build snapshots, other files from project_infos.db, source code, and binary dependencies are not included. Hook debug logs are stored as diagnostics/cli/hook-debug.log.

Manual uploads to either an explicitly configured Custom Server or a backend selected from an internal build's bundled server list send the project name and developer username as separate fields for backend classification. The public service receives only the bundle. Manual reports are not marked as automatic uploads. Both kinds of backend also receive original Jugg logs, device logcat, and hook debug logs, which may contain project paths, usernames, and other sensitive content. Only uploads to the public service when no backend is available, and locally saved bundles, redact these logs. Sensitive fields in project snapshots are always redacted. The manifest marks original logs as redaction: none. Send reports only to trusted backends; HTTP transport is not encrypted.

NOTE

Upload failure does not change the local compilation or deployment result. The temporary ZIP remains under build/jugg/tmp/diagnostics and can be uploaded again; backend reports also retain their original logs here. A cleanup task deletes it after project startup once it reaches 7 days old. Uploads do not follow redirects or fall back from a backend to the public service.

Automatic failure-log uploads ​

A team backend can distribute autoUploadFailureLogs=true so Jugg automatically uploads the two most recent logs after a final compilation failure or an actual deployment failure. User cancellation, skipped deployment, no device before deployment starts, and a successful final result after a Gradle fallback do not trigger an automatic upload. Each Run uploads at most once.

The automatic bundle contains the two most recent real Jugg logs, environment information, a project summary, redacted project snapshots, the hook debug log when present, and the manifest. It does not collect adb logcat. Logs follow the destination-specific rules described above. The backend can also use autoUploadFailureLogsExcludeRegex to exclude known errors. When the regex matches the current Run's final error summary, Jugg does not upload. An empty regex applies no filtering, while an invalid regex skips that upload.

An automatic upload includes an automatic-upload marker, a failure summary, and any available detailed error alongside the bundle. It also sends the project name, developer username, plugin version, and Report ID. Any available backend, including one selected from an internal build's bundled list, receives the original error text. Manual reports do not include the automatic-upload marker and remain manual reports.

Automatic uploads run asynchronously without a dialog or retry. An upload failure does not change the original compilation or deployment result. Only an available backend receives them at /report_issue (HTTP or HTTPS); without one, the upload is skipped and never sent to the public service.

Local log location ​

If uploading is temporarily unavailable, inspect the latest log first:

bash
~/.jugg/log/<projectName>_<pathHash>/compile_latest.log

This file contains the main log for the most recent compilation and deployment. It is usually the first place to check deployment, fallback, and runtime problems.