I'm developing a very simple cross platform window class in C++ just so I have a surface to render to. I've gotten it working on Linux and Windows so far. After I get it working on OS-X I want to try to get it working on my android phone.
However, I need to know if all "windows" created with SurfaceFlinger are full screen or if they can take up only a section of the desktop like a window on Linux or Windows? I ask this because I know I can place widgets on my phone's desktop but I've never seen an app do anything like a popup or a frame that hovers over the desktop.
How does creating a "window" that is smaller than the resolution of the phone work? Does it just center the drawable surface and leave black borders? Also can an application have multiple "windows?"
The Surfaceflinger, as its name suggests, deals with surfaces, not windows.
Each window actually holds one surface it can draw onto, but these are different types of classes.
Whenever the ViewRootImpl (top view of a window) of a certain application's window is created or changed in some way, a call is made to the WindowManagerService's relayout function.
Now, skipping some boring details, the WindowManagerService creates a surface.
A surface can be of any size, and if you are using multiple displays, it can even be attached to a certain display (though this is not yet implemented).
This brings us back to your question(s):
- A surface (window if you like) can be of any size. The black borders that you mentioned actually come from the window that is placed below the current window (and is painted black).
- Yes, an application can have multiple windows (a window, for example, can be a dialog).
As for widgets, I know how the Launcher (the desktop app) supports them and supports their drag and drop behaviours, but I never asked myself whether they were in fact new windows - so I can't really answer that.
Also can an application have multiple "windows?"
Yes, an application can have multiple windows.
1. Status bar window
2. Activity screen window
3. Navigation window
4. Dialog and so on.
Related
I am totally newbie in Unity.
I have some pop-up windows in my 2d project. I want "block" rest of screen if pop up window is active.
How i can achive this?
I am working with android.
Welcome new user, it's actually pretty simple.
if you are used to programming ios or android, it's different, you simply do it "manually".
All you do is ...
in your UI
make a new panel which is full screen, name it "gray cover" or such
make it 90% alpha and black
in fact simply put your popups on top of that
when you want one of your popups to appear, just turn on the gray cover and whichever popup/message you want
Enjoy
I want to place a hardware keyboard on part of the screen of a specific android smartphone (just like the Galaxy S7 edge Keyboard Cover). So i need the android system to always only use the part of the screen which is not occupied by the keyboard, even on full-screen video playback etc. But a service needs to be able to handle the touch events of the area occupied by the keyboard. This does not need to work while booting.
Solutions may use stock android (with root access) or a modified LineageOS.
I tend to believe that there is no solution for stock android.
But the Android open source Project is too complex for me to find a place to start modifying. The window manager service, surfaceflinger, or any other?
My intention is that modifying surfaceflinger would be the most general solution. Is modifying surfaceflinger even possible or is it linked statically with the HAL and part of the binary blob? I expect surfaceflinger not to handle touch events in any way, right?
A vague idea not touching surfaceflinger is to modify the window manager to ask surfaceflinger to create a virtual display with a smaller size as the native one, use this for anything instead of the native one, and blit it to the native one.
Another idea is to modify rectangles of the windows in the window manager. But i don't know whether this is possible (especially for full-screen video playback).
The touch events would need to be modified as well. By the way, does the window manager route the touch events?
Is there any component of android which uses surfaceflinger directly bypassing the window manager and my possible modifications? For example may apps ask surfaceflinger for the screen size/resolution or is this information dispatched by the window manager?
Is there a more simple way?
Any hints?
I found a even more simple solution on my own. The window manager of android manages overscan-settings for each display which may be changed by the wm command in a root shell for example, in order to restrict the area of the display used by the system. This works like a charm.
And yes, the window manager routes the input to the top window. But i do not know how and where, cause the WindowManagerService class is a huge mess, i do not want to fiddle with anymore.
The documentation even states, that a touchscreen driver exposing a specific file in /proc (or /sys, i can't remember) containing information about where fixed soft-buttons are located and how they should be mapped to linux key codes would force the system to automatically use them. So using a custom kernel module which creates such an entry in the filesystem will eventually do the trick. But it is untested.
The button presses of the hardware keyboard are handled by a dedicated service only, so i will simply read /dev/input/event directly in this service.
I'm looking for a way to take a screen shot/screen capture of an openGL application that is behind another window. Namely, I want to screen capture the Android Emulator running an openGl app.
Since the Android Emulator is behind another window, it's not visible on the PC screen, so that taking a normal screenshot or using one of the several screenshot tools I found does not work. Making the Android Emulator the active window to capture it is not an option, because I don't want to distract the computer user.
Of the numerous screenshot tools I tried, one was able to capture background windows. But it couldn't handle opelGl and returned only a black picture. I didn't find a tool that could handle both background windows and openGl.
Note: Although the user should not be disctracted, using a graphical screenshot tool will probably work. I'd do this by leaving the tool in the background and sending it mouse/keyboard input, e.g. via AutoHotkey.
I'd also be comfortable with writing a program for this task, but I haven't found a way to screen capture an openGl window. It's possible to capture Direct3D Windows, and it is also possible to draw the content of an openGl window somewhere else, but neither of this seems to be helpful here.
Using the android debug bridge to take a screenshot returns only black pictures. People often suggest turning the gpu acceleration of the emulator off, but when I do this, the android app I'm trying to capture doesn't start anymore.
I'm using Windows 7 (32bit) with the latest Android SDK and Android 4.4.2. When the Android Emulator is visible, a normal screenshot shows it's actual content, not only a black rectangle.
So is there any way to do what I want?
What I want to achieve here is to shrink all of the Android's OS UI (everything inclusive) to use only 70-80% of the screen.
The reason is that I wish to have my area to put in whatever I want - apps icons which exist and are always visible (no matter if I am in a browser, or playing angry bird etc).. its like Windows's quick launch or Mac's dock which always stays there . I can also put some important text that I wish to see throughout my interaction with the device or anything else.
I just want to use 20-30% of the screen-size all by myself and run Android on the remaining portion of the screen.
Do you think it is possible? If so, can you please give me pointers?
Thanks much,
Rohan
There are two solutions for me:
1) create custom Android build. Change WindowManager code a little.
2) create own virtual keyboard which will serve keyboard and your stuff (http://developer.android.com/reference/android/inputmethodservice/InputMethodService.html)
I'm quite new to Android programming but familiar with C/C++ and Linux enough to program a few stuff. In my next project, I've to run some native application (Linux applications) under Android.
The executable I'm calling is using the framebuffer device to produce screen output. When I try to just call the program the output of the program is lost because Android is redrawing the screen, thus overwriting the framebuffer.
In order to prevent this, I made a "stubbing" Android program, which actually has no window design (just a black screen) but calls my program. This is working good to some extend; however, whenever I rotate the screen, or some Tattoo notification comes, Android redraws the screen and we're back to frame #1...
Thus, I wondered if there is a "low level" API or something, which can prevent Android from using the screen at all, as long as I release it. Shortly, like a WakeLock preventing phone from sleeping, I want a 'Lock' which will lock the screen (framebuffer device) completely. Does anyone know how can I achieve such functionality?
PS: This might have something to do with SurfaceFlinger, but I've read somewhere that it doesn't publish any API to user-level.
On Android the screen belongs to SurfaceFlinger.
The executable I'm calling is using the framebuffer device to produce screen output.
That's not supported.
Thus, I wondered if there is a "low level" API or something, which can prevent Android from using the screen at all, as long as I release it.
Nothing that is supported at the SDK or NDK levels. You are welcome to create your own custom firmware that does whatever you want, and load that custom firmware on your own device.
Otherwise, please use a supported means for interacting with the screen (e.g., OpenGL natively in C/C++).