- scale the matrix
- but don't scale if the matrix *looks* like obtained from the canvas itself. (typically to set it back to original matrix)
This is best effort change and not perfect (not even close), but works for one game,
and hopes it can handle many other apps that uses set/get Matrix. If you have an alternative idea, please let me know.
* More surface view fix.
- correct event translation on surface view.
- use compatible window
* removed FLAG_NO_COMPATIBILITY_SCALE. It was my misunderstanding of how SurfaceView works, and this was not necessary.
* Added compatibility related info to package dumpsys
* preserve compatibility window flag when the app updates window's layout params.
* Added assertion in DEFAULT_COMPATIBILITY_INFO object to prevent unintentional modification.
* A few minor updates
* log/dump message improvement
* Removed unnecessary method in FadeInOutAnimator
* Fixed 100 char issue in WindwoManagerServer.java
ViewRoot keeps a reference to the previously focused View and use this reference
when trying to scroll the window to the focused rect. There situations however
in which the previously focused view might have been removed from the view
hierarchy. This happens on Home for instance when you trash an icon, or with
ListView's items. This change ensures the previously focused view is still part
of the view hierarchy.
* added background filler surface to fill the outer rim. Using the same layer as dim surface because
they never co-exists (in the same window)
* clean up the obsolete code in CompatibiltyMode/ViewRoot for support large screen support.
A restricted Context is a special type of Context that prevents specific features
from being used. For instance, android:onClick, used by View, can be dangerous when
used from within apps widgets. By using a restricted Context to inflate apps widgets,
widgets providers are prevented from using android:onClick.
There is a compatibility issue with the cupcake IME where the generic
input connection would just consume actions. Late in cupcake this
stuff was reworked so that the IME would send an action command
to the app instead of an enter key event, and the compatibility code
got lost.
This change fixes issues with existing applications that access the drawing cache
directly. The API now lets application choose whether they want to get a scaled
drawing cache or not. The framework relies on the scaled cache for quality
purposes.
* use full window for activities, and shift & clip the content
* refactored the compatibility code, and introdcued Translator class to handle cooridnate translations.
* removed a workaround to handle an activity with configChagne=rotation in old implementation.
* I'll fix background issue on rotation in next CL.
* removed unnecessary scaling code in SurfaceView, which I forgot to remove when I changed SurfaceView
not to scale the content.
These are all variations of needing to validate ranges on editing operations
coming from the IME, to account for the underlying text changing (usually being
deleted) asynchronously with the IME.
ViewGroup was trying to access the AttachInfo without checking whether the
info object is null. The object can be null at varioous times in the lifecycle
of a list.
* adding compatibility menu
* backup gravity
* set expanable=true if the screen size is hvga * density.
* added "supports any density" mode. I'll add sdk check later.
* disallow to catch orientation change event if the app is not expandable. This
was causing layout problem under non-expandable mode. I discussed this with Mike C
and we agreed to do this approach for now. We'll revisit if this causes problem to
a lot of applications.
* Refactored Compatibility code
* Added CompatibilityInfo class
* Removed getApplicationScale from Context
* Added Resources#getCompatibilityInfo so that RootView can get the compatibility info w/o going through Context
* Expandable support
* Added expandable tag under manifest
* Old application w/o expandable is given the default screen size ([320, 480] x density).
* The non-expandable window is centered.
This adds a new window type that is a surface that sits between the
current media type and the application window, in theory allowing you
to have two surface views in your hierarchy and control their
Z-ordering. There is also another hidden API on SurfaceView to set
the type of your window.
All a big hack, but for the good of the commonwealth!
* changes:
New feature to track down #1846038. Adds the ability to export flags encoded in int values so as to make them human readable in HierarchyViewer.
* don't scale LayoutParams (this must be app's scale).
* scale the layout params' coordinates & size only when requesting layout.
In SurfaceView, window's x,y wasn't scaled before sending to window manager.
* changes:
Density Compatibility mode for SurfaceView * use fixed size when requested. Otherwise, give the original size instead of scaled down size. * scale back the motion event to original size when surface view is using the orignal size.
* use fixed size when requested. Otherwise, give the original size instead of scaled down size.
* scale back the motion event to original size when surface view is using the orignal size.
