problems when setting / removing color filter to image views

by Romain Guy » Thu, 29 Jan 2009 01:09:59 GMT

Sponsored Links

The problem comes from a rather unknown feature of resources and
drawables. The state of several drawables that come from the same
resource is shared across all the drawables. Take this example:

Drawable d1 = getResources().getDrawable(R.drawable.my_image);
Drawable d2 = getResources().getDrawable(R.drawable.my_image);

d2.setAlpha(0); // Sets the alpha value of d2 *and* d1 to 0

The two drawables are different objects but they both use the same
"constant state" (it's the actual name of the implementation) which
contains, among other things, the alpha value, the bitmap... and the
color filter.

This behavior comes from the necessity to optimize the memory usage
and the loading times of applications. By doing so we have only one
constant state used by all buttons across all applications.

Romain Guy
Android framework engineer

Note: please don't send private questions to me, as I don't have time
to provide private support.  All such questions should be posted on
public forums, where I and others can see and answer them


Other Threads

1. BroadcastReceiver and abortBroadcast()

Hi all

Are there any good design patterns to solve the following problem:

How can I best implement a BroadcastReceiver that may need to
"consume" the current broadcast (via abortBroadcast()), but it first
needs to perform some non-trivial work to determine whether or not the
broadcast should be consumed.

The problem is that if the non-trivial work takes more than 10 seconds
then the receiver is considered to be blocked by the system and may be

I realise that long-running operations should not be performed in the
onReceive() method of receivers for that very reason, and should
instead be handed-off to an appropriate service. However, if the
current broadcast is to be consumed, then the abortBroadcast() method
must be called within the onReceive() method before it returns. If
some processing is required to determine whether the current broadcast
should be consumed or not, then things can get tricky.

I'm developing an app that can consume some (but not all) inbound SMS
messages. For any given SMS message it will need to perform some
analysis based on the sender's phone number and the message body
(including database lookups) in order to determine if the message is
one that is relevant to the app or not. In the vast majority of cases
this will take less than 10 seconds, but it is possible that it could
take longer on rare occasions.

To get around this I'm considering the following solution.

1. On receiving a broadcast for a received SMS, my receiver starts a
background thread to perform the required analysis and handle the
message if appropriate.
2. The main thread (currenly executing the onReceive() method) waits
until either the background thread has finished its work, or 8 seconds
have elapsed, whichever occurs first.
3. If the background thread finished within the allotted time (which
should happen most of the time), then the main thread calls
abortBroadcast() or not, (depending on the result of the analysis) and
returns normally.
4. If the background thread did NOT finish within 8 seconds, then the
main thread stops the background thread and instead starts a service
to perform the work. In this case it does NOT call abortBroadcast(),
and the broadcast will be passed to other receivers (eg the default
messaging app) regardless of whether or not the service ends up
handling the message.  While not an ideal outcome, it is acceptable.

Because the main thread can potentially block for up to 8 seconds at a
time, the receiver and associated service would run in a separate
process from the process that hosts the app's Activities.

Is that a viable approach?  If there are any better options I'd love
to hear them ...


2. Are developers now tech support for the Market?

This is the first time in over a year of having apps on the Market that 
I've gotten one.  I've mainly have people email me at my own support 
address.  And none of those had to do with any download problems, nor 
credit card, etc. Usually just questions about the program or feature 
requests which are always welcome. 

Get used to it, because you will be getting a lot of these. Google support is both hard to find and inadequate, and users will expect you to be able to solve any problem around downloading your app, regardless of whose responsibility it is. I get a dozen or more emails like this a day. There are many reasons why the download can fail, but top of the list are credit card authorization issues (check google checkout) and the known problem with downloads which fills a lot of this forum.
I got some forwarded email via the Market from someone who purchased on of my products but yet downloaded it. I suspect in their e{*filter*}ment over the purchase they missed the download prompt. And I have no idea what happens in that case other than to suggest they go back to the listing and see if there is a Download icon presenting itself. I also explained that app developers have no control over what happens on the Market and those questions should be directed at the Market's own tech support. - Brian

3. Android build error for superh arch

4. Emulator behaving like I麓m pressing "=", but I麓m not!

5. Are developers now tech support for the Market?

6. regarding stopping service

7. Prevent application from showing up when dialing.