Skip to content

General

General

Categories

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

46 results found

  1. 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)
  2. 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)
  3. 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)
  4. 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…

    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. 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)
  6. 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?