The PhoneWindowManager is now responsible for determing this,
since it needs to do this before we can generate the configuration
since we need to take into account the system bar size we will use.
Also the Display should now report the screen height without
including the system bar.
Change-Id: I82dfcc5e327e4d13d82c373c6c870f557a99b757
Added a new PointerIcon API (hidden for now) for loading
pointer icons.
Fixed a starvation problem in the native Looper's sendMessage
implementation which caused new messages to be posted ahead
of old messages sent with sendMessageDelayed.
Redesigned the touch pad gestures to be defined in terms of
more fluid finger / spot movements. The objective is to reinforce
the natural mapping between fingers and spots which means there
must not be any discontinuities in spot motion relative to
the fingers.
Removed the SpotController stub and folded its responsibilities
into PointerController.
Change-Id: Ib647dbd7a57a7f30dd9c6e2c260df51d7bbdd18e
Also fix not writing the settings file when an admin is removed.
And take care of an old to-do about not removing an admin until
after it has received the broadcast about it being disabled.
Change-Id: I4ebe0ea0461222b65425b2c5438b646b572f18c8
4 hours is excessive, and we want to save bandwidth on the NTP servers
Change-Id: Ic5ac4f4a8e62167206f3f620ea51635a2ea771d6
Signed-off-by: Mike Lockwood <lockwood@android.com>
Rip out the old funky code for trying to restrict the app window
sizes to be within the compat mode range. Instead, we know rely
entirely on scaling -- we deal with windows always with the scaling
applied so that the window manager doesn't have to deal with them
specially. Instead, we just apply the inverse scale at the few
points we need to do something the app sees.
Change-Id: I785409dd4513b5f738684e1635dc8f770c249651
This ID is used for MTP as well as per volume querying in the media provider.
Change-Id: Ic4fc986d972bd477730643f7e9450c390c0b3a4b
Signed-off-by: Mike Lockwood <lockwood@android.com>
Not yet working, so turned off.
Also fix a bug where the display size configuration became inconsistent
after a configuration change -- we now figure out everything about the
display size when computing a new configuration.
Change-Id: Id155f133c0bf108508a225ef64ed3ca398a90a58
Applications now get the display size from the window manager. No
behavior should be changed yet, this is just prep for some real
changes.
Change-Id: I47bf8b55ecd4476c25ed6482494a7bcc5fae45d2
Replace config_emulateExternalStorage, config_externalStorageRemovable,
config_externalStoragePaths, config_externalStorageDescriptions and
config_mtpReserveSpaceMegabytes resources with an XML resource file
to describe the external storages that are available.
Add android.os.storage.StorageVolume class
StorageManager.getVolumeList() now returns an array of StorageVolume
Change-Id: I06ce1451ebf08b82f0ee825d56d59ebf72eacd3d
Signed-off-by: Mike Lockwood <lockwood@android.com>
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
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: Ic9836c2e1e8a5677d0c4e33476a72081f69823a0
Signed-off-by: Mike Lockwood <lockwood@android.com>
Handle the case where the kernel driver is in accessory mode but we failed
to initialize it at the framework level. On disconnnect, check to see if the
accessory kernel driver is enabled rather than checking mCurrentAccessory.
That way we will restore the USB state in the kernel even if mCurrentAccessory
is null.
Change-Id: I35d458f21a8b21611946da523d0f53723cab0540
Signed-off-by: Mike Lockwood <lockwood@android.com>
If you deleted the host routes (started a secondary network like mms, supl
of hipri and then ended it) you would lose the host route to the default
gateway. Then if you needed to re-add the default gateway route (lost
the connection and removed the default route and then re-established)
you couldn't - can't add a gateway that isn't routable apparently.
This happens if you are in a video chat and lose your connection without
losing the interface (PPP keeps it up for a bit).
Fixed it by having addDefaultRoute first add a hsot route for the gateway
before adding the default route. This allows the default add to succeed.
bug:3490353
Change-Id: I415e7319832e6456f8757b14c4f79f098a08839b
o Update the copyright date on InputDispatcher_test.cpp and InputReader_test.cpp
because these two files were moved from other places to the current location,
and were actually created in 2010.
bug - 4119349
Change-Id: Ic93b81ddafb58e9e72a2e9e02ca3d9f173d6dca7
In PackageManagerService, intent with ACTION_PACKAGE_FIRST_LAUNCH was
being sent to wrong package. It was being sent to the installed
package with installer package in the URI, whereas it should be sent
to installer package with installed package in the URI.
Comment in Intent.java:1417 seems to support that intent with this
action should be sent to the installer package, not installed.
Bug: 3426299
Change-Id: Iadec4ae7a1af6bab434716f8fcdb7d0b099d1ee1
Bug: 3473532
Reverting: Ie3f5b484b5574e10a4
Depends on Bug: 3511230
This must be fixed before submitting this CL.
Change-Id: I435a294a818bec5675f0ada00d81c1b3e37d1dce
This is used when there is only one application available and the user has
not chosen to start it by default.
If more than one application is available we continue to use UsbResolverActivity
Bug: 4074719
Change-Id: Id61f2ccc6de5b9ac70fb4670006ff1fee2028d55
Signed-off-by: Mike Lockwood <lockwood@android.com>
