Status Update
Comments
vi...@google.com <vi...@google.com> #2
pa...@gmail.com <pa...@gmail.com> #3
Due to the pattern I am noticing when researching the other reports of this bug, I have a feeling this ticket will be closed as "Won't Fix (Obsolete)" when it clearly is not. I can confirm that this issue exists in Android 10, so unless Android 10 is obsolete, and this issue is not reproducible in the current Android versions, I would hope to see this get fixed before the Android 11 release.
Tickets reporting this issue but closed:
ub...@gmail.com <ub...@gmail.com> #4
This also very likely affects the new ContentProviders
.
Given those (Firebase, Jetpack App Startup) are official Google products I am wondering whether this means that Android Backup will be sunsetted soon or otherwise would need extensive changes to its implementation (which would likely be hard to roll out to older devices as AFAIK it's shipped with the OS). Would be great to get some official statement here so that we have enough time to migrate away our apps from Android Backup to some other backup service.
pa...@gmail.com <pa...@gmail.com> #5
It's been a bit over a year since I reported this issue, and I have a feeling that it hasn't been resolved in Android 12. Nudging this ticket a bit to hopefully get some eyes on this, especially since Hilt seems to require the Application
class to be extended.
vi...@google.com <vi...@google.com> #6
[Deleted User] <[Deleted User]> #7
Awesome! Can you link the commit for the fix? Thank you.
pu...@gmail.com <pu...@gmail.com> #8
If you want to work-around this issue in case user is starting the Main Activity to your app while it is in restricted mode thus will crash at some point, you can do this in your startup Activity to force kill the process so it starts next time in non-restricted mode:
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if(!(getApplication() instanceof MyCoolApplicationSubClass)) {
// app is in restricted mode, kill it
new Handler().post(() -> System.exit(0));
finish();
return ;
}
// else start normally
}
[Deleted User] <[Deleted User]> #9
cp...@pluto.tv <cp...@pluto.tv> #10
va...@gmail.com <va...@gmail.com> #11
da...@google.com <da...@google.com>
sa...@google.com <sa...@google.com> #12
A fix for apps restarting in restricted mode if they crash during backup was merged in T. Folks still reporting this issue in T+ Android versions, can you confirm if you are seeing your app being restarted in restricted mode, preventing users from using the app?
vi...@google.com <vi...@google.com> #13
Please share the information requested in
su...@gmail.com <su...@gmail.com> #14
We've observed similar crash reports in play console only on T+:
android:allowBackup="true"
in application manifest- A custom application class, initializing some global static instances on created
- MainActivity tries to access these global instances on created, assuming they've already been initialized, leading to a crash
Regarding specific data by OEM/device, this crash commonly occurs on T+, including Google Pixel. HONOR devices seem to be more prone to this issue, but users from other OEMs (Samsung, OPPO) reported a higher frequency (>5 events per user)
Description
To detail the problem, when Android starts an app for the Auto Backup, it is placed in a "Restricted" mode as per the documentation here:https://developer.android.com/guide/topics/data/autobackup#ImplementingBackupAgent . This forces the app to start without any
ContentProviders
that are declared in the manifest, and forces the App to use the vanillaApplication
class instead of the declared one in the manifest.The problem is that this "Restricted" mode does not prevent
Service
orBroadcastReceiver
classes from starting, some of which are exported and started by external sources (ie. Firebase). This can be detrimental if certain libraries are expected to be loaded in theApplication
orContentProvider
. This can potentially cause app crashes, and while in this "Restricted" mode, if the app crashes, the flag for this mode is kept. So this would mean a user initiated app launch would start in this "Restricted" mode, which would launch the App without any declaredContentProvider
orApplication
classes loaded, thus potentially causing another crash, which would maintain the "Restricted" flag, and repeat the cycle ofterrorcrashes.This was first reported as a Firebase issue (https://github.com/firebase/firebase-android-sdk/issues/1456 ), but this seems more like a platform problem.
To sum up the problems:
Application
andContentProvider
classes from starting (expected), but does not preventService
orBroadcastReceiver
from receiving intents (unexpected)leading a particular Android dev into the depths of madnessmaking troubleshooting difficult.Number of beers consumed while troubleshooting this bug: ~17