Android display resolution

Report · Sep 16, 2013

When building an AIR app for iOS, inside of the (app.xml) file there is a section for <iPhone>

Inside the iPhone section is a <requestedDisplayResolution>

I understand what this feature does and I am able to use it correctly... but my question is... Is there anything like this for Android?

Report · Sep 19, 2013

Basically for an iPad3, it's retina display is 1,536 x 2,048.. but if you include something like this line:

it forces the iPad3 to be 768x1024, just the same as the iPad2....

So again my question is.... anything like this for android?

Report · Sep 20, 2013

No, as of now, this is only for iOS.

Regards,

Nimit

Report · Sep 20, 2013

are there any plans of doing anything like this? I recently upgraded to a Galaxy S4 with 1920 x1080 & 441 ppi and all my apps are ridiculously tiny.

Report · Sep 20, 2013

In that case, I request you to open an enhancement bug report on this over at bugbase.adobe.com? Please include use cases if possible. Once the bug has been added would you mind posting back with the URL so that others affected can add their votes and comments?

Regards,

Nimit

Report · Sep 20, 2013

I added the enhancement bug as requested:

https://bugbase.adobe.com/index.cfm?event=bug&id=3637474

Please vote on this!

Report · Sep 20, 2013

I think you should investigate stage scale modes. If you are using noScale then you have to do the resizing and positioning of everything with code. But if you use showAll or noBorder, the Flash stage gets scaled to fill the device, no matter what its DPI or pixel size is.

The reason you might exclude the iPad 3 is because if you are using Direct render mode, and not using Stage3D, that’s a lot of pixels to be blitted. Forcing the iPad 3 to run as 1024x768 cuts the number of pixels down to 1/4.

If you are seeing your app as being only a small part of the screen, I think you are using noScale and you’re not doing the scaling yourself. So, try commenting out the exiting scale mode line (it will then default to showAll), and you should see your app fill the screen again.

Report · Sep 20, 2013

I am using the "noScale" mode and doing all the resizing/positioning myself.

My app was originally a Desktop AIR app using the display list and I am converting it to iOS and Android.

I am excluding the iPad 3 from being in the higher resolution mode, and I'm using GPU. The reason for doing this is because it renders at 1024x768 instead of 2,048x1,536 (which otherwise would make my app appear very tiny since I'm resizing/positioning graphics to fill the stage.stageWidth/etc).

This all being said... the only reason I can think of iOS evening having the option for <requestedDisplayResolution> is to address this exact problem.

And since everything is working perfectly for iOS by using this option, I was simply hoping the same could exist for Android.

Report · Sep 20, 2013

You can tell the width and height of the device you’re on, and so when you lay out your interface with code you would just end up using twice the value on iPad 3.

As you are using GPU, there are no performance reasons to exclude iPad 3.

Android doesn’t have the same concept of Retina/non-Retina. It’s not like with iPhone and iPhone 4, or iPad 2 and 3. There are hundreds of different sized Android screens, you will need to solve the problem of laying things out with your code to cope with all the sizes and ratios there are.

Report · Sep 20, 2013

There may be no performance reason to exclude iPad3, but there definitely is a visual reason (2,048x1536) vs (1024x768).

The initial AIR Desktop app I am porting is a multi "native window" app where in each window has assets that are being resized.

and maybe i'm not quite understanding the process but... can you explain "and so when you lay out your interface with code you would just end up using twice the value on iPad 3"

Lets say I have a 100x100 logo in the Desktop AIR App sitting on the top right corner. Are you saying I need to scale up my graphics to be 200x200? Isn't that going to make my app look horrible quality wize?

Report · Sep 20, 2013

If the image is a bitmap, and it was designed for 100x100, then yes, it may look a little fuzzy. But when you set the iPad 3 to be 1024 instead of 2048, it’s just doing the same scaling for you.

Ideally you would have used vector graphics, those will look great when scaled up.

Report · Sep 20, 2013

