NDK and screen size; esp. w/ keyboard

[J Decker]

I've been doing some tinkering trying to get a good size of the screen when the keyboard is present.

Managed Views get to have a feature to use android:windowSoftInputMode="adjustResize" ; which I guess NDK apps get also but with some work...

I don't understand why this is made to be so difficult.

My native resolution is 720x1280, and specifically testing on samsung galaxy S3; this is the resolution that a java activity sees; and is available at multiple levels.

The ANativeWindow I get is sized 640x1138.

I did some digging, and found various methods to get View sizes...

I found that a NativeActivity is made of...

DisplayMetrics metrics = new DisplayMetrics();

getWindowManager().getDefaultDisplay().getMetrics(metrics);

Log.v( "MyNative", "matric height " + metrics.heightPixels + " width " + metrics.widthPixels );

int result = getResources().getDimensionPixelSize(resId);

Log.v( "MyNativeI", "status bar result " + result );

      Display display = getWindowManager().getDefaultDisplay();

Point size = new Point();

display.getSize(size);

int width = size.x;

int height = size.y;

Log.v( "MyNative", "width " + width + " height " + height );        

    Log.v( "MyNative","this is d)" +  getWindow() );

    Log.v( "MyNative","this is d)" +  getWindow().getDecorView() );

Log.v( "MyNative","this is c)" +  ((ViewGroup)getWindow().getDecorView()).getChildAt( 0 ) );

Log.v( "MyNative","this is b)" +  ((ViewGroup)((ViewGroup)getWindow().getDecorView()).getChildAt( 0 )).getChildAt( 0 ) );

Log.v( "MyNative","this is b)" +  ((ViewGroup)((ViewGroup)getWindow().getDecorView()).getChildAt( 0 )).getChildAt( 1 ) );

Log.v( "MyNative","this is a)" +  ((ViewGroup)((ViewGroup)((ViewGroup)getWindow().getDecorView()).getChildAt( 0 )).getChildAt( 1 )).getChildAt(0) );

Log.v( "MyNative","this is b)" +  ((ViewGroup)((ViewGroup)getWindow().getDecorView()).getChildAt( 0 )).getChildAt( 2 ) );

Log.v( "MyNative","this is a)" +  ((ViewGroup)((ViewGroup)((ViewGroup)getWindow().getDecorView()).getChildAt( 0 )).getChildAt( 2 )).getChildAt(0) );

-------------

V/MyNative( 5489): matric height 569 width 320

V/MyNative  ( 5489): status bar result 25

V/MyNative( 5489): width 320 height 569

V/MyNative( 5489): this is d)com.android.internal.policy.impl.PhoneWindow@4230f4d8

V/MyNative( 5489): this is d)com.android.internal.policy.impl.PhoneWindow$DecorView@42310db0

V/MyNative( 5489): this is c)android.widget.LinearLayout@42311bd8

V/MyNative( 5489): this is b)android.view.ViewStub@42313050

V/MyNative( 5489): this is b)android.widget.FrameLayout@42313418

V/MyNative( 5489): this is a)android.widget.TextView@42318078

V/MyNative( 5489): this is b)android.widget.FrameLayout@4231abc8

V/MyNative( 5489): this is a)android.app.NativeActivity$NativeContentView@42310b40

So the size of (a) can be gotten...   activityRootView = (a)

       Log.v("MyNative", "Height is "+activityRootView.getRootView().getMeasuredHeight() + " "+ activityRootView.getMeasuredHeight() );

or 

       Log.v("MyNative", "Width is "+activityRootView.getRootView().getWidth() + " "+ activityRootView.getWidth() );

which results with (without keyboard)

   V/MyNative(31098): Height is 569 544

or  (with the keyboard)

   V/MyNative( 1293): Height is 569 323

which indicates that the keyboard might be 199 pixels.  The other 47 pixels I assume are the top.

The size of the android.widget.FrameLayout around the android.widget.TextView is 25; the TextView is 25.... (1/2 of the status bar size from metrics)

All of the sizes that can be gotten of the RootView or of the Window that contains the views is 320x569; this times to is 640x1138 (which is the native surface I get)

if I use getWindow().setWindowSize( 1000, 1000 ); nothing changes regarding the output, or the antive window surface; the size is still resulted as 640x1138.  The relative size of the android.app.NativeActivity$NativeContentView changes by -199 if the keyboard is present, no matter what size... (tried forcing 720x1280, and result was (1280-47) normal view size, and (1280-47-199) with keyboard on display... (if I set the flags soon enough to get the internal views to update)

unless the device is sideways, in landscape mode, a java application shows a keyboard that has a large text input, and covers the form; the keyboard also usually has symbols over it (one more row of data) that doesn't show in the NDK version; probably an option on showing the keyboard so I'm not so concerned with that detail.... but the landscape application doesn't get a size change... actually my NDK app did, when the keyboard was showing, and turned frmo portrait to landscape, the first size includes the -199; and the keyboard auto closes, so It takes my app twice (interally I think it's showing, so first I hide it hidden, and then reshow) and it does not resize in landscape....

