ANRs from com.evernote.android.job.JobBootReceiver

mateot1 commented 3 years ago

We have many (100+) reports of ANRs from the Google Play Console coming from com.evernote.android.job.JobBootReceiver when receiving Intents with the action android.intent.action.BOOT_COMPLETED. We do not directly use this library and Cloudinary seems to be the only source of the transitive dependency. We're a couple versions behind (1.27.0), but don't think there's been any evernote job changes in recent releases.

The stack traces in these reports seem to be related to initialization we're doing unrelated to Cloudinary, so my question is - when does this happen in the sdk and is there anything we can do about it? Or is it simply a red herring/side effect that the report is coming from this receiver?

Issue Type (Can be multiple)

[ ] Build - Can’t install or import the SDK [x] Performance - Performance issues [ ] Behaviour - Functions aren’t working as expected (Such as generate URL) [ ] Documentation - Inconsistency between the docs and behaviour [ ] Other (Specify)

Build System

[ ] Maven [x] Gradle [ ] Other (Specify)

Is the issue reproducible only on a specific device?

[x] No [ ] Yes (specify model + Android version + vendor build number, if applicable)

michalkcloudinay commented 3 years ago

@mateot1 In order to further investigate can you please provide more details?

What’s the variance of the errors across the device, and what’s the percentage of errors (e.g. are they in the millions?)
Can you please provide a full stack trace of the error?
Are you running the code in a boot-complete event? If privacy is a concern you can open a support ticket to support@cloudinary.com.

mateot1 commented 3 years ago

After further investigation I am thinking this is just a coincidence of these things all happening at app start.

There are 15 or so different errors being reported, most are shown happening in com.evernote.android.job.JobBootReceiver, however there are a couple that happen in google's JobInfoSchedulerService and one happening from a different library's broadcast receiver
We are not directly running any code in a boot-complete event, which is why this was so confusing to me.
All of the stack traces seem to have to do with initializing EncryptedSharedPreferences from androidx.security.crypto which we updated in our latest release, so perhaps I'll open an issue with them instead...

michalkcloudinay commented 3 years ago

@mateot1 Thanks for the update. please let us know if there is anything we can assist with.

mateot1 commented 3 years ago

Closing this as it turned out to be unrelated to this evernote receiver. Thanks

cloudinary / cloudinary_android