The use of FLAG_RECEIVER_REPLACE_PENDING is an optimization to reduce
redundant messages. For some calls this is fine, such as
broadcastSignalStrengthChanged. For others it can cause problems, such
as broadcastDataConnectionStateChanged where the MobileDataStateTracker
will not be able to properly track the state if messages are dropped.
This changes removes the optimization from all methods in
TelephonyRegistry except broadcastSignalStrengthChanged.
bug: 4427303
Change-Id: Ia9c0dd0ce66b8b3dcda770f5ab2c63cf08f3ebfc
Activity manager now does all dump requests into apps
asynchronously, so it can nicely timeout if there is an
app problem. Also lots of general cleanup of the am
dump output.
Change-Id: I99447b87f77a701af52aeca984d93dfe931f065d
You can now specify resource configuration variants "wNNNdp"
and "hNNNdp". These are the minimum screen width/height in "dp"
units. This allows you to do things like have your app adjust
its layout based only on the about of horizontal space available.
This introduces a new configuration change flag for screen size.
Note that this configuration change happens each time the orientation
changes. Applications often say they handle the orientation change
to avoid being restarted at a screen rotation, and this will now
cause them to be restarted. To address this, we assume the app can
handle this new config change if its target SDK version is < ICS.
Change-Id: I4acb73d82677b74092c1da9e4046a4951921f9f4
Adds a really crappy UI for toggling compat mode.
Persists compat mode selection across boots.
Turns on compat mode by default for newly installed apps.
Change-Id: Idc83494397bd17c41450bc9e9a05e4386c509399
Secure settings are accessible by applications without
permissions. Move to a system-only accessible file
Bug: 4391796
Change-Id: I5448943d26cccce39dd4f32423c68dad4bbf50ad
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
It is not safe to call into vold with a lock held on mVolumeStates
since we will receive events back from vold on a different thread.
So in the boot completed handler we make a copy of the volume list and
then call vold to mount volumes after releasing the lock
Change-Id: Iaadfb1b8be5567c8e228a8fbc69d4d483c8dc987
Signed-off-by: Mike Lockwood <lockwood@android.com>
Settable per network so you can have not timeout for some and some for others.
If you set the old NETWORK_RESTORE_DELAY_PROP_NAME system property
(android.telephony.apn-restore) it will override this value.
Change-Id: Icca706fdc74245dce679209116660e5dc4b05d23
It is not safe to call into vold with a lock held on mVolumeStates
since we will receive events back from vold on a different thread.
So in the boot completed handler we make a copy of the volume list and
then call vold to mount volumes after releasing the lock
Change-Id: Ic9836c2e1e8a5677d0c4e33476a72081f69823a0
Signed-off-by: Mike Lockwood <lockwood@android.com>
* commit '4ec33c2aad59b2a745ee891c9b7246b9533d95e0':
Do not merge. Cherry-pick of Idc802af57fb9926a69ed52d4e776ef57d8b647c6 (package manager fix) to gingerbread.
* commit '75c664582c5ce5d94826f37cb725b447a4d62c50':
Backporting I57c58c4083bd59f45095c184d6ca5a302f79ff6e to HC-MR1. New change since file was renamed, making cherry-pick impossible.
* commit '8325c3a89197e47cfc2eeb4117c927fb8cb91630':
Backporting I57c58c4083bd59f45095c184d6ca5a302f79ff6e to HC-MR1. New change since file was renamed, making cherry-pick impossible.
To avoid blowing past the Binder IPC limit, change the
PackageManagerService to have a DB-like interaction where the client
tells the service the last "row" that it read.
The fact that we use a HashMap instead of a TreeMap makes this
problematic. For now we're just making a new ArrayList for the keys and
then sorting them for each call. This can make the API slower for callers
of this, but it's probably greatly overshadowed by the cost of the data
transfer itself.
Bug: 4064282
Change-Id: Ic370fd148d4c3813ae4f2daffa1a7c28d63d5a09
