How to disable the calling of "com.adobe.air.OrientationManager $1."

[XYobj]

Hello~

We are not allowed to call "com.adobe.air.orientationmanager$1."

So how can I ban it.

version: 33.1.1.686

[marchbold]

Can you elaborate some more on exactly what your issue or feature request is?

Have you tried setting the auto orients flag to false in your app descriptor?

[XYobj]

Can you elaborate some more on exactly what your issue or feature request is?

Have you tried setting the auto orients flag to false in your app descriptor?

Our publishing platform detected a call to "com.adobe.air.orientationmanager $1."

We haven't called it.

What is the name of "auto orientations flag"?

I'll try it.

[marchbold]

What is the issue with the orientation manager being called? It's probably how AIR handles orientation changes?

[marchbold]

FYI autoOrients

https://airsdk.dev/docs/building/application-descriptor-files/elements/initialWindow#autoorients

[XYobj]

FYI autoOrients

https://airsdk.dev/docs/building/application-descriptor-files/elements/initialWindow#autoorients

I tried the above method and still reported calling "com.adobe.air.orientationmanager$1."

[XYobj]

Our publishing platform has detected it. Let's explain why we use it.

But we really haven't used it.

I'm crazy now.

[marchbold]

Not really sure what the issue is. The name would indicate an internal working of AIR likely to handle the orientation of the application. Why is this an issue?

[XYobj]

Not really sure what the issue is. The name would indicate an internal working of AIR likely to handle the orientation of the application. Why is this an issue?

It's just the requirement of our release platform

[marchbold]

Interesting, have they given a reason? Seems odd given this is functionality of the app.

[XYobj]

Interesting, have they given a reason? Seems odd given this is functionality of the app.

It is because of the standard of personal information collection.

Can you help shield this call and provide a new SDK?

Thank you.

[marchbold]

personal information related to the device orientation? Seems odd?

I'm not a developer of the AIR SDK, just a user. You'll need to get someone from Harman to do that.

[XYobj]

personal information related to the device orientation? Seems odd?

I'm not a developer of the AIR SDK, just a user. You'll need to get someone from Harman to do that.

OK and thanks.

[XYobj]

@ajwfrost Please help me.

[marchbold]

Personally I'd push back at the platform and ask them to explain why this is an issue?

[ajwfrost]

Hi @XYobj

Your original comment here is:

Our publishing platform detected a call to "com.adobe.air.orientationmanager $1."

The com.adobe.air.OrientationManager class is an internal one for AIR which listens out for device orientation changes and then sends events and/or adapts the display as requested by the AIR application. So if this is calling a particular API which you're not allowed to call, then I would ask:

