Restore runs during the SetupWizard, before the phone is usable per se, so we
want to avoid presenting the usual "Application whatever has crashed..." dialog
to the user in the middle of that process. This change modifies the exception
handling around agent bringup so that agent-originated exceptions are caught and
a null agent binder reported to the backup manager.
There are three points during this code sequence at which an exception can be
thrown due to application-code error:
+ the app's manifest can name a nonexistent or malformed BackupAgent class,
incurring a VM-level exception like ClassNotFound or BadCast.
- the agent's onCreate() method could crash/throw.
- the agent's onBind() method could crash/throw.
The new code arrangement here puts a try/catch around all of these possible
failure points. When the code is invoked for backup, any caught exception is
merely rethrown. During restore, however, execution is allowed to proceed
through reporting the app's agent binder back to the activity manager. If any
exception was thrown, this reported binder will be null, i.e. a clean failure
notification to the backup manager.
What this code does *not* do at present is tear down the app when an exception
has been thrown. This is happens if the exception is allowed to propagate.
Doing so cleanly is problematic, however, in circumstances where mutiple apps
and agents share a process. Leaving the background process around until it is
torn down by the usual policies is probably the safer course at present.
We support a ColorStateList reference now as a valid font color value
in the given html and manage html strings for all supported states
which we dynamically set while drawing the items.
This will get checked in along with changes to GlobalSearch,
EnhancedGoogleSearchProvider and Browser to make them use the new
model.
Bug: http://b/issue?id=1865037
Before it was hidden in cancel(), which does not get
called when the search dialog is dismissed by clicking
on a suggestion.
Fixes http://b/issue?id=1967633
Details:
- Add a new SearchDialogWrapper class that makes sure
all access to the SearchDialog is run one a single thread
other than the main ServerThread.
- Don't save/restore seach dialog state in Activity.
This resulted in lots of calls to the SearchManager
throughout the life cycle of all activities, for
the questionable benefit of restoring the search dialog
in a few cases.
- Remove search UI state save/restore, and the isVisible()
method from SearchManagerService. They are no longer used,
and were tricky to implement since they return values from
the search UI thread to the service.
- Handle configuration changes in searchDialogWrapper instead
of calling through from Activity.
Fixes http://b/issue?id=1938101
TODO:
- Activity.performPause() calls stopSearch(). This call may not happen
until the new activity has been started. If the new activity starts a
search immediately, this search could be cancelled by the old activity's
call top stopSearch().
If provided and true, URLs entered in the search dialog while searching within this activity would be detected and treated as URLs (show a 'go' button in the keyboard and invoke the browser directly when user launches the URL instead of passing the URL to the activity). If set to false any URLs entered are treated as normal query text.
The default value is false. This is an optional attribute.
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.
did not seem to expand to show the corpus selectors. (http://b/1906643)
It turns out that when the trackball was used to select this item, onItemClick
was getting called on the listener twice in AutoCompleteTextView#onKeyUp:
once when we call onKeyUp on the DropDownListView, and once a little further
down when we call performCompletion(). In our case, performCompletion() is
useless since it was intended for normal AutoCompleteTextViews which populate
text into the TextView when an item in the list is clicked, but we do not
rely on this. So the easiest fix is just to make performCompletion() do nothing
in our SearchAutoComplete subclass.
On invoking the search UI, the drop down list box with past queries and shortcut items
appears after a few hundreds of milliseconds on screen. This was because we were
displaying the drop down within the onFilterCompleted callback after the list box filtered
the items based on the given query text. While that code path is necessary, for the first
invocation of the search dialog with an empty query we can show the list box before the
text stuff happens. This change does that, issuing an async request to show the drop
down after pending events have been processed.
Without this change, on an average it took 350ms for the code to show the drop down.
With this change, on an average it takes 150ms.
update config changes in Resources.mSystem
Since Resources is preloaded in the zygote, system resources in Resources
need to be updated with config changes every time an application is started
The am command is now the one that takes care of opening the target file,
handling the opened file descriptor to the process that will be profiled.
This allows you to send profile data to anywhere the shell can access, and
avoids any problems coming up from the target process trying to open the
file.
app for search. (This started when we moved to system process, not sure
why then, but we should be getting the dropdown to update at this point
regardless.)
is full-screen width but has rounded corners on the bottom so it doesn't
look crappy if the list is not full-screen height. This was already
being used for in-app search, so I just got rid of the old global search
background and use the in-app one for everything.
By removing the lines in SearchDialog, I'm causing it to rely on the
value specified for the dropdown background in
frameworks/base/core/res/res/layout/search_bar.xml.
This change adds a new intent extra field USER_QUERY set in intents
launched by the search dialog. It contains the query as typed by
the user, unaffected by query jamming or search suggestions.
Fixes http://b/issue?id=1939592
Adds this to the instance state bundle:
- mStoredComponentName
- mStoredAppSearchData
- mPreviousComponents
All the UI selection fields that were previously saved were removed.
It's not necessarily useful to restore the
selection, and it's hard to get right. The old code was buggy
(see http://b/issue?id=1911660) and did not restore the
list selection because that's quite hard.
Fixes http://b/issue?id=1926174
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.
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
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.
- 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.
This introduces a new Uri form of Intent with an "intent:" scheme, and a
corresponding update to the parser to handle these, so that the browser
can use this generic facility for starting activities based on the links
that are clicked and allow for web pages to link to arbitrary intents.
There is also a new "package" field on Intent which allows you to limit
the components it finds to a given package. This replaces the new method
that was added to PackageManger for doing this when resolving activities,
and implements it for all Intent queries against the package manager.
Create a new public IntentSender class that can be used by PackageManager instead.
This new class uses IIntentSender internally and can only be created by PendingIntent for now.
Provide a new getIntentSender api in PendingIntent to create an instance of this class.
Move IIntentSender and IIntentReceiver from android.app to android.content
Change imports of IIntentSender and IIntentReceiver to reflect the new package name
The PackageManager api has been named as freeStorageWithIntent and will be renamed as freeStorage
once the older api(which has been deprecated) will be removed shortly.
- Instead of passing the suggest provider component name as the field
EXTRA_DATA, we now pass via the field COMPONENT_NAME
- Kept EXTRA_DATA field as is so we can use it for real extra data.
commit 9798cd23605c96c1d6a29202f4d31f5454079b61
Author: Mitsuru Oshima <oshima@google.com>
Date: Tue Jun 16 13:50:44 2009 -0700
Made other toShortString in performDestroyActivity safe.
commit 19bf973df81d9d01210effb39c99e5236f2229c1
Author: Mitsuru Oshima <oshima@google.com>
Date: Fri Jun 12 15:50:03 2009 -0700
* component can be null after destory?
This was causing NPE in catch block, which hides the actual exception.
Conflicts:
core/java/android/app/ActivityThread.java
This change removes all location code from the
system search dialog. The code was out of sync with
the EnhancedGoogleSearchprovider, and was possibly
responsible for some network location provider
crashes.
Instead we will try to make EnhancedGoogleSearch persistent, so that
it has a reasonable location most of the time.
