Also, set FLAG_ACTIVITY_NEW_TASK to allow launching
global search from non-activity contexts.
Fixes http://b/issue?id=2460991
Change-Id: I833d5b851f0127fb69165fbfc7d1ee190b320401
The ui modes can be controlled with the UiModeManager class, which
is can be retrieved as a system service via getSytemService(Context.UIMODE_SERVICE).
The class is necessary so that CarHome can be unbundled and other apps can
disable the car mode. Its currently a hidden class, since I'm not sure if this
is the best way to provide this functionality to the user.
I am getting tired of writing package monitor code, realized this is missing in
a number of places, and at this point it has gotten complicated enough that I
don't think anyone actually does it 100% right so:
Introducing PackageMonitor.
Yes there are no Java docs. I am still playing around with just what this
thing is to figure out what makes sense and how people will use it. It is
being used to fix this bug for monitoring voice recognizers (integrating the
code from the settings provider for setting an initial value), to replace
the existing code for monitoring input methods (and fix the bug where we
wouldn't remove an input method from the enabled list when it got
uninstalled), to now monitor live wallpaper package changes (now allowing
us to avoid reverting back to the default live wallpaper when the current
one is updated!), and to monitor device admin changes.
Also includes a fix so you can't uninstall an .apk that is currently enabled
as a device admin.
Also includes a fix where the default time zone was not initialized early
enough which should fix issue #2455507 (Observed Google services frame work crash).
In addition, this finally introduces a mechanism to determine if the
"force stop" button should be enabled, with convenience in PackageMonitor
for system services to handle it. All services have been updated to support
this. There is also new infrastructure for reporting battery usage as an
applicatin error report.
Because some apps make SQLite database names containing email
addresses, we take care not to log those email addresses in the
EventLog, so other apps with READ_LOGS access can't read them.
This change fixes a problem where an unwanted tone is generated by audio policy manager when a MT call is answered.
This is because of a policy that replaces high visibility system sounds (ringtones, alarms...) by a beep when in call.
There is a transitory phase while the call is being answered where the phone state is changed to IN_CALL but the
ringtone is still playing. The audio policy manager then mutes the end of the ringtone and starts playing a beep
in replacement because the ringtone is categorized as high visibility.
The fix consists in changing the ringtone stream type from high visibility to low visibility. This is not a problem as
the only actual use case where a ringtone would be generated while in call is if another call is received.
But in this case, the phone system does not generate a ringtone but a call waiting tone instead.
It is therefore not required to handle a ringtone as a high visibiltiy tone that must be somehow signaled to the user
while in call.
Add a Flattenable interface to libutils which can be used to flatten
an object into bytestream + filedescriptor stream.
Parcel is modified to handle Flattenable. And GraphicBuffer implements
Flattenable.
Except for the overlay classes libui is now independent of libbinder.
Don't go looking at attributes of a package struct without first verifying
that the struct pointer is non-null: in the failed-install case, of course
there will be no package info.
Change-Id: I3b2cafca2f1e3891a6592825ce5bcc977e7f3483
A lot of this documentation isn't even true of the G1, let alone Froyo running
on a Nexus One. Distinguish between truth and fiction, clarify where the JIT
affects things, and clarify certain confusions (such as the difference between
intrinsics and native methods).
I still need to include updated performance numbers in the final section. I
should also make the benchmark code available so that people don't have to
take our word for these things, and so it's easier for them to get an idea of
the performance of future devices and builds. (Though hopefully we can update
this every release in future.)
Anyway, just removing the untruths is a big step forward.
