[Bug]: Incorrect device cutout status upon app launch

[jwtan-unity]

Braze Unity SDK Version

3.11.0

Steps To Reproduce

bug-appboy-cutout.zip

1. Build and run the app on an Android device that has a cutout
2. Open Android Logcat and filter by @@@

Expected Behavior

Log message should print @@@ Screen.cutouts.Length: 1 to indicate the correct status of the cutout on the device.

Actual Incorrect Behavior

Log message prints @@@ Screen.cutouts.Length: 0 that indicates that there are no cutouts on the device.

Verbose Logs

No response

Additional Information

I'm unsure if this problem is caused by the Appboy Unity SDK or a problem with the SDK integration with Unity.

Does the Appboy Unity SDK attempt to modify the app layout in any way?

[bryanlogan]

I'm running the example using Unity 2021.3.14f1 against a Pixel 6 and I'm getting the following results. It appears that the cutouts is correct when FirstScript.start is executed.

11-22 08:05:47.006 28473 28614 I Unity   : @@@ Screen.cutouts.Length: 0
11-22 08:05:47.006 28473 28614 I Unity   : @@@ Screen.safeArea: (x:0.00, y:0.00, width:1080.00, height:2282.00)
11-22 08:05:47.012  1758  5219 W SensorService: sensor 01010001 already enabled in connection 0xb400006e97755150 (ignoring)
11-22 08:05:47.013   900   900 D usf_sensor_hal: accelerometer: Enter Batch. period = 200000000, latency = 0.
11-22 08:05:47.013  1115  1115 D AOC     : A3:MSG: usf_sensor.cc, 1845: USF: Received reconfig sampling request for LSM6DSR Accelerometer.
11-22 08:05:47.014   900   900 D usf_sensor_hal: IMU temperature: Enter Batch. period = 615385000, latency = 0.
11-22 08:05:47.014   900   900 D usf_sensor_hal: accelerometer: Enter Flush
11-22 08:05:47.015   900   900 D usf_sensor_hal: accelerometer: Enter Batch. period = 20000000, latency = 0.
11-22 08:05:47.015  1115  1115 D AOC     : A3:MSG: usf_sensor.cc, 1845: USF: Received reconfig sampling request for LSM6DSR Accelerometer.
11-22 08:05:47.016   900   900 D usf_sensor_hal: IMU temperature: Enter Batch. period = 615385000, latency = 0.
11-22 08:05:47.020 28473 28473 E SurfaceSyncer: Failed to find sync for id=0
11-22 08:05:47.020 28473 28473 E SurfaceSyncer: Failed to find sync for id=1
11-22 08:05:47.035 28473 28473 E SurfaceSyncer: Failed to find sync for id=0
11-22 08:05:47.035 28473 28473 E SurfaceSyncer: Failed to find sync for id=1
11-22 08:05:47.050 28473 28614 I Unity   : ### FirstScript.Start ###
11-22 08:05:47.050 28473 28614 I Unity   : @@@ Screen.cutouts.Length: 1
11-22 08:05:47.050 28473 28614 I Unity   : @@@ Screen.safeArea: (x:0.00, y:0.00, width:1080.00, height:2170.00)
11-22 08:05:47.053 28473 28614 I Unity   : ### FirstScript.Update ###
11-22 08:05:47.053 28473 28614 I Unity   : @@@ Screen.cutouts.Length: 1
11-22 08:05:47.053 28473 28614 I Unity   : @@@ Screen.safeArea: (x:0.00, y:0.00, width:1080.00, height:2170.00)```

[jwtan-unity]

I think you'll find that earlier in the log FirstScript.Awake returns @@@ Screen.cutouts.Length: 0. This can also be seen in the log snippet that you've posted.

[bryanlogan]

I've removed all the Appboy libraries and used "com.unity3d.player.UnityPlayerActivity" in the AndroidManifest.xml, and the app is behaving in the same way. Value is incorrect at first, but then eventually is correct. I believe this is a Unity bug.

[jwtan-unity]

Can you try going into Project Settings > Publishing Settings and disabling Custom Main Manifest? Based on my testing, this will fully remove AppBoy Unity SDK integration which results in the app correctly printing @@@ Screen.cutouts.Length: 1 at app launch.

Just to be very clear, I'm unsure if this problem is caused by the AppBoy Unity SDK or a problem with Unity player activity overriding (this second possibility could indeed be considered a Unity bug). Unity requires that layoutInDisplayCutoutMode use shortEdges so if the AppBoy Unity SDK is attempting to modify this value, it can cause the cutout status to return the wrong values during app launch. Does the AppBoy Unity SDK modify layoutInDisplayCutoutMode at all?

[bryanlogan]

OK, I see that behavior if I turn off the custom manifest.

When I have no Braze code or library anywhere, and I'm just using the custom manifest using the UnityPlayerActivity directly, I'm getting a 0 the first time. So that makes me think it's something on the Unity side.

When we display In-App Messages, we'll read the displayCutout values to adjust the margins of some of our views, but we're not writing to that value.

[jwtan-unity]

If you're not modifying the app layout settings at all then this would appear to be a Unity issue after all. Let me look into this further and I'll get back to you when I figure out a solution.

[jwtan-unity]

We've tracked down the problem to the custom player activity that your documentation specifies here. As no theme is specified in the player activity, the app launches in an unknown layout that can cause delays when the Unity engine requests for the required app layout.

The solution is to specify Unity's default theme in your player activity (i.e. android:theme="@style/UnityThemeSelector"). Unity's documentation has already been updated to reflect this recommendation (see the example at the bottom).