order.
The new implementation uses a dually topologically sorted graph of the child
views. The graph of dependencies is sorted once for the rules that impact the
horizontal axis (toLeftOf, alignRight, etc.) and once for the rules that impact
the vertical axis (above, below, etc.)
Doing so gives the ability to declare dependencies in any order, allows for
partial cycles in the graph (given view1 and view2, view1 can be toRightOf=view2
and view2 can be above=view1) and probably gets rid of most surprising behaviors
of RelativeLayout.
This change amends the doRestore() / onRestore() interface to backup agents to
provide the integer android:versionCode of the app that stored the backup set.
This should help agents figure out how to handle whatever historical data set
they're handed at restore time.
This is to fix bug http://b/issue?id=1931983
Instead of changing the keyboard button from search to carriage return,
I have changed it from search to 'Go' which I find more useful since
it indicates that the user can now go to that URL.
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.
* changes:
Helper API cleanup. Allows multiple helpers to function, because they'll always go in the same order, and this lets us not have to write headers to keep them paired.
They were only static because of a now removed restriction that
only activity contexts could instantiate SearchManager.
This only changes hidden APIs, but all users of the changed methods
must be updated to use them non-statically before this is submitted.
Since https://android-git.corp.google.com/g/3880
all activities create a SearchManager object, to handle
saving and restoring the search dialog. This broke
ActivityUnitTestCase, since ApplicationContext.getSearchManager()
threw an exception in non-activity contexts.
This change removes the activity context check from
getSearchManager(). Since SearchManager is now just a thin
wrapper for SearchManagerService, there shouldn't be anything
activity-specific in it.
Fixes http://b/issue?id=1926254
It doesn't make much sense to ellipsize the text entered by the user, so we
just ellipsize the hint. This avoids introducing a new XML attribute/Java API
just for the particular case of ellipsizing the hint.
The check for allowing the start of an activity was broken, it was
comparing the process of that activity's application vs. the current
instrumentation target package name. Okay it was utterly insane.
Now this check is that the target activity will be running in the
same process as the instrumentation, which is really what we want.
This is a monotonically increasing integer. Wraps to 0 at
Integer.MAX_INT, and at boot.
Current implementation returns the number of AT commands handled since
boot. This is a good indicator for spammy headset/handsfree units that
can keep the device awake by polling for cellular status updates. As a
rule of thumb, each AT command prevents the CPU from sleeping for 500 ms
Eat the security exception that is now thrown by the window manager to
retain the old behavior for tests. (We still need to throw the
exception from the WM for the new permission tests.)
- Fix a bug where targetSdkVersion could not be set if minSdkVersion. Stupid, stupid.
Also make sure to fail if minSdkVersion is for a code name. Really stupid.
- Change the API for resize compatibility mode to be a bit in the flags field, instead
of a separate boolean.
- Implement delayed dexopting, to avoid the looong full dexopt during boot. This is
only enabled for "eng" builds. When in this mode, the activity manager will make
sure that a dexopt has been done before loading an .apk into a process, and will
try to avoid displaying ANRs if they are due to the dexopt causing some operation
to take longer than it normally would (though I make no guarantees about this
totally working).
- Add API to Context to get the ApplicationInfo for its package, for easy access to
things like targetSdkVersion.
