Skip to content

General

General

Categories

JUMP TO ANOTHER FORUM

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

51 results found

  1. Since Android & Wear OS must use the same package name to be able to communicate, we have no way to split apart Android & Wear OS crash reports.
    This is an issue because we use Flutter for the mobile app and Kotlin/Jetpack Compose for the Wear OS app. The two apps share essentially nothing in common except for the package name and we have two separate teams working on them.

    Filtering for device type sounds like it should work, but the we only have phone & tablet in that list even though there's at least one crash guaranteed to…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Crashltyics seems to display thread names for iOS apps, but not for Android. Sorting through Thread #1...50 is not ideal in a complex application. Nearly all our threads are in the NDK, and are just pthreads. The call to obtain the (15+endofstring) thread name is one line of code from the pthread_id.

    This was my original query about adding this support, and has the pthread query.
    https://groups.google.com/g/firebase-talk/c/cIRb75V5Jxw

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. What happened to us was Crashlytics decided to group only loosely related crashes, same uncaught Objective-C exception in the title field but totally different error message and root cause (displayed as subtitle).

    But now we have fixed the original first issue, and the remaining crashes have a different message than the one that still appears in the subtitle field on Crashlytics dashboard, which causes confusion each time a new developer takes a look at the open crashes ("didn't we fix this one already?") before realising it's now a different issue.

    It would be great if we could at least choose…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. When pressing "Filter crashes" on the info banner about the latest release, the time selection also silently changes from "Last 7 days" to "Last 24 hours".

    It would be easier to compare between all crashes and crashes from the latest release if the time span didn't change unasked like that.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. The log event parameters appear in a random order, changing from event to event, crash to crash, making it hard to search and find the parameter of interest. It would be nice if the parameters would be sorted by key, so the one of interest would be easy to find.

    (Maybe the order is whatever happened to be serialised in the original crash report. But since it was attached as an unordered Dictionary<String, Any> via the FirebaseAnalytics API, there's no way to control the order in which they appear in crash logs.)

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. nativePollOnce should be excluded from ANR in Firebase

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. Translation: It is recommended that firebase add native crash and java crash filtering to facilitate checking the crash-free rate of native and java crash, and also to facilitate timely discovery of some problems.

    Original: 建议 firebase 加上 native crash 与 java crash 的过滤,便于查看 native 与 java crash 的 crash-free 率,也便于及时发现一些问题

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. Currently, Crashlytics only supports Bug issue type with Jira Integration. It would be helpful if it allowed other issue types, such as post-production issues.

    This solution allows users to integrate with their organization's Jira issue-type standards, including Pre-production, Post-production, and Defects, instead of relying solely on the issuetype "bug".

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. Recently I find that we can only check the recent four days' crash data even I select 'past 30 days', is there anything wrong? or why we are not allowed to check historical crash data?

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. I need crashlytics to track crashes of my SDK not the crashes of the app which is implementing my SDK

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. This can be either done by directly adding the filter option to the graphs above, or by a toggle which applies filters from the list to the graphs. (not by default, to prevent confusion/regression from current behaviour)

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
1 3 Next →
  • Don't see your idea?