Ti.Platform.displayCaps throwing error on getWindowManager()

[jordanbisato]

I have searched and made sure there are no existing issues for the issue I am filing

• I have searched the existing issues

Description

I was looking at my crashlytics reports and found some error on displayCaps in some devices.
It mainly happens on Motorola and some Samsung Galaxy J family.

The error on Crashlytics:

Non-fatal Exception: java.lang.Throwable
       at /alloy/controllers/login.js.Uncaught Error: Attempt to invoke virtual method 'android.view.WindowManager android.app.Activity.getWindowManager()' on a null object reference($.vLabel.top="4.5%"):Ti.Platform.Android.physicalSizeCategory==Ti.Platform.Android.PHYSICAL_SIZE_CATEGORY_NORMAL&&("medium"==Ti.Platform.displayCaps.density?($.icCaixa.top="3.5%",$.vLabel.top="3%"):"high"==Ti.Platform.displayCaps.density?($.icCaixa.top="5.25%",$.vLabel.top="4.5%"):"xhigh"==Ti.Platform.displayCaps.density?($.icCaixa.top="7%",$.vLabel.top="6%"):"xxhigh"==Ti.Platform.displayCaps.density?($.icCaixa.top="10.5%",$.vLabel.top="9%"):"xxxhigh"==Ti.Platform.displayCaps.density&&($.icCaixa.top="14%",$.vLabel.top="12%"));var:434)
       at ti.modules.titanium.platform.DisplayCapsProxy.getDisplay(DisplayCapsProxy.java:36)
       at ti.modules.titanium.platform.DisplayCapsProxy.getDensity(DisplayCapsProxy.java:66)
       at org.appcelerator.kroll.runtime.v8.V8Object.nativeFireEvent(Native Method)
       at org.appcelerator.kroll.runtime.v8.V8Object.fireEvent(V8Object.java:63)
       at org.appcelerator.kroll.KrollProxy.doFireEvent(KrollProxy.java:985)
       at org.appcelerator.kroll.KrollProxy.handleMessage(KrollProxy.java:1219)
       at org.appcelerator.titanium.proxy.TiViewProxy.handleMessage(TiViewProxy.java:260)
       at ti.modules.titanium.ui.WindowProxy.handleMessage(WindowProxy.java:481)
       at android.os.Handler.dispatchMessage(Handler.java:103)
       at android.os.Looper.loop(Looper.java:214)
       at at Window.postLayoutEvt (login.js:434)
       at at Window.value (kroll.js:1604)
       at at Window.value (kroll.js:1656)

I see the code and i suspect that the error is caused on this line:
https://github.com/tidev/titanium_mobile/blob/master/android/modules/platform/src/java/ti/modules/titanium/platform/DisplayCapsProxy.java#L36

Is there a chance of Activity be null? How can it can be avoided?

Thanks!

Expected Behavior

Don't throw error

Actual behavior

Throwing error

Reproducible sample

$.win.addEventListener("postlayout", postLayoutEvt);

function postLayoutEvt() {
	$.win.removeEventListener("postlayout", postLayoutEvt);
	if (OS_ANDROID) {
			if (Ti.Platform.Android.physicalSizeCategory == Ti.Platform.Android.PHYSICAL_SIZE_CATEGORY_NORMAL) {
				if (Ti.Platform.displayCaps.density == "medium") {
					$.ImageView.top = "3.5%";
					$.View.top = "3%";
				} else if (Ti.Platform.displayCaps.density == "high") {
					$.ImageView.top = "5.25%";
					$.View.top = "4.5%";
				} else if (Ti.Platform.displayCaps.density == "xhigh") {
					$.ImageView.top = "7%";
					$.View.top = "6%";
				} else if (Ti.Platform.displayCaps.density == "xxhigh") {
					$.ImageView.top = "10.5%";
					$.View.top = "9%";
				} else if (Ti.Platform.displayCaps.density == "xxxhigh") {
					$.ImageView.top = "14%";
					$.View.top = "12%";
				}
			}
		}
}

Steps to reproduce

I don't know because it happened on a production build and i get the errors on firebase crashlytics console.
But it happened on following devices:

• Galaxy A11 (Android 11)
• Galaxy J7 Prime (Android 8.1.0)
• Galaxy J7 Prime2 (Android 9)
• Galaxy J6 (Android 10)
• Galaxy J5 Prime (Android 8.0.0)
• Galaxy J5 (Android 6.0.1)
• Galaxy J2 Core (Android 8.1.0)
• Motorola One (Android 10)
• Motorola One Fusion (Android 11)
• Moto e(7) (Android 10)
• Moto e6s (Android 9)
• Moto G6 Plus (Android 9)

Platform

Android

SDK version you are using

10.1.1.GA

Alloy version you are using

1.17.3

[m1ga]

I can make a PR with m1ga@cb8e240
that will check if the activity is null and return 0 for all checks. Then you'll have to test it.

Could it be that the login window is closed right away (e.g. user is logged in already)?

To reduce Java calls you could also just do Ti.Platform.displayCaps.density one time and put it in a variable. And I think you don't need to put them in a postlayout.

[jquick-axway]

@m1ga can add a null check, but that would also mean he has no choice but to return zero which isn't what you want, but natively he has no choice. This will only be an issue if there is no active UI/activities.

If you're okay with an Android-only solution, then move your logic into the window's Activity.onCreate callback.

if (OS_ANDROID) {
	$.win.activity.onCreate = () => {
		// Do your thing here...
	};
}

Alternatively, move your code into a window "open" event listener. But the downside with this is you'll briefly see your views move after the 1st rendered frame.

[jordanbisato]

Yes, it's the login screen, first screen created after index.js.
Good tip to put result on a variable.
I will try the activity.onCreate tip. Thank you all!

[m1ga]

@jordanbisato you can also try the artifact here: https://github.com/tidev/titanium_mobile/actions/runs/2226558143 with the PR

[caspahouzer]

@jordanbisato did #13421 (comment) solves your problem?

[hansemannn]

I would actually argue to close the PR, since it's rather addressing the effects of the issue than the issue itself (a lifecycle issue based on the activity not being ready). Maybe a note about the onCreate callback could be added to the display-caps API instead?

[jordanbisato]

Hi, in my last production build, i use the callback solution of jquick, and the error didn't occour again.
I didn't use the PR because i didn't have enough time to test before upload the new version to the store.
And i can't reproduce this on development, just on production build using the Crashlytics tool.

[m1ga]

@hansemannn I would prefer both 😄 Adding this PR will just remove the crash when people use it wrong (eg. from a closing window). I've added a note how to read the values d0c358a in the apidocs.
Less random crashes is always better 😉

[hansemannn]

I'm not suuuure. The APIs do not work as expected if the null check is used, so people should know that they have to properly initialize it. But you are leading Android, so if you want to take it, we will take it!