This is due to the window doing a relayout after its activity is
stopped, at which point it may need to interact with the adapter
to load data.
The fix here is to tell ViewRoot about an activity being stopped
and, if in this state, hold off on doing any new measurements and
layouts of the hierarchy until it is no longer stopped.
In this case the relayout was happening due to the cursor
being deactivated, with causes the adapter to invalidate
its data. Because this is now in a dialog window, this
allows the window to actually be resized smaller (unlike when
in a full screen activity), and boom.
Change-Id: I26442b4679819b4a4e6bc56289afd3445526750b
paths of code getting the mCacheLock and DB locks in different
orders.
The philosophy I followed for this was to ensure that the
DatabaseHelper is only ever accessed from within a
synchronized(mCacheLock) block. I also renamed a bunch of
methods to make it easier to know if a given method should
be called from within this synchronized block.
Bug: 3404506
Change-Id: Ia48f95e77b77647d0717f70f1d8364da3719cc13
ViewTreeObserver OnScrollChangedListener will then get notified.
The scroll values are not specified, since they are passed to the
base View.onScrollChanged method that simply sets the flags.
No need to throw these from a Runnable (in case this happens during
a relayout) since the listeners will be notified later from ViewRoot.draw().
Calling View.onScrollChanged in invokeOnItemScrollListener for normal scroll and
in onOverScrolled to handle mScroller animation.
Change-Id: Ib41434e5cd82e5a45ca6653db576746e89ef072d
The wallpaper service claims a desired width/height of (-1,-1) during
initial setup, so look to the default display's metrics if necessary.
Change-Id: I341f12fb7b0b9d6b7761c277f23fc68fa5355256
New pointers touching the screen always become the active pointer.
Still to do: allow flings until another pointer moves enough to stop
it. Currently flings will be immediately stopped by the other pointers
still contacting the screen.
Change-Id: Ic1c7bf98dcf40252593cec0ab1f0d524aaeed8e4
Also removed config_hasUsbHostSupport framework resource, which is now obsolete.
Change-Id: I6f18cc1c4f68085de8b8363e1b5edff79aff404f
Signed-off-by: Mike Lockwood <lockwood@android.com>
When a USB device or accessory is connected, the UsbService now asks the
user which application to associate with the device or accessory.
Applications interested in devices or accessories must specify the
devices they work with via meta-data attached to their manifest.
Permission to communicate with the device is assigned when the user chooses
the activity to use for the device.
The user has the option of clicking the "always use this application" checkbox
to make the assignment automatic in the future.
The user may later clear this preference and revoke permission for an application
to have permission to communicate with the device by clicking the "Clear defaults"
button for the activity in the Manage Applications panel in Settings.
Added class UsbResolveActivity (a subclass or ResolveActivity for choosing
an activity for a USB device or accessory)
Added UsbDeviceManager, which manages the mapping between USB devices/accessories
and applications, including default applications for devices and accessories,
and manages application permissions.
Add interface to allow Settings to clear device and accessory
preferences and permissions for an application.
Remove obsolete ACCESS_USB permission.
Add new signatureOrSystem MANAGE_USB permission to allow administrating
preferences and permissions.
Moved UsbService.java to a "usb" subdirectory, along with new classes
UsbResolveActivity and UsbDeviceManager.
Change-Id: I92554381e9779e68ce380daaee4e1401fb875703
Signed-off-by: Mike Lockwood <lockwood@android.com>
Also switch to using libcore's array bounds checking. (This variant had no
detail message and was missing the length check.)
Bug: http://code.google.com/p/android/issues/detail?id=15075
Change-Id: Icfc045bd59403b59f02d95c8514abf881d3996e5