I don't see a need for this on Android. The high/normal moniker is a poor way to denote density, and the parameter is there just as a quick way to support old apps on the high density displays. Adding this would only cause confusion and a doubtful improvement. This is gonna bite Apple's in the ass in the future if they ever want to add a different pixel density since they'll just keep on adding magical keywords.

On Android you read the display pixel density by reading Capabilities.screenDPI (since displays can have any number of different pixel densities). Then based on this you can decide what to do (load higher res image, whatever).

If you want to have the same behavior on Android as the "high" parameter on iOS, you can just read the pixel density on your app's startup and resize your main app container Sprite scaleX and scaleY as desired. That way you won't have to take the current size into consideration anywhere else.

Report · Sep 23, 2013

Thanks for your comments

Sadly I am porting a very large previously existing Desktop AIR application that uses many bitmaps instead of vector.

The reason I was hoping for a simple Android solution similar to the iOS one, is that my client simply does not have the budget for the time it would require me to go

redo all every section/feature to scale up, simply because this was pitched as "Now AIR can be compiled iOS and Android!"... and it does... just I didnt know it requires redoing stuff for Android only.

Report · Sep 23, 2013

But it doesn't require you redoing anything. The same issues you'd having porting a "normal" iOS app to a "high resolution" iOS app are the issues you'd have with supporting other Android pixel densities. You'll scale the Bitmaps up.

If you want to solve this quickly, just resize your main container, or use stage scale modes like Colin suggested. This will have the same effect as running an old iOS app on a new iOS device. You may need to search for references to stageWidth or stageHeight on the app to make sure it's not trying to be clever, but you won't have to touch the content or recreate bitmaps or whatever.

That tag is not magic. It's there to make scaling the content faster. But the same can be accomplished by a couple of lines on Android or other platforms.

Report · Sep 23, 2013

Thanks for the comments

I'm not trying to port my app to be in "high resolution". I'm trying to prevent "high resolution". That being the case, the point I was trying to make is that I have no issues for iOS simply because that tag exists.

The "redoing" I was referring to, is exactly what you mentioned, "You'll scale the Bitmaps up". Something I do not have to do for Desktop nor iOS (because that tag exists)

If my client approves more time I will look into the suggestion you made for how to fix Android.

Report · Sep 23, 2013

I'm not sure you understand my point. When I say "you just scale the Bitmaps up" what I mean is that you use a bigger scale (in Flash) for the content. It will be the same content.

I'll say it again: what the tag does is easily done in Android (or any other platform) with very little code. The tag is just a clutch that does it more automatically but with less control. Whether you'll have time to do that or whether the client will approve that is nothing I can comment on. But I'm afraid you may be overthinking this.

Report · Sep 23, 2013

I appreciate your help. I definitely do understand your point.

Your suggesting that through code, I would do something to address the scale, whether using a combination of scaleX/scaleY/width/height/Capabilities.screenDPI ... whether it be on the main container or individual pieces, even if it's very little code.

All I'm saying is, as it stands, on iOS there is a tag that handles this all for me, not Android.

not trying to beat a dead horse... but i think the biggest thing the tag does that is IMPOSSIBLE to do on Android is it makes "this.stage.stageWidth" go from 2048 to 1024.

No matter what trickery/scaling or doubling/halfing of assets...

Report · Aug 14, 2014

I'd love to know if you ever found a magic bullet for this. I am in the EXACT same situation: have an old AIR app that looks ridiculous on HiDPI android devices because "this.stage.stageWidth" returns a crazy high number on those devices. I don't want to hack through my code. I just want stageWidth to return a "virtual" value as if it were a standard definition device, like it can with iOS, but for Android.

Report · May 12, 2016

Hi JonArnold,

Did you find a way to achieve this?

Our flash vectorial content is getting really slow on those high resolution screens (like the Samsung S7) and we would like to make it faster by simulating a smaller resolution screen somehow...

Thank you

Alexandre