Received: by 10.224.70.131 with SMTP id d3mr4205276qaj.0.1349301563113;
        Wed, 03 Oct 2012 14:59:23 -0700 (PDT)
X-BeenThere: android-developers@googlegroups.com
Received: by 10.229.178.10 with SMTP id bk10ls3019601qcb.3.gmail; Wed, 03 Oct
 2012 14:56:44 -0700 (PDT)
Received: by 10.224.223.84 with SMTP id ij20mr4192273qab.5.1349301404178;
        Wed, 03 Oct 2012 14:56:44 -0700 (PDT)
Received: by 10.224.28.72 with SMTP id l8msqac;
        Wed, 3 Oct 2012 08:16:57 -0700 (PDT)
Received: by 10.52.93.132 with SMTP id cu4mr417565vdb.14.1349277416935;
        Wed, 03 Oct 2012 08:16:56 -0700 (PDT)
Date: Wed, 3 Oct 2012 08:16:56 -0700 (PDT)
From: Cesar <cesar.maior...@gmail.com>
To: android-developers@googlegroups.com
Cc: hack...@gmail.com
Message-Id: <346b3acd-fafd-4d34-969b-08cd685360c7@googlegroups.com>
In-Reply-To: <e8853815-1938-436f-aafc-4cb2272f4487@f40g2000pri.googlegroups.com>
References: <ec603266-f8b0-462a-8c3b-b91977963824@79g2000hsk.googlegroups.com>
 <6fb74526-8307-4a95-9e12-85102b15dd98@40g2000prx.googlegroups.com>
 <6a8c2141-a2fe-4415-a0f6-8d8d0274b64c@v28g2000hsv.googlegroups.com>
 <3b8b3a18-b3eb-443e-b9a1-f96958819314@42g2000pry.googlegroups.com>
 <80a28c7d-665e-4632-ac25-f21cfd06054c@x41g2000hsb.googlegroups.com>
 <e8853815-1938-436f-aafc-4cb2272f4487@f40g2000pri.googlegroups.com>
Subject: Re: Sticky Broadcasts and Concurrency
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_216_22480916.1349277416358"

------=_Part_216_22480916.1349277416358
Content-Type: multipart/alternative; 
	boundary="----=_Part_217_13857107.1349277416358"

------=_Part_217_13857107.1349277416358
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Are the broadcasts sent by the system for hardware button presses sticky?

On Tuesday, October 14, 2008 3:14:14 AM UTC-4, hackbod wrote:
>
> Er...  there is NO reason to use sticky broadcasts for communication 
> within your own app.  In fact, I'll go farther and say you just should 
> not do this.  Sticky broadcasts are GLOBAL to the system.  And because 
> of this, performing a sticky broadcast is multiple orders of magnitude 
> slower than just implementing direct calls within your own app (IPC 
> for each receiver to register, IPC to the system to send it, IPC from 
> the system back to your app to deliver it, marshalling and 
> unmarshalling of all the data within the Intent over both IPCs). 
>
> More than that, there is NO protection on them, so any other 
> application can watch your sticky broadcasts, or even send their own 
> values back to you.  (Btw, this is also issue with using any 
> broadcasts within your own app.  Broadcasts are really there for cross- 
> application communication.  It is just far more efficient and easier 
> to implement these things within an app by having a callback 
> interface.) 
>
> Now I am really regretting that I made that function public. :/ 
>
> > And of course, if you want out of application notifications, you have 
> > no other option. 
>
> You do have the option of using a normal broadcast rather than a 
> sticky broadcast.  You'll notice that there are basically no sticky 
> broadcasts used by the system, at least that you see in the public 
> APIs.  In fact there are some places they are used internally, but 
> even those are slowly going away as we discover security holes with 
> them because there is no way to protect who can receive the broadcast 
> data. 
>

------=_Part_217_13857107.1349277416358
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

Are the broadcasts sent by the system for hardware button presses sticky?<br><br>On Tuesday, October 14, 2008 3:14:14 AM UTC-4, hackbod wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Er... &nbsp;there is NO reason to use sticky broadcasts for communication
<br>within your own app. &nbsp;In fact, I'll go farther and say you just should
<br>not do this. &nbsp;Sticky broadcasts are GLOBAL to the system. &nbsp;And because
<br>of this, performing a sticky broadcast is multiple orders of magnitude
<br>slower than just implementing direct calls within your own app (IPC
<br>for each receiver to register, IPC to the system to send it, IPC from
<br>the system back to your app to deliver it, marshalling and
<br>unmarshalling of all the data within the Intent over both IPCs).
<br>
<br>More than that, there is NO protection on them, so any other
<br>application can watch your sticky broadcasts, or even send their own
<br>values back to you. &nbsp;(Btw, this is also issue with using any
<br>broadcasts within your own app. &nbsp;Broadcasts are really there for cross-
<br>application communication. &nbsp;It is just far more efficient and easier
<br>to implement these things within an app by having a callback
<br>interface.)
<br>
<br>Now I am really regretting that I made that function public. :/
<br>
<br>&gt; And of course, if you want out of application notifications, you have
<br>&gt; no other option.
<br>
<br>You do have the option of using a normal broadcast rather than a
<br>sticky broadcast. &nbsp;You'll notice that there are basically no sticky
<br>broadcasts used by the system, at least that you see in the public
<br>APIs. &nbsp;In fact there are some places they are used internally, but
<br>even those are slowly going away as we discover security holes with
<br>them because there is no way to protect who can receive the broadcast
<br>data.
<br></blockquote>
------=_Part_217_13857107.1349277416358--

------=_Part_216_22480916.1349277416358--