sentry-demos / android Goto Github PK

Logcat integration automatically creates breadcrumbs for your android.util.Log.* calls.

Docs reference: https://docs.sentry.io/platforms/android/configuration/integrations/logcat

Increase product_processing span duration to make a more obvious/compelling span to inspect, minimum 3s. Currently it is approx 1s.

Startup Profiling (Startup Profiling 1 - Decouple Profiler from Transaction #3101, Startup Profiling 2 - Add options and sampling logic #3121, and Startup Profiling 3 - Add ContentProvider and start profile #3128) from the Sentry SDK allows Sentry to track activity before the SDK starts.

This can be useful for cases where a library loads when application starts, but the configuration is slow, or you don’t need the library anymore. This can also highlight other slow functions that happens before SDK starts.

Add a custom metric as an example (docs ref)

Docs reference: https://docs.sentry.io/product/issues/issue-details/performance-issues/regex-main-thread/

1. Move TTFD to after product_processing
2. Increase product_processing span duration to ~3s
   

Create customerType custom tag, similar to reference React demo's (see following screenshots), which have: small-plan, medium-plan, large-plan, enterprise (ref code)

Currently its the android-robot icon. let's change it to https://github.com/sentry-demos/empower/blob/master/react/public/logo192.png

Tasklist to showcase Sentry's Android SDK functionality

• #60
• #61
• #65
• #67
• #68
• #69
• #70
• #71
• #72
• #74
• #66

Running the app locally can cause slower performance. The slower performance can hit unintended deadlines. E.g. there is a hard deadline (of 30s) when capturing profiles.

Reducing time of mock functions to avoid deadline(s) will allow for testing/validating the app locally.

Note: This is not a problem when generating events via pytests (i.e. https://github.com/sentry-demos/empower/blob/master/tda/mobile_native/android/test_checkout_android.py generates EmpowerPlantActivity transactions of ~25s).

Enable Time To Full Display as described in https://docs.sentry.io/platforms/android/performance/instrumentation/automatic-instrumentation/#time-to-full-display, enabling with io.sentry.traces.time-to-full-display.enable and finish manually with Sentry.reportFullyDisplayed();:

Time to full display is dependent on having an active transaction bound to the scope. Ideally, it should be used along with Activity Instrumentation, which starts a transaction and binds it to the scope automatically.

Add Sentry.reportFullyDisplayed(); to the appropriate line such that we can see TTFD data in the Screens page.

Context: Mobile Screens was recently released getsentry/sentry#60127. TTID & TTFD data are available to showcase on Sentry, but requires configuration from the SDK as described in this GitHub Issue.

The DB on Main Thread Performance Issue is not appearing consistently. Over the past 7 days of automation data (discover query), we see 29 DB on Main Thread Performance Issues.

The DB on Main Thread Performance Issue appears on average once every 5.8 hrs.

The DB on Main Thread Performance Issue should appear more frequently.

Docs reference: https://docs.sentry.io/product/issues/issue-details/performance-issues/image-decoding-main-thread/

Environment:
macOS 11.4
Android Studio 4.2.2

Build failed for release configuration with error

Execution failed for task ':app:uploadSentryProguardMappingsRelease'.
> Process 'command '/var/folders/cq/fcg17v_x56z5lr5yzgwlvpm00000gp/T/.sentry-cli9070864541215928418.exe'' finished with non-zero exit value 1

Problem for branch perf-issues-db_main_thread-np1_api (at this commit):
Unable to make synchronous API calls to create N+1 API Calls performance issue. I've made two unsuccessful attempts: [1], [2].

Goal:
Create a transaction to match this reference React /nplusone transaction, which generates this N+1 API Call performance issue.
The attempts so far have been by using this button to trigger the API calls:

Right now we are using MainFragment$ItemDeliveryProcessException
TBD what will be standard name for flagship exception across all platforms?
Please comment what you would use for a backend API exception in a real Android app according to Android conventions and common practices?
For now can use BackendAPIException - better than current

Update: Karl mentioned that on mobile platforms exceptions names can be idiomatic and specific to platform. Let's find some middle ground to make it recognizable for SE while looking "normal" for the platform

Docs reference: https://docs.sentry.io/product/issues/issue-details/performance-issues/json-decoding-main-thread/

Standardize sentry-demos apps Profile data such that they matches the flask example, which uses get_iterator. It demonstrates Color Coding > By Recursion as follows:

src

Currently, all Application Frames for the flagship profile span product_processing have the same duration and does not demonstrate a Color Coding > By Recursion example.

src

Requirements

1. Replace function of product_processing span to have frame name get_iterator
2. Make get_iterator function recursive, with variety in frame duration as shown in the flask/python reference

Existing PR: #59
seems to have regressed with source code context
Transaction not tested (wasn't sure which one is flagship) - checkout [something]???

Create GitHub release workflow like what was set up for sentry-demos/ios:
https://github.com/sentry-demos/ios/actions/workflows/release.yml > Run workflow, see screenshot

Context:

1. https://github.com/sentry-demos/ios/blob/master/.github/workflows/release.yml
2. https://github.com/sentry-demos/ios/actions
3. https://github.com/sentry-demos/ios/issues?q=ci%3A

User Feedback was working up until approx 11 days ago (Jan 11 2024). Reference Issue with User Feedback.

Codecov reports should be consistently generated for every change in main.

Codecov highlighting is appearing on the stack trace in Sentry, but there is no associated Codecov report:

Enable Automatic Instrumentation > User Interaction Instrumentation to avoid needing to manually instrument the checkout [android] transaction with ITransaction checkoutTransaction (ref: app/src/main/java/com/example/vu/android/empowerplant/MainFragment.java):

    public void checkout() {
        selectedStoreItems = this.adapter.getSelectedStoreItems();
        ITransaction checkoutTransaction = Sentry.startTransaction("checkout [android]", "http.client");
        checkoutTransaction.setOperation("http");
        Sentry.configureScope(scope -> scope.setTransaction(checkoutTransaction));

This presumes that the click on the checkout button begins a transaction as per the docs:

The UI instrumentation, once enabled, captures transactions for a set of different user interactions, which include clicks, scrolls, and swipes.

The transaction generated by the User Interaction Instrumentation should be comparable to the manually generated checkout [android] transaction, which includes a trace of 2 transactions and 3 issues, each of which should not be regressed. This transaction and its associated events are a way to demonstrate Distributed Tracing.

Android 3.1 Demo alerts (sent to #demo3-android) stopped appearing in early March. Formerly, notifications appeared when running the Android 3.1 Demo locally (Android Studio > Devices with the sentry-demos/android app to generate a checkout error).

Update Alerts
https://sentry.io/organizations/demo/alerts/rules/android/14467381/details/ and https://sentry.io/organizations/demo/alerts/rules/android/14754732/details/ so Slack notifications once again trigger on non-automated data.

Update https://github.com/sentry-demos/android/blob/main/README.md; it is out of date.

Problem for branch perf-issues-db_main_thread at this commit:
The checkout [android] transaction has span http.client.connection, which is incorrectly associated with SentryHttpClientException: HTTP Client Error with status code: 500 error. The span’s Status is deadline_exceeded, but this is not accurate. The error should not be due to the http client connection nor deadline--it is due to an associated backend error.

Expected Behavior:
Error should to match with current checkout [android], where it has an http.client span with associated error SentryHttpClientException: HTTP Client Error with status code: 500. The span’s Status is internal_error.

If you use auto-formatter in your team's codebase and have enabled in IDE please feel free to first auto-format entire codebase so that subsequent commits are not cluttered with whitespace changes, etc.

Docs reference: https://docs.sentry.io/platforms/android/profiling/

Profiling is enabled.
Set up a function for a problem to solve.

Suspect Commit are not appearing on the flagship error (tda-generated, locally generated)

However, they were consistently appearing in tda-generated events and from a local run (event).

What is preventing Suspect Commit from consistently/reliably appearing?

Improve presented device.class https://docs.sentry.io/product/reference/search/searchable-properties/#device-classification data, which is displayed in a widget in Mobile > Screen Summary.

Mock data so Time To Initial Display and Time To Full Display are different, and different between releases.

Ensure TTFD is slower than TTID (currently they’re the same).

Create a span operation which has a delay that can be inspected (Performance > Mobile > Screen > the Operation table shows span operations to inspect). The delay may be dependent on build.gradle versionCode such that there are differences between (the two latest) releases.

Flagship transaction EmpowerPlantActivity to consistently show CPU Usage and Memory graph:

Note: CPU Usage and Memory are sent as part of profile envelopes, so if there's no corresponding profile for a transaction (can use has:profile.id filter), then these graphs won't be shown up.

Use pytest to click Performance Issue Buttons: