Update AndroidManifest.xml

[gsfare]

Disable automatic initialisation for all components and dependencies otherwise the following exception is generated during application start-up.

java.lang.RuntimeException: Unable to get provider androidx.startup.InitializationProvider

[DanAlbert]

Apologies for the (very) delayed response. There hasn't really been anyone able to look after this repo for a while.

You're right that this does fix the problem, but could you help me understand why? Sorry for the stupid questions ahead, but I'm not an app developer. Given that these are samples that everyone's going to be copy pasting from, I need to make sure that this is the best fix. I'm a bit confused because a new project created from Android Studio does not include this, but also does not crash. https://developer.android.com/topic/libraries/app-startup seems to imply it's an optional feature of JetPack, but this sample doesn't use that library. It does use the android.app-compat library, but it doesn't use androidx.startup, afaict. It looks to me a lot like there's something else that's wrong, and while this PR definitely makes the problem go away, it may not be the right fix.

[DanAlbert]

#903 is what did it. That commit shows the problem, the one before does not. Why is still an excellent question, and the changelogs aren't helping.

[DanAlbert]

I found https://issuetracker.google.com/209387755, where other people have reported the same issue in other applications. I'm really not clear on why this sample needs it, but a freshly generated app (using Studio's Game Activity or Native C++ templates) doesn't.

[DanAlbert]

Actually, the problem also goes away if we remove the dependencies on androidx, neither of which appear to be used. I'd like to dig into why those are here before ripping them out, but it may just be copy pasta.

[DanAlbert]

I'm not all that familiar with the appcompat library, but https://developer.android.com/jetpack/androidx/releases/appcompat says it's the backport library, which I could see being useful even in a NativeActivity app, so it's probably worth preserving? I can't find any additional documentation on its requirements aside from the gradle dependencies bit on that page though...

[heyoukang]

@DanAlbert hi DanAlbert , this pr #997 fix #929
and explain why, Can you help me merge this pr?

[gsfare]

Hi Dan, no apologies are necessary, it looks like you've made some helpful progress in narrowing down the underlying cause for this. I'm on business travel right now but I'll try to take a look and see what's happening there between the commits you reference in #903. It may require a little reversing but I'll see if I can discover anything to provide some extra insight.

[DanAlbert]

@DanAlbert hi DanAlbert , this pr #997 fix #929 and explain why, Can you help me merge this pr?

Thanks, I'm slowly working through things in order and hadn't made it that far yet :) I'll respond on the various threads in a few.

[DanAlbert]

I'd actually figured out the same thing you did: appcompat is totally unnecessary here. I'm pretty tempted to just remove it from the sample. I'd tried the hasCode thing yesterday as well and it did not fix it for me. Wondering if I hadn't rebuilt correctly on that test now...

The docs for hasCode aren't great: http://go/android-dev/guide/topics/manifest/application-element#code. I'm inclined to believe that true is correct here, but based on the existing sample I think the hasCode docs should say "Whether the application has any Java/Kotlin code." (the wording is messy, but not-native, basically). I'll see if I can find someone to ask about that.

[DanAlbert]

I'd tried the hasCode thing yesterday as well and it did not fix it for me. Wondering if I hadn't rebuilt correctly on that test now...

Yeah, just retested this and it does work. Not sure what I did wrong yesterday.

[DanAlbert]

As explained in #929, I think #1000 is the more correct fix. Will close this in favor of that. Thanks for the patience while I figured stuff out 👍