For specific methods, Layoublib_create can rewrite the implementation
of a method to invoke a delegate instead of the original code. This
allows layoutlib to implement native code or override existing behavior.
This patch also 'saves' the original implementation of a rewritten
method so that the delegate can access the original implementation
as needed. Obviously this is only done for non-native methods.
Given a non-native SomeClass.MethodName, we generate 2 methods:
- A copy of the original method named "SomeClass.MethodName_original".
The content is the original method as-is from the reader.
- A brand new implementation of SomeClass.MethodName which calls to a
non-existing method named "SomeClass_delegate.MethodName".
The implementation of this 'delegate' method is done in layoutlib_brigde.
Change-Id: I5ca2cd3ac55991a8e8a51c417e75ee447bf9e9e6
Fix zombie threads in the Layoutlib.
Some widgets can create (indirectly) HandlerThread which are started
but never stopped.
This patch use the delegate methods to override the thread run method
to record which threads are started to be able to call quit() on them
after a render.
Note that we should really fix layoutlib_create to be able to call
the default implementation from a delegate to remove code duplication.
Change-Id: Iaf5432623e9704bb3114a8e0583c8553282c205e
LayoutLib: custom styles override the default style instead of replacing it.
Intead of reading either the custom or the default style for a widget, we
read both and use the values from the custom style if it exists, or
from the default style otherwise.
Change-Id: Ibcec2e9b1e8a95295ab26ede145c287ff2f30be4
LayoutLib: Fix issue where <include> with no layout params wouldn't display.
The issue is that the layout params from the root element of the included
layout should be used but this failed because loading the layout params
from the <include> tag didn't throw a RuntimeException in our modified
code (BridgeTypedArray).
Because we don't want to throw exception in general we only throw it
when reading the layout params of an include node which is pretty crappy,
but works for now.
Change-Id: I83ccf956e8b476f34dfc9a70aebae2288d53746e
LayoutLib: Fix issue with rendering mode.
When the layout content is embedded inside a decor layout
to emulate system bar (top or bottom) and title bar (or action bar)
then the code computing the full required size based on the RenderingMode
would fail because the decor layout would prevents the content layout to
take as much room as possible.
There is also an issue with the way we know render dialogs as the
dialogs usually as a frame with some padding and the previous measurements
would not take into account the dialog padding when increasing the
screen size.
This fix makes the code measure the size of the content layout in the
normal rendering, and then separately from the root layout with the proper
MeasureSpec to let the content grown. The difference in size is then added
to the screen size.
Bug: http://code.google.com/p/android/issues/detail?id=15892
Change-Id: Ie9a6c5e254b16785f817dcb9fae755d4936880aa
LayoutLib: fix Capabilities and getDimensionPixelSize
Commented out a Capability that is not in ADT 10.
BridgeTypedArray.getDimensionPixelSize shouldn't call
getDimension since most of the code is duplicated, and
it prevents use from properly detecting malformed attribute
values.
Change-Id: I008334af605a89f240247a13c0024009247ec5af
LayoutLib: Fix dimension parsing to handle negative value.
Also make TypedArray.getDimensionPixelSize properly
handle negative values (which are not allowed).
Change-Id: I03ffcef5ab7ec7ef95419566776dcc798845fd88
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
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
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
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
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.
The device mode is now called ui mode. Furthermore is the order of
precedence for the resources now in such a way that the ui mode needs
to be specified after the orientation and before the density.
The ui mode can be set, like it is done for the locale, as follows:
IActivityManager am = ActivityManagerNative.getDefault();
Configuration config = am.getConfiguration();
config.uiMode = Configuration.UI_MODE_TYPE_CAR | Configuration.UI_MODE_NIGHT_ANY;
am.updateConfiguration(config);
To allow users to disable the car mode and set the night mode the IUiModeManager
interface is used.
The automatic night mode switching will be added in a separate change.
This implements the spec for external storage organization, and
properly reflects how the media scanner organizes the files it finds.
Also includes package manager support for removing app private
files from external storage when the application is uninstalled.
For the new APIs and paths, the main place to look is Environment
and Context.
Merge commit '31ef2e77c50485ad6ed410a5d341754d6787b8e1'
* commit '31ef2e77c50485ad6ed410a5d341754d6787b8e1':
ADT/Layout: support for 3+ color in linear gradients
