There was a race in the system process between applying the initial
configuration and executing code in higher-level system services
like the app widget service that relies on the config. For some
reason it starting showing up more after my code changes; it should
now be completely fixed.
Also fix the activity starting window to run in compatibility mode
if its application is going to be in compatibility mode.
And some various cleanup and small fixes.
Change-Id: I0566933bf1bbb4259c1d99a60c0a3c19af1542e5
The previous implementation was using glBlendFunc with the parameters
GL_ZERO/GL_ZERO which doesn't work for text, paths and other alpha
sources (anti-aliasing.) The correct implementation is GL_ZERO/
GL_ONE_MINUS_SRC_ALPHA.
Change-Id: I4cca65e57b6a37bbf5a41d382cb0648ee8e11e79
Padding around fragments and to the left of preference items
adjusted for different display sizes.
Change-Id: I2d29e5525c381092a3f1d2fb1265ce07db893d78
Change-Id: I40d57e4354e48accc1027c9f90916ea73eb5190d
android:requiresSmallestWidthDp provides the smallest supported width.
android:compatibleWidthLimitDp provides the largest compatible width.
there are cases where webkit dump timed out, but a RuntimeException
was not thrown (as it should have) after the timeout limit was
reached. It's probably because the Looper message to invoke time
out is obtained after the message to dump webview. This change
adjusts the order of obtaining the message so hopefully it can make
the timeout work for real.
Change-Id: I4197699f5aad765c88dc81123d052e4c49d7c53d
Views requesting lights out mode will cause the navbar to
disappear (this is useful for viewing videos/photos/etc
using every pixel of the screen).
But there's a catch: any user activity at all will cause the
lights to come back on and the navbar to return.
Change-Id: I535ed3ba9ae7fab3282c402be256add765395b6f
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
Previously, the translucent boundary of AA lines would be scaled
by the line's transform. It should always be exactly one pixel wide
in screen space. This fix accounts for scaling for the boundary
region, and fixes some AA calculations that make wide/AA lines
more correct.
Change-Id: I30df2d5d96315bf3e7ff30be9735282fd5439a39
Bug #4343984
TextureView can be used to render media content (video, OpenGL,
RenderScript) inside a View.
The key difference with SurfaceView is that TextureView does
not create a new Surface. This gives the ability to seamlessly
transform, animate, fade, etc. a TextureView, which was hard
if not impossible to do with a SurfaceView.
A TextureView also interacts perfectly with ScrollView,
ListView, etc. It allows application to embed media content
in a much more flexible way than before.
For instance, to render the camera preview at 50% opacity,
all you need to do is the following:
mTextureView.setAlpha(0.5f);
Camera c = Camera.open();
c.setPreviewTexture(mTextureView.getSurfaceTexture());
c.startPreview();
TextureView uses a SurfaceTexture to get the job done. More
APIs are required to make it easy to create OpenGL contexts
for a TextureView. It can currently be done with a bit of
JNI code.
Change-Id: Iaa7953097ab5beb8437bcbbfa03b2df5b7f80cd7