This makes the system a little more careful to not start third party
code until it is ready to.
Also fix a little bug in SyncManager that would cause it to crash
during boot if sync was in a failure state.
Change-Id: Ib2d287d8441d155d393fe740a5f98690895fd358
This will be used to allow running dumpstate as root from the init process
to enable gathering debugging information that requires root to access.
Change-Id: I5bb7e83071fad2b377e549058f318a5118194061
Signed-off-by: Mike Lockwood <lockwood@android.com>
This addresses a few parts of the bug:
- There was a small issue in the window manager where we could show a window
too early before the transition animation starts, which was introduced
by the recent wallpaper work. This was the cause of the flicker when
starting the dialer for the first time.
- There was a much larger problem that has existing forever where moving
an application token to the front or back was not synchronized with the
application animation transaction. This was the cause of the flicker
when hanging up (now that the in-call screen moves to the back instead
of closing and we always have a wallpaper visible). The approach to
solving this is to have the window manager go ahead and move the app
tokens (it must in order to keep in sync with the activity manager), but
to delay the actual window movement: perform the movement to front when
the animation starts, and to back when it ends. Actually, when the
animation ends, we just go and completely rebuild the window list to
ensure it is correct, because there can be ways people can add windows
while in this intermediate state where they could end up at the wrong
place once we do the delayed movement to the front or back. And it is
simply reasuring to know that every time we finish a full app transition,
we re-evaluate the world and put everything in its proper place.
Also included in this change are a few little tweaks to the input system,
to perform better logging, and completely ignore input devices that do not
have any of our input classes. There is also a little cleanup of evaluating
configuration changes to not do more work than needed when an input
devices appears or disappears, and to only log a config change message when
the config is truly changing.
Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
Partial fix for http://b/issue?id=2081673
This prevents a crash. However, if the user continues typing
into the textfield, the selection is incorrect. The real solution
(forthcoming), will make sure that the WebTextView's text gets
updated when webkit updates.
Change-Id: Ic832ec48fd4236c8116c5cbda1467677ad731feb
* changes:
Make new attribute EXTRA_CHANGED_COMPONENT_NAME in broadcast intent ACTION_PACKAGE_CHANGED public so that apps like launcher can find out the changed component name when loading changes made in components.
broadcast intent ACTION_PACKAGE_CHANGED public so that
apps like launcher can find out the changed component name
when loading changes made in components.
* changes:
For intent ACTION_PACKAGE_CHANGED, there could be a lot of broadcasts related to enabling/disabling components by apps which could result in thrashing on the PackageManager. For apps that do not want to be restarted when such a broadcast is sent, we can just aggregate these broadcasts and handle them at one go. Changes include: New structure to hold pending broadcasts by class name. If a component is enabled or disabled frequently aggregate component enabled/disabled settings in this structure in a 10 second window and then send out the accumulated list of broadcasts to the ActivityManager. A new Handler implementation handles this message Add new attribute name EXTRA_CHANGED_COMPONENT_NAME in broadcast intent Intent.ACTION_PACKAGE_CHANGED for additional information for apps like Launcher. Rename a couple of parameters, the names were too jarring.
Certain carrier websites allow sending SMS to phones on their network. They allow filling
out a "Reply to Address" which can be a phone number. The website may send that message to
the device as an SMS-to-email, but the "From" address will be an SMS short code and not a
valid email address. When the user replies to this message, the response is directed to the
short code and not delivered correctly.
In extractEmailAddressFromMessageBody(), currently it checks if the sender is a shortcode
and an email address is present as the first word in the message body. If so, it replaces
the email address as the sender replacing the short code.
The fix to support the above case is remove the email address check and treat the first word
as FROM address regardless of what the user types.
Change-Id: Ifd39a39b352f204024c76fde293164dcd2b0896b
components by apps which could result in thrashing on the PackageManager. For apps that
do not want to be restarted when such a broadcast is sent, we can just aggregate these broadcasts and
handle them at one go.
Changes include:
New structure to hold pending broadcasts by class name. If a component is enabled or disabled frequently
aggregate component enabled/disabled settings in this structure in a 10 second window and then
send out the accumulated list of broadcasts to the ActivityManager.
A new Handler implementation handles this message
Add new attribute name EXTRA_CHANGED_COMPONENT_NAME in broadcast intent Intent.ACTION_PACKAGE_CHANGED for
additional information for apps like Launcher.
Rename a couple of parameters, the names were too jarring.
Unfortunatley, shutdown() on the underlying fd does not actually stop a
listening socket from listening. You need to call close() on the fd to
do this. There is no way around it.
So this means the Java BluetoothSocket code has to call destroyNative() during
BluetoothSocket.close().
Since native methods cannot be called after destroyNative(), add a ReadWrite
lock and mClosed field to protect access to native methods.
This fixes the "resource busy" error when Bluetooth OPP and Bluetooth PBAP
tried to resume listening after turning BT off and then on.
we keep book and only read a particular file once and send it to the server.
The files are:
Ramconsole Driver (Dream/Sapphire):
/data/dontpanic/last_kmsg
Apanic Driver (Sholes/all future designs):
/data/dontpanic/apanic_console
/data/dontpanic/apanic_threads
