Applications that create an icon for launcher to use couldn't determine
which size or density the icon should be created.
Bug: 3224340
Change-Id: Iee96113a4092696a9bd18eecbd2593b38f952a16
Notably, this removes exessive info about resources
from the content package, because it's not a good location
and the info is avilable in the dev guide, but also
added some of the info to the Resources class description.
Change-Id: Ie78af26c9cec66314deb98e53078f48e16c08e70
Um. My fix for calling onReceive() even after a receiver is
unregistered actually made it so onReceive() is never called for
the result receiver of a broadcast.
Change-Id: I30efe05d8fdec6fee4222b7d797f2b303073dbcc
...Invalid index 0, size is 0 at
android.app.ActivityThread.performPauseActivity(ActivityThread.java:2326)
It looks like if an arrow key is dispatched between the time the
list view is told its data set has changed and it does the resulting
layout pass, we could try to move the position to a now invalid
index. This may prevent that from happening.
Also put in a better error message if saving state of a fragment
whose target is no longer in the fragment manager.
And fix a bug in PackageManager where we could return a null from
queryIntentActivities().
And add a new API to find out whether a fragment is being removed,
to help fix issue #3306021: NPE at
android.app.AlertDialog.getDefaultDialogTheme(AlertDialog.java)
Next, for new HC apps we can delay committing data to
storage until the activity is stopped.
Finally, use the new multi-threaded AyncTask executor in a few
places, so we don't have worked blocked by long-running tasks from
the application.
Change-Id: I27b2aafedf2e1bf3a2316309889613fa539760f3
And also fix#3343369: EGL_BAD_DISPLAY and/or broadcast intent
TIME_SET before boot completion
And a few more tweaks to animations to keep the wallpaper displayed
when needed.
And make more use of the drag and drop "rotation disabled" thing to
also use it while animating the screen rotation, since if we try to
start a new rotation while doing the animation we end up with a mess.
Change-Id: I373af305a6e23a92835abed96229a83e173f67ce
This is a band-aid over the existing kludgy stopping mechanism
where the semantics of stop are different in the activity manager
than in the clients.
This change is intended to be as unobtrusive as possible, only
impacting the sleep case. I have a different change that
completely reworks how we stop activities to simply this all
a lot by unifying the semantics between the server and client.
However, it is too late in HC for such an extensive change. Later
I'll revert this one and put in the better solution.
Change-Id: Id77f2db1ec83469cdd888acb8fbc4679daa7766e
Misc stuff found after looking at the first day of data, Jesse's
review, and comments from Dianne about tracking Activity counts
better.
Change-Id: Ifee1ef8f59f41061d4aac8c02765627dbf3cd8e4
Don't deliver data arriving from a Loader after the application
has moved on to a new Loader.
Also throttle the number of Loaders will have actively running
for a particular ID.
Oh, and documentation. Documentation is good.
Change-Id: I5a5cfdbb8c9bfb320ffc014f99e37fe7e3001382
3362464 API REVIEW: android.content potpourri
3362445 API REVIEW: Fragment transaction stuff
3362428 API REVIEW: Fragment stuff
3362418 API REVIEW: Loader stuff
3362414 API REVIEW: android.content.pm.ActivityInfo
Change-Id: I6475421a4735759b458acb67df4380cc6234f147
* Add code to persist per-admin setting
* Add hooks for OS-level tie-in (is supported, get / set status)
* Add 3rd API call to get OS status (irrespective of admin settings)
* Remove "REQUESTED" status, no longer relevant with 3rd API
* Fixed bug that impacted global proxy settings
* Update api/11.xml to match current.xml
Bug: 3346770
Change-Id: I56bdf9a7894f6ca4842402c7b82ddb3caf4b37b9
ContentProviders are allowed to return null and both
of our contact directories (Focus and Exchange) actually
do when they find no data to return.
The problem is that when LoaderManager receives a result
from a loader, it checks if the result is the same as
previously received. That's fine, as long as the loader
always returns a different result. Now consider a loader
that returns null when it cannot produce the result.
What we are seeing is that if the loader is rapidly restared
and returns null twice in a row, the null is never
delivered to the callbacks.
In the case of the reported bug, the scenario is this:
1. We look for "foo"
2. Data for "foo" comes from a directory and we display it
3. We hit backspace twice in rapid succession. Each time
we hit backspace, the loader is restared, but since we do
this very fast, the second restart overrides the first. So
far so good.
4. The directories are programmed to return null if the
query string is less than 3 characters long, so the loader
returns null twice.
5. Loader manager looks at the final result, compares it
to the previous result and since they are the same (both null)
concludes that it does not need to deliver either of them.
6. The UI attempts to show the stale data and blows up
Bug: 3352125
Change-Id: I3e5bc505faa03f72ebe5cb010377a740f5c7d5b6
Also hide the bitmap thumbnail stuff, we can't support it in its
current form.
And fix some bugs with propagating paths to native code. Yikes!
Change-Id: I13ab37ddbdba5c073489cba5eab035117d3c1574
You can now do android:largeHeap="true" on an application.
Doesn't yet do anything, waiting for Dalvik API.
Also tweak package parsing so that the SDK API level is set in the
configuration, allowing manifest resource value selection based on
that.
Change-Id: I6e035f9702a97b055416743b88f83a22ba4a9584
docs: Rewrite of App Fundamentals.. Part 2.
This introduces three new docs:
Services:
Provides an introduction to using services and describes the
service lifecycle (previously in the "Component Lifecycles" section
of the fundamentals.jd document)
Bound Services:
A guide for services that offer binding.
AIDL:
A doc about using AIDL (primarily for creating a service interface)
Also includes edits to IntentService javadocs to clarify
different behaviors for some callback methods
Includes a new version of the services lifecycle diagram
and an additional diagram for determining onRebind()
These files are orphaned for now---they're not linked in the sidenav,
until I get the last couple documents submitted for the app fundamentals.
Change-Id: I7fb0a8faff1f18b7d6b9a7b59f66f55a1b6168f1
* New uses-policies value
* Definitions for storage domain and encryption status
* API to get and set encryption status
* Intent to launch encryption changes
* Both new calls bottom out in the DPM service and are suitable for
a device that does not support encryption.
NOTE: Nobody should use ACTION_START_ENCRYPTION yet. It needs a receiver
to be built in Settings (different CL).
Change-Id: I2ae193bedbec59f6ba46c0ec7de12ecf321e5803
