thanks for the info! did you find that helped with that error? also is this supposed to go into applicationChildElements? or maybe manifestChildElements? I dont know enough about it to know…
What i do know know for some of our apps to do tools:node=“Remove” for a user permission AD_ID we had to put it in manifestChildElements
The metric of Android Vitals still does not show me information about that bundle that I have recently uploaded. I will have to wait a little longer.
Yeah understood, each update takes a good few days to see data start pouring through. Quite frustrating…
Did you ask @vlads if this should be in applicationChildElements or manifestChildElements ?
He told me that it should be in applicationChildElements
1 Like
No need for sharing the apk.
You can scan the results yourself using the veridex tool to see if any APIs are abandoned.
If you want, you can share a list of those abandoned APIs.
Can you share the 40.aab's Crashes/ANRs list?
It should be easy to see which components are associated with those Crashes/ANRs, but its hard to reproduce and fix without the details.
@orangegstudios has any data come through for you yet regarding removing the android:name=“androidx.startup.InitializationProvider” ? has the crash rate for that particular crash fallen?
I may have found something. see image below…
The only difference between the bottom 2 using 3696 we added the following to our main.lua
local function onSystemEvent( event )
if event.type == "applicationSuspend" or event.type == "applicationExit" then
HideAds() -- This calls a function which hides admob's ads.
end
end
Runtime:addEventListener( "system", onSystemEvent )
and as someone mentioned above we added showRuntimeErrors = false into our config hoping for some sort of miracle. our crash rate is now way down! not sure yet which of the two changes did that… ANRs are still a bit high. Still early data and pushing to more users for more data to come through. but maybe this can help!
Further to the post above i have not seen the crash below in the latest bundle we uploaded we did simply by hiding the banner on app suspend or exit.
**Stack tracking: java.lang.IllegalArgumentException**
Exception java.lang.IllegalArgumentException: parameter must be a descendant of this view
at android.view.ViewGroup.offsetRectBetweenParentAndChild (ViewGroup.java:6305)
at android.view.ViewGroup.offsetDescendantRectToMyCoords (ViewGroup.java:6224)
Again this is still just very early data but the difference in crashes between the latest bundle uploaded and previous is significant.
I already have some android vitals results for this publication which has in builds.settings the inclusion of ""android:name=“androidx.startup.InitializationProvider” and for the moment the exception “java.lang.NullPointerException” does not appear.
I share some test data that I have been doing:
-
I upload an update of one of my apps, compiling with 3696 and completely eliminating “banners”. The previous version compiled with 3685 had a crash rate = 0.94%. This new version with 3696 and without banners now had a crash rate of 2.97%
-
Another test that I did in another app, which after updating it at 3696 the failure rate increase at 22.07%, now i compiled with 3696 but only adding “showruntimeerRors = false” and the failures rate fell to 0.06%
Therefore, at first glance, it seems that “banners” are not the cause of the increase in the failure rate.
Your function “HideAds()” What does it contain, admob.hide()?
In this app, where I eliminated the banners, and the crash rate is 2.97%, the failures are as follows:
Yes it calls the admob.hide() function. We haven’t seen the crash below in our latest build
**Stack tracking: java.lang.IllegalArgumentException**
Exception java.lang.IllegalArgumentException: parameter must be a descendant of this view
at android.view.ViewGroup.offsetRectBetweenParentAndChild (ViewGroup.java:6305)
at android.view.ViewGroup.
But interesting removing banners didn’t make a difference for you.
And even more interesting that the RemoveRuntimeErrors seemed to have brought it down to 0.06 for you. That may explain the big drop for myself as well. I just don’t understand how that could be. As any crash should still technically be there.
Hey!
Information posted on public channels is best desensitized to avoid unnecessary trouble.
I recommand delete this one:
And I’m sorry that I haven’t encountered similar problems, sorry I can’t help you.
I’m confused as to why setting showRuntimeErrors=false in config.lua would make a difference here.
Doesn’t it only affect errors that occur in the simulator? And as SGS said, the error has already occurred regardless of whether the error popup appears to the user or not.
If the root cause of the issue is GP deciding that “any error popup = crash” even when the error could be handled gracefully, it’s possible that adding a runtime error handler listener which always returns false will also solve this problem for you (because that will also stop the error popup from appearing).
That’s fine for lua crashes, but completely useless for java, etc
True, but I would assume the showRuntimeErrors=false flag that people have suggested fixes their crashes is also only applicable to Lua crashes.
I’ve had a look at the Solar2D source, and as far as I can see showRuntimeErrors only affects the simulator. So I’ve no idea how it’s improved crash rates on Android for some people - can only assume it’s a coincidence and that something else just happened to change at the same time (a 3rd party SDK update or something like that).
I agree that the solution is not to hide the errors, because I suppose that although they are not reported they continue to occur. But certainly that parameter affected the metrics.
If they look at this picture, the version 13 rose it compiled with the Build 3696 (without any change of code with respect to version 12) and went from 1.76% to 24.44% crazy!.
Then I just upload the v15 by adding only the “showRuntimeErrors = false” parameter, and the rate dropped drastically to 0.04%
Only that was the change at the code between these versions, so I understand is no coincidence.
Again, I don’t think it’s the solution.
I don’t know what has changed compilation 3692. But certainly the compilations of that version onwards, make the crash rate increase dramatically.
Unless there is some craziness in the latest build you realise this doesn’t make any sense?
showRuntimeErrors = false is the default for non-debug builds. The crashes you are reporting are not runtime errors, they are happening outside your code.
Most likely a plugin was fixed.