From kde-core-devel Mon Apr 26 15:47:58 2021 From: Martin Klapetek Date: Mon, 26 Apr 2021 15:47:58 +0000 To: kde-core-devel Subject: Re: Is there (going to be) an auto-retracer service for KDE? Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=161945212828906 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--000000000000712d9e05c0e213af" --000000000000712d9e05c0e213af Content-Type: text/plain; charset="UTF-8" On Mon, Apr 26, 2021 at 7:07 AM Harald Sitter wrote: > > Also going off on a tangent: On windows I understand the store already > has crash tracking and all that stuff implemented, I expect the same > is true for OSX? No idea about android Just chiming in about Android - if an app is installed from Play Store, the store itself will collect crash traces, both Java and native ones. However those traces will have the same issue - they won't have the debug stuff for native ones; they will for Java crashes unless the code has been obfuscated in the release build, which is actually very common. To deobfuscate those traces, the debug symbols can be uploaded to the Play Store (or the mapping file in case of Java), but it's a manual process which must be done for every single release. There are also alternatives to Play Store's traces collecting - there are many SDKs that can be integrated into the app code that will collect all crashes and upload them to a web service (basically a DrKonqi equivalent...maybe DrKonqi could be turned into Android framework for crash reporting?), but then the same debug symbols issue will exist there. Some of these SDKs also provide a simple gradle task (build system step) that will auto-upload those debug symbols to their web service as part of the release build, sorta automating that process. But these are generally closed/paid 3rd party services, so not entirely useful for KDE. There may be open alternatives, but I haven't really looked into that. Finally, setting these up is usually a single line in the (Android) App's onCreate(), so this could potentially work with Qt apps on Android too. Cheers -- Martin Klapetek --000000000000712d9e05c0e213af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 26, 2021 at 7:07 AM Harald Si= tter <sitter@kde.org> wrote:

Also going off on a tangent: On windows I understand the store already
has crash tracking and all that stuff implemented, I expect the same
is true for OSX? No idea about android

Just= chiming in about Android - if an app is installed from Play Store,
the store itself will collect crash traces, both Java and native ones.
However those traces will have the same issue - they won't hav= e
the debug stuff for native ones; they will for Java crashes unl= ess
the code has been obfuscated in the release build, which is a= ctually
very common. To deobfuscate those traces, the debug symbo= ls can
be uploaded to the Play Store (or the mapping file in case= of Java),
but it's a manual process which must be done for e= very single release.

There are also alternatives t= o Play Store's traces collecting - there are
many SDKs that c= an be integrated into the app code that will collect
all crashes = and upload them to a web service (basically a DrKonqi
equivalent.= ..maybe DrKonqi could be turned into Android framework
for crash = reporting?), but then the same debug symbols issue will exist
the= re. Some of these SDKs also provide a simple gradle task (build
s= ystem step) that will auto-upload those debug symbols to their web
service as part of the release build, sorta automating that process.
But these are generally closed/paid 3rd party services, so not entire= ly
useful for KDE. There may be open alternatives, but I haven= 9;t really
looked into that.
Finally, setting these up = is usually a single line in the (Android) App's onCreate(),
s= o this could potentially work with Qt apps on Android too.

Cheers
--
Martin Klapetek
--000000000000712d9e05c0e213af--