Since the new API prepare for stateful layoutlib, major
reorganization of the code.
New "android" sub-package for all extended android classes.
Also moved BridgeInflater in here so that all extended classes
are in this package. Only delegates and classes replacing
renamed classes are in their original android.* packages.
Also created full file for the empty implementations of
IWindow and IWindowSession.
New "impl" for the dirty work implementation.
Main package contains the basic implementation of the API.
Most of the code that was in Bridge is now in .impl.LayoutSceneImpl,
with the main init/inflate/render code split into the contrustrutor,
inflate() and render().
Change-Id: Ie15b15e5a1b2388cd6ef82e518345b1fc02ec981
This change does the following:
- Make the bridge context extend Activity instead of Context
so that it can act as a view factory. This is needed because
the Activity is used as factory for Fragment objects.
- Override the default Fragment.instantiate(...) method
through a delegate. This is done to load the Fragment
classes located in the project (similar to custom views).
Change-Id: If62e7c9ff2b7585677077ad825aa1c3591d1b5e0
While the difference is pretty minor since it's a small class,
the point is that the unit test will ensure that we detect
new methods added to FloatMath more easily.
Change-Id: Ia8bfee231cc4ae0cfeb18692be86d02649c187d5
Also fix native delegate generation to put "this" parameter even
for methods that don't have any parameters.
Change-Id: I5dd0c505871370ff7b4cda16de84a5b3ae438f73
This does not implement all the native methods of the
android.graphics.Bitmap class, only what's needed to draw an
ImageView object. The rest will be implemented after Canvas and
Paint have been moved to the native delegate.
Change-Id: Ia0c3b2cafa03871c298deaef5817a25ac1c35521
Instead this uses the actual output of layoutlib_create, which is
all the modified classes before the content of the bridge is added
to form layoutlib.
Change-Id: I22755f38800cd69206834ff9594a99cb0c1d2139
Instead of renaming the old Matrix class into _Original_Matrix
and have layoutlib provide a full new implementation of Matrix,
we keep the old one by only modifying it to implement the native
methods which calls out to a new Matrix_Delegate class.
The goal is to not have to maintain the java portion in
sync between the framework and the layoutlib version.
Change-Id: I3e1aefffbae45e91b75331c0c6ff2260323deacd
Framework resources loaded through Drawable.createFromXml could
be overriden by project resources if there were loaded through
a state list drawable where the final resource name was used
by a project resource (of the same type).
This ensures that the XML parser knows that it's a framework
resource being parsed and that the resource resolution uses
that information.
Change-Id: I39cf9eba755e55f1604b968637aeecff969a558d
DragEvent.getResult() returns 'true' if the drop was ultimately accepted;
false otherwise. The validity of this datum is only guaranteed when the
DragEvent's action verb is ACTION_DRAG_ENDED.
Also fixes the drag-start timeout handling (though the offending app is
not yet officially declared ANR).
Implements bug 3097807
Change-Id: I6908ac628c72ff7d6193d87060d769a559a78d0e
A View initiates a drag-and-drop operation (hereafter just called a "drag")
by calling its startDrag(ClipData) method. Within the processing of that
call, two callbacks are made into the originating View. The first is to
onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this
callback must respond by calling setDragThumbnailDimension(width, height) to
declare the size of the drag thumbnail image that should be used. Following
this, the View's onDrawDragThumbnail(canvas) method will be invoked to
actually produce the bits of the thumbnail image.
If all goes well, startDrag() will return 'true', and the drag is off and
running. (The other arguments to startDrag() provide reconciliation between
the current finger position and where the thumbnail should be placed on
the screen relative to it.)
Potential receipients of the ClipData behind the drag are notified by a
new dispatch mechanism, roughly parallel to motion event dispatch. The core
routine is the View's onDragEvent(event) callback, with the mechanics of
dispatch itself being routed through dispatchDragEvent(event) -- as in
the case of motion events, the dispatch logic is in ViewGroup, with leaf
View objects not needing to consider the dispatch flow.
Several different event 'actions' are delivered through this dispatch
mechanism:
ACTION_DRAG_STARTED: this event is propagated to every View in every window
(including windows created during the course of a drag). It serves as a
global notification that a drag has started with a payload whose matching
ClipDescription is supplied with the event. A View that is prepared to
consume the data described in this event should return 'true' from their
onDragEvent() method, and ideally will also make some visible on-screen
indication that they are a potential target of the drop.
ACTION_DRAG_ENTERED: this event is sent once when the drag point
enters the View's bounds. It is an opportunity for the View to set up
feedback that they are the one who will see the drop if the finger goes
up now.
ACTION_DRAG_LOCATION: when the drag point is over a given View, that
View will receive a stream of DRAG_LOCATION events, providing an
opportunity for the View to show visual feedback tied to the drag point.
ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point
leaves the View's bounds. The View should undo any visuals meant to
emphasize their being the hovered-over target.
ACTION_DROP: when the drag ends at a given point, the View under that
point is sent this event, with the full ClipData of the payload.
ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global
broadcast that the drag has ended and all Views should return to their
normal visual state. This happens after the DROP event.
Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
I can't find the bug number for this, but it is needed for some things
we are doing where the app building an intent may not have access to the
URI in the data field. This is for HC, but doing in GB to avoid introducing
integration issues.
Change-Id: I0cac971854198b18775d2a73deb80f23431bfbe2
I can't find the bug number for this, but it is needed for some things
we are doing where the app building an intent may not have access to the
URI in the data field. This is for HC, but doing in GB to avoid introducing
integration issues.
Change-Id: I0cac971854198b18775d2a73deb80f23431bfbe2
- Change semantics if IDs associated with these fragments, to
work correctly when placed in a container. If the container
has an ID or you have supplied a tag, the fragment's ID is
optional.
- To do this, there is a new LayoutInflater API that allows code
creating views to access the parent container that view will
be in.
- Fix issues with state management around these fragments. Now
correctly retains state when switching to a layout that doesn't
include the fragment.
Also:
- Add new simple list layouts for items that want to show an
activated state.
- Add new Activity.dump() that can be invoked with adb shell
dumpsys; the default implementation dumps fragment state.
Change-Id: I192f35e3ea8c53fbd26cf909095f2a994abfc1b6
The makefile variable USE_OPENGL_RENDERER must be set to true to compile
libhwui and the related code in the JNI layer.
This change also removes obsolete APIs from Canvas that must not be used
and would be confusing if left in. These APIs were remnants of our first
attempt at an OpenGL renderer for the view hierarchy and had not been
taken out before Android 1.0 was released.
Change-Id: I2475ff1307212bab26c926724f3c508681c7dae1
It would change the text rendering info but not recompute
the Java Font objects. The effect is a broken font rendering
in the EditText (which use this method to copy some Paint
object before using the copy for the actual drawing)
Change-Id: I9e7fbf9bd57b421fd793876a6de4ade1ecac372d
It would change the text rendering info but not recompute
the Java Font objects. The effect is a broken font rendering
in the EditText (which use this method to copy some Paint
object before using the copy for the actual drawing)
Change-Id: I6d8d1bf86f0d77d088f60ad81c71dd3ebab727b0
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
add new method openOrCreateDatabase in Context.java to allow
callers specify a DatabaseErrorHandler object to be used when
database corruption occurs.
add new constructor in SQLiteOpenHelper to accept DatabaseErrorHandler
as an additional param to be used when SQLiteDatabase instance is
created.
Change-Id: I912a0202a74510f9ca0206dd8101c4abab9102ae
Well, mostly. There is still a problem here where the first time
you show the lock screen it just doesn't draw itself. I assume
this is something breaking in the view hierarchy as it floounders
around removing and adding new views as it is first being shown...
but no idea at this point what is the actual case.
Change-Id: Iba99ae3242931c8673b17b106c86fc99e2c52abe
This is the framework part, moving classes around so the framework
no longer needs to link to android-common. Makes some APIs public,
others that didn't need to be public are private in the framework,
some small things are copied.
This is a bunch of reworking of how configuration changes are handled:
- When orientation is changing (for whatever reason), the window manager no
longer tries to pre-emptively compute a new configuration. Instead, it
just determines change is happening and tells the window manager.
- The activity manager is now responsible for giving the window manager the
final configuration it is using. This is both so it knows whem the
activity manager is done with its configuration updates, and so the window
manager can use the "real" configuration.
- When an orientation or other configuration change is happening, freeze the
screen and keep it frozen until the activity manager has given us the
final configuration.
- The window manager can now send new configurations to its clients during
its layout pass, as part of a resize, if it has determined that it has
changed. This allows for a new View.onConfigurationChanged() API for any
view to easily find out when the configuration has changed.
- ViewRoot now also works with the activity thread to make sure the process's
current resources are updated to the new configuration when it receives one
from a window. This ensures that at the time onConfigurationChanged() and
other view callbacks are happening, the correct configuration is in force.
- There is now a sequence number associated with Configuration, which
ActivityThread uses to avoid using stale configurations. This is needed now
that it can receive configurations asynchronously from both the window
manager and activity manager.
- The hack for keeping the locale has been removed, and underlying problem
fixed by having Configuration initialize its locale to "unknown" instead of
a valid default value.
