Publish debug symbols for nativescript-optimized.aar, not only for nativescript-regular.aar

Offen
#1,982 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
android, cpp

Rechercherichtung

Beginne damit, die Release-Paketierung nachzuverfolgen, die debug-symbols.zip und das optimierte AAR erstellt, und vergleiche anschließend die BuildIDs der regulären und optimierten Artefakte. Die Aufgabe ist abgeschlossen, wenn die Release-Ausgaben Debug-Symbole enthalten, die zur optimierten Laufzeit passen, und die Artefaktbenennung oder die Release Notes den Flavor identifiziert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Is your feature request related to a problem? Please describe.
I'm trying to get native crashes of our app symbolicated. Sentry and Play Console both show only raw offsets inside libNativeScript.so. Every release here ships a debug-symbols.zip, which looked like exactly what I needed, but unless I'm misreading things it doesn't match release builds: the gradle template picks the optimized runtime for release builds, while the published symbols are built from the regular flavor. Since Sentry and Play match symbols strictly by BuildID, the published symbols can only ever apply to debug builds, and production crashes stay unsymbolicated.

Describe the solution you'd like
Publish the unstripped optimized build as well (debug-symbols-optimized.zip or similar, or both flavors in one zip), the same way it's already done for the regular flavor. That would make production native crashes debuggable without any build changes on the app side. It might also be worth mentioning in the release notes which flavor the existing zip corresponds to.

Describe alternatives you've considered

  • Setting "android": { "useV8Symbols": true } so that release builds ship the regular flavor, which the published symbols do match. That works, but it means giving up -O3 and section gc on the runtime glue and shipping the inspector code in production, just to get matching symbols.
  • Building the runtime from source with symbols. Possible, but a lot of infrastructure for something the release pipeline here already produces for the other flavor.
  • Living with unsymbolicated native frames.

Additional context
BuildIDs checked with v9.0.4 on arm64-v8a:

regular (npm AAR):                  BuildID[sha1]=d7c0ab67…, stripped
optimized (npm AAR):                BuildID[sha1]=68bb8632…, stripped
optimized-with-inspector (npm AAR): BuildID[sha1]=d7c0ab67…, stripped
debug-symbols.zip:                  BuildID[sha1]=d7c0ab67…, with debug_info, not stripped

It took me a while with file and readelf to figure out why nothing matched, so hopefully this saves the next person the detour. And if I'm missing something and there is already a way to get matching symbols for the optimized runtime, happy to be corrected.

Vorherrschende Sprache
C++
Sterne
563
Forks
144
Ø Merge
10 Std. 46 Min.
Gemergte PRs (30 T.)
14

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus NativeScript/android

Alle Issues in NativeScript/android

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.