ANRs from com.evernote.android.job.JobBootReceiver
mateot1 opened this issue · 4 comments
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)
@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.
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'sJobInfoSchedulerService
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
fromandroidx.security.crypto
which we updated in our latest release, so perhaps I'll open an issue with them instead...
@mateot1 Thanks for the update. please let us know if there is anything we can assist with.
Closing this as it turned out to be unrelated to this evernote receiver. Thanks