1. what is the API that's forbidden? is it something like android.hardware.SensorManager or is it the fact we've got a subclass of android.view.OrientationEventListener (which may be the issue seeing as you've mentioned a $1 which would imply an anonymous class within the OrientationManager class, which matches how the OrientationEventListener is created..)
2. would it be acceptable to have the implementation but have this disabled by code? i.e. if there was a setting you could apply that would prevent these APIs from being exercised, would that be sufficient, or are they scanning the capabilities of the source code and seeing that it references an Android API regardless of whether it's actually called or not?

thanks

[XYobj]

Hi @XYobj

Your original comment here is:

Our publishing platform detected a call to "com.adobe.air.orientationmanager $1."

The com.adobe.air.OrientationManager class is an internal one for AIR which listens out for device orientation changes and then sends events and/or adapts the display as requested by the AIR application. So if this is calling a particular API which you're not allowed to call, then I would ask:

1. what is the API that's forbidden? is it something like android.hardware.SensorManager or is it the fact we've got a subclass of android.view.OrientationEventListener (which may be the issue seeing as you've mentioned a $1 which would imply an anonymous class within the OrientationManager class, which matches how the OrientationEventListener is created..)
2. would it be acceptable to have the implementation but have this disabled by code? i.e. if there was a setting you could apply that would prevent these APIs from being exercised, would that be sufficient, or are they scanning the capabilities of the source code and seeing that it references an Android API regardless of whether it's actually called or not?

thanks

We haven't called relevant functions.

I think they scanned the source code.

[ajwfrost]

We haven't called relevant functions.

It looks like the OrientationEventListener derivation would be automatically created and enabled, without you having to do anything: https://developer.android.com/reference/android/view/OrientationEventListener#enable() So this is something we can potentially prevent from happening if we add a new configuration setting...

I think they scanned the source code.

In which case there's nothing we can do: we need that capability to remain in place for anyone who does actually need to have the orientation information or to change/auto-orient their app! So I would suggest if you can check with them and see whether they are able to confirm how they do it and whether they can make an exception, whether disabling it via configuration would be sufficient, etc?

thanks

[XYobj]

We haven't called relevant functions.

It looks like the OrientationEventListener derivation would be automatically created and enabled, without you having to do anything: https://developer.android.com/reference/android/view/OrientationEventListener#enable() So this is something we can potentially prevent from happening if we add a new configuration setting...

I think they scanned the source code.

In which case there's nothing we can do: we need that capability to remain in place for anyone who does actually need to have the orientation information or to change/auto-orient their app! So I would suggest if you can check with them and see whether they are able to confirm how they do it and whether they can make an exception, whether disabling it via configuration would be sufficient, etc?

thanks

Can you add a configuration in "app_config.xml" to decide whether to call it?

[ajwfrost]

Can you add a configuration in "app_config.xml" to decide whether to call it?

Yes we should be able to add something in here. It won't help if they're just code-scanning, but it would mean that we can avoid making the actual call...

I'll get someone to look at how to best make these changes.

thanks

[XYobj]

Can you add a configuration in "app_config.xml" to decide whether to call it?

Yes we should be able to add something in here. It won't help if they're just code-scanning, but it would mean that we can avoid making the actual call...

I'll get someone to look at how to best make these changes.

thanks

Thank you.

How long will it take?

Please contact me if you have any results.

[XYobj]

My boss is in a hurry, so please give me a time first. Thank you.

[marchbold]

I'm very interested to know why this is a concern? I've never had anyone pull us up on this before :) Did they give you any more information on the reason for the issue with the orientation listener?

[XYobj]

I'm very interested to know why this is a concern? I've never had anyone pull us up on this before :) Did they give you any more information on the reason for the issue with the orientation listener?

Their answer is only "they have been tested manually and by machines", which is not high-speed to our other information.

It's puzzling

[marchbold]

Yeah right, very cryptic.

[ajwfrost]

It seems to be a fairly simple change where we can hook into the existing "autoOrients" value in the XML descriptor, and then use a third option there to ignore all the orientation code. This does however mean that we won't be listening out for orientation changes so there may be some interesting challenges with layouts...

We'll get this into our next release on the 33.1 branch to make it a bit quicker, should be within the next two weeks.

thanks

[XYobj]

It seems to be a fairly simple change where we can hook into the existing "autoOrients" value in the XML descriptor, and then use a third option there to ignore all the orientation code. This does however mean that we won't be listening out for orientation changes so there may be some interesting challenges with layouts...

We'll get this into our next release on the 33.1 branch to make it a bit quicker, should be within the next two weeks.

thanks

Is there a specific release time for the new version? My boss is in a hurry. ╮(╯_╰)╭

[ajwfrost]

Release process has been kicked off, so it should be available maybe end of this week or start of the next..

[ajwfrost]

@XYobj preview is available here: https://airsdk.harman.com/download/33.1.1.926 thanks

[ajwfrost]

So with this, you should be able to set the "autoOrients" flag in your xml descriptor to "ignore" rather than true/false. This will then stop that call being made...

[XYobj]

So with this, you should be able to set the "autoOrients" flag in your xml descriptor to "ignore" rather than true/false. This will then stop that call being made...

Thank you.