I did some measuring using onscreen display and the top of the keyboard seems to be at (740 of 1138) ... 

okay so I set the window size to 640x1138 so ANativeWindow and the overall view are almost aligned... which results in a view sized 892.... there's no translation between 740 and 892 possible; so the keyboard isn't actually 199 pixels.

(and  740:832 as 1138:1280   )

maybe  (740 + 47):885 as 1138:1280  

but that's not right, cause the ANativeWindow is actually full screen ( even behind the status bar, which seems to be at (43 or 44):49 (scaled)  neither of which is 47... ) so that size shouldn't matter to the position on the native window... it it should be 740 at the top of the keyboard....

-----------------------------------------------------

So it seems to me that there has been deliberate effort made to sabotage compatibility.... but according to Hanlon's razor 'Never attribute to malice that which is adequately explained by stupidity'  That probably isn't the case.

The next thing I could query would be /dev/graphics/fb0 and see what it claims... but then I have to get superuser permission which isn't a good long term solution. so I'm just gonna avoid that route

--------------------------

So maybe the original view size is relative to the 199 and 25... since it's 1/2 of the screen approx, then the text box would be 50 high and approximately represent the status bar (and maybe that's why it's there... maybe it just has to exist to get the keyboard to show)

199 * 1280 / 569 = 447 (1280-447 = 832) (that's what it is if ANativeWindow geometry is forced 1280x720)

199 * 1138 / 569 = 398 ( 1138 - 398 = 740 )  (well that's the number it is...)

so if I keep the logic to get the changed size, and scale that back to the ANativeWindow size I get the size....

I do hate that I can't actually get native pixel output; makes some lines thicker than others.. about 1 in 11 or so

-----

code to get the adjusted view is... with the above init for activeRootView

activityRootView.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {

   @Override

   public void onGlobalLayout() {

       int heightDiff = activityRootView.getRootView().getHeight() - activityRootView.getHeight();

    } } );

------

re: the status bar size...  (50 is from the get metric)

50 / 1280 * 1138 = 44 which is what the apparent status bar size was... 

-----

setting      getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,     WindowManager.LayoutParams.FLAG_FULLSCREEN); disabled the sizing.

setting  getWindow().setSoftInputMode( WindowManager.LayoutParams.SOFT_INPUT_ADJUST_RESIZE);  after      super.onCreate( savedInstanceState ); disabled the sizing.

not having the attribute in the XML <activity android:windowSoftInputMode="adjustResize" />  disables resizing.

-----

So then the only real problem is I cannot get the real screen size.... 

maybe I can launch another activity to get the screen setup and record it to a database or something (and not launch if the settings are already set).  Feature; most android devices don't have video upgrades :)  

Will fail probably if the display is output to hdmi or something.

---

I pursued the option to read /dev/graphics/fb0; 1) just getting su didn't allow me to read it; 2) other threads say 'we're not supporting this' 3) if I use 'adb shell' and 'su' and "chmod 666 /dev/graphics/fb0" I can open it, but IOCTL calls fail to it, so cannot get information that way.

I Looked to see if the framebuffer driver exported simple symbols somewhere in /proc... but the only thing there seems to be the list of framebuffer devices and that's just the driver name.

----

So I suppose it's all sabotaged to limit developers into using 'the proper' SDK; could wish it weren't so hard to interop with BIOS features... the keyboard being a basic input device

[J Decker]

I was missing a tag in my AndroidManifest.xml

    <uses-sdk

        android:minSdkVersion="14"

        android:targetSdkVersion="19" />

Which is supposed to be in <manifest>

I had minsdk and targetsdk as attributes of the activity, which didn't work.

Now applications get a Window which is the correct dimensions.

Is there a maximum size per sdk version?  Like eventually if I run into 1920x1080 screen, will 14 be high enough to still get the correct size?  Was it changed at some point to result the correct size instead of constant?

[NoAngel]

 Hi, I got this problem and found Your post.
>ANativeWindow is actually full screen ( even behind the status bar...

My AndroidManifest.xml looks good, has uses-sdk tag, but still have problem above.

From Your post:

>activityRootView.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
>  @Override

>  public void onGlobalLayout() {

>  int heightDiff = activityRootView.getRootView().getHeight() - activityRootView.getHeight();

>} } );

Is this fixed it for You?

[NoAngel]

nvm, I did it by myself, resized OpenGL drawing area, and fixed touch y...

[Chanon]

NoAngel,

I have a similar problem. How did you resize the OpenGL drawing area?

[Cass]

nvm, I saw your other post