morning

just visiting today - no questions right now

howdy, fitz!

OK

if something comes to mind, chime in

howdy, Tejas!

Hey Mark !

Good Morning

liked Malcolm Cooke questions today in email - interesting stuff about sorting 2-3 different data sources

yeah, a general-purpose solution for that would not be easy

at least, off the cuff

Tejas: do you have a question?

I had few questions about IPCs

fire away!

Basically I would like to know what are the best ways one can pass sensitive data (like username, password etc..) between processes

first question: why are you passing sensitive data between processes in the first place?

(as that might influence my suggestions)

well, consider that there is one common authentication/autherization app which provides settings etc.. to some other "family" of apps

OK, so all the apps are yours

(vs. integration with third parties)

the intent is..

but there may be some other app, i would like to provide the data

if it authenticates correctly

its like a authentication gateway app

OK, so all the apps are *not* yours, then

right?

yes

I'm not quite sure what you're defending against

so long as you are not using broadcast Intents, nothing can sniff on communications between processes

the auth app is mine... others may or may not be mine

(e.g., remote service via Intents, remote service via AIDL/binding, content provider)

A content provider is not particularly well-suited for an authentication pattern, though

so I'd lean towards a service implementation

whether you use the binding pattern or the command pattern would be up to you

so if it is Intents - they have to be Explicit - with a component name specified

no

in fact, that's generally a bad idea

why so ?

the service exposing the API (binding or command) should have an <intent-filter> with a custom action

why so: http://android-developers.blogspot.com/201…

let me check

if you have third parties communicate to you by component name, you can never rename/refactor your API class

got it

also, in theory you could use different action strings to identify different API versions in your published API

ok. do you see any holes in the Binder interface for such purpose

on the whole, I don't like binding much, as I find it too tightly couples client and service

makes configuration changes a bit more challenging

as seen in the Services/WeatherAPI sample from _The Busy Coder's Guide to Android Development_

that being said, if you're willing to test all that, there's nothing intrinsically wrong with binding

and, for an authentication model, I can see why you might want to lean in that direction

yes

I'm not a big fan of permissions. I don't think the users really read all those

true, and it's not designed to be an app-to-app authentication scheme

you can't use permissions to say, for example, that App A can use your API but not App B because App A paid you

yup ! I got worried last night when I learned that Intents for starting services can easily be sniffed using the RecentTaskInfo

this make me think if this is possible for BroadcastReceivers and Services too

there is no RecentTaskInfo in the SDK

oh, no, wait

and ContentProviders as well

search wasn't working

ContentProviders don't use Intents

What about ActivityManager.RecentTaskInfo

the baseIntent would only be the service if the task was not already running

(again, my apologies -- the search field doesn't work on the Blog tab of developer.android.com, which is why RecentTaskInfo wasn't coming up for me)

ok, gat it :)

yeah, I'll need to play around with RecentTaskInfo/Running*Info

haven't used them to date

I hadn't realized that the Intents were visible that way

not good

yes, i was able to sniff the extras from the intents of other activites

activities I can believe

though that's not ideal, either

tasks are usually an activity construct, though

which is why I'd want to see how services/broadcast receivers behave with it

yet another experiment to run

yup... in my todo list for today !

where did you see a reference to services appearing in RecentTaskInfo?

no I didn't see it - I still believe its not possible with services and receivers using RecentTaskInfo - but was thinking if there is anything equivalent.

ah, OK

RunningServiceInfo does not seem to expose an Intetn

er, Intent

nor does RunningTaskInfo

yup

BTW, you were asking on Twitter regarding the pair of security issues I filed with the Android security team

one is that you can enable the NFC adapter, even if it is disabled, through a trick

I argue that this should not be allowed for privacy reasons, akin to disabling GPS

the other is that somebody found a way to block the HOME button from working

oh !

which Ms. Hackborn and others have repeatedly said should not be allowed

interesting ... thanks for the heads up

curiously, I haven't heard back from said Security Team yet

they're probably all busy getting their Google+ Circles in order... :-)

:)

i'm still waiting for an invite :D

since we are on and around security - I have seen some apps write an AIDL for some system services like Telephony and then override the functionality

is it normal thing to do ?

um, no

not sure why they're doing that

the OS shouldn't be using their system service

so this shouldn't work as a hack

i have seen some apps doing this to replace the incoming call screen

I thought that was just by handling some Intent actions

(not that I'm a fan of replacing the incoming call screen, and I try to avoid those questions like the plague)

nopes, they bring their activity in front when a call comes in - which is doable

however in order to receive and end calls they need functions fromt he Telephony service

OK, but I'm not sure where the AIDL comes in

you can check out the codebase for : http://code.google.com/p/teddsdroidtools/

oh, I see what you mean

I thought you meant they were exposing things via AIDL, not consuming them

no, this is not normal either

yup.. thats wat i thought so

this is yet another tool in the "we want to make crappy apps that break on certain Android devices and OS versions" arsenal

ha ha.. true

if anyone has a question, chime in

Sure..checking my list

Ah... got one

we can query the Packagemanager for various things like Permissions, Application info etc...

essentially it retrieves the info from the Manifest File, right ?

that sort of stuff, yes

is there any way to query for the IntentFilters for an application (or any of its components)

nope

given an Intent, you can find who would respond to it

but you cannot iterate over IntentFilters anywhere I have found

yup thats fine, is there a way to programmatically read the Manifest file ?

not that I am aware of

hmm.. ok

ok Mark, i'll head off now

have a Great day

you too!