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.
Fixes http://b/issue?id=1905863
This is needed to address two security issues with global search:
http://b/issue?id=1871088 (Apps can read content providers through GlobalSearch)
http://b/issue?id=1819627 (Apps can use GlobalSearch to launch arbirtrary intents)
This also fixes http://b/issue?id=1693153 (SearchManager.OnDismissListener
never gets called)
To fix the security issues, GlobalSearch also needs to require
a non-app permission to access its content provider and launch intents.
With the new implementation of using a SuggestionItemView, we no longer need to draw a solid background for all items in the suggestion listview. Hence removing the code to draw a default white background, and make the item transparent so the listview-drawn selection hilite shows through.
I've used a simple approach of not drawing the solid background color for the selected item, thereby letting the default selection background to show through properly. This works by using the item's 'pressed' state and redraw code which are used by the listview during the tapping operation.
