4 ms·

Intents are the best permissions system.

by mynameislegion 10y ago

BoorishBears 10y ago
Intents as in Android intents?
- Zigurd 10y ago
  I think he means: "Apps should be more modular and use other apps' capabilities more." Which is true.
  - BoorishBears 10y ago
    The way Android has facilitated that (the intent system) is horrid, so in reality the more apps try to use other apps, the more unstable they become.
    - Zigurd 10y ago
      Android has both high-level IPC via Intent filters and low-level IPC via bound Service objects. Neither create instability. ACTION_SEND is widely implemented without creating instability. But other verbs are underutilized: Setting calendar events, picking contacts, etc. ACTION_EDIT should be almost as common as ACTION_SEND. Making a cooperating suite of apps is a huge missed opportunity in Android. Meanwhile I see plenty of bloaty apps that are unstable because they are large and monolithic.
      - BoorishBears 10y ago
        Low-level IPC is practically inapplicable to apps made by different creators working together. Not to mention it's no dream to work with. I work with hardware that comes with stock AOSP, and getting a "daemon" style service to run from boot without closing took several workarounds, even though it should have been as simple as "START_STICKY" with a foreground service Android's Service model is very clearly not meant to support such a simple usecase. The most reliable way is actually to modify the image because only system services are supposed to be allowed to do that. Working with services that aren't reliably started can also be bad for UX even if you don't have the usecase I had of needing a daemon because there might be a high cost associated with starting up. People also don't want every service showing a notification to stay alive. After trying to model this complex device management system I was working on in nice contained pieces we could maintain separately, I was forced to stuff it into one monolithic app. Performance improved because we no longer needed workarounds to keep the multiple services alive, just one was enough, and we only needed one process to stay alive (a process which is always second from the top in recent usage because our hardware only needs to run our app and a 2nd party one). Intents are unstable because no one follows the standards for verbs properly. Samsung's built in apps are notorious for crashing if you try to use extras. Facebook won't crash, but it won't respect EXTRA_TEXT or EXTRA_SUBJECT properly because they only want you sharing a URL. Pinterest crashes on sharing some images that other apps don't. I'd almost go as far as saying you can find a crash report that's app-specific for any major app (Gmail, Facebook, etc.) that you'd expect to see receive a share intent by googling "<insert app name> android intent crash". It's almost always something with the app that's taking the intent not respecting the intent contract properly.
        Zigurd 10y ago
        It seems like 80% of your trouble comes from trying to subvert the "your service won't start until you use it" solution to the "everybody is lazy and/or anti-social and wants to start their service on boot" problem. In other words, Google intended to make the life of an app author who wants this extremely difficult and would have suggested that they attack the "because there might be a high cost associated with starting up" problem instead. But, yeah, if it is your device with your AOSP build, and you really really have The Most Important Service, go ahead and compile it into the system. On top of all that, the usual reason there is a "high cost to starting something" is that it hits a server and hasn't cached the data it needs. The OS can't solve that for you.
        BoorishBears 10y ago
        That was really a digression of my main point of intents forming an unstable API but our problem was 100% subverting your service won't start until you use it, but Google's approach is insanely heavy handed. A saner solution would to be to give a permission for daemon style services that comes with a warning to the user about battery life and network implications. Our service really is the most important service on the device because if our service goes down the device is essentially "bricked" (these are embedded android devices so we lose visibility on the installation), but adding our service to the image means managing images for every device variation we use (and some of those device's manufacturer's won't be happy to have someone else managing said images since it means more work for them [build image, send it to us, we modify it, send it back to them, they use it vs just building an image and using it]). It's a unique use case, but it's not hard to imagine more common software that could take advantage of daemons, even if it's just to provide smarter background processing than the "all-or-nothing" defaults provide (like START_STICKY). Besides being rather unique to our use case, I'd also say it doesn't have to do with apps from different creators working together... And I don't think the network is involved most cases of expensive services, because the OS (or more specifically, Google's services on most end user devices) already help solve that with things like the GCMNetworkManager and ConnectivityManager callbacks for optimizing network access.
        10y ago

Intents are the best permissions system.

BoorishBears 10y ago

Intents as in Android intents?

Zigurd 10y ago
I think he means: "Apps should be more modular and use other apps' capabilities more." Which is true.
- BoorishBears 10y ago
  The way Android has facilitated that (the intent system) is horrid, so in reality the more apps try to use other apps, the more unstable they become.
  - Zigurd 10y ago
    Android has both high-level IPC via Intent filters and low-level IPC via bound Service objects. Neither create instability. ACTION_SEND is widely implemented without creating instability. But other verbs are underutilized: Setting calendar events, picking contacts, etc. ACTION_EDIT should be almost as common as ACTION_SEND. Making a cooperating suite of apps is a huge missed opportunity in Android. Meanwhile I see plenty of bloaty apps that are unstable because they are large and monolithic.
    - BoorishBears 10y ago
      Low-level IPC is practically inapplicable to apps made by different creators working together. Not to mention it's no dream to work with. I work with hardware that comes with stock AOSP, and getting a "daemon" style service to run from boot without closing took several workarounds, even though it should have been as simple as "START_STICKY" with a foreground service Android's Service model is very clearly not meant to support such a simple usecase. The most reliable way is actually to modify the image because only system services are supposed to be allowed to do that. Working with services that aren't reliably started can also be bad for UX even if you don't have the usecase I had of needing a daemon because there might be a high cost associated with starting up. People also don't want every service showing a notification to stay alive. After trying to model this complex device management system I was working on in nice contained pieces we could maintain separately, I was forced to stuff it into one monolithic app. Performance improved because we no longer needed workarounds to keep the multiple services alive, just one was enough, and we only needed one process to stay alive (a process which is always second from the top in recent usage because our hardware only needs to run our app and a 2nd party one). Intents are unstable because no one follows the standards for verbs properly. Samsung's built in apps are notorious for crashing if you try to use extras. Facebook won't crash, but it won't respect EXTRA_TEXT or EXTRA_SUBJECT properly because they only want you sharing a URL. Pinterest crashes on sharing some images that other apps don't. I'd almost go as far as saying you can find a crash report that's app-specific for any major app (Gmail, Facebook, etc.) that you'd expect to see receive a share intent by googling "<insert app name> android intent crash". It's almost always something with the app that's taking the intent not respecting the intent contract properly.
      - Zigurd 10y ago
        It seems like 80% of your trouble comes from trying to subvert the "your service won't start until you use it" solution to the "everybody is lazy and/or anti-social and wants to start their service on boot" problem. In other words, Google intended to make the life of an app author who wants this extremely difficult and would have suggested that they attack the "because there might be a high cost associated with starting up" problem instead. But, yeah, if it is your device with your AOSP build, and you really really have The Most Important Service, go ahead and compile it into the system. On top of all that, the usual reason there is a "high cost to starting something" is that it hits a server and hasn't cached the data it needs. The OS can't solve that for you.
        BoorishBears 10y ago
        That was really a digression of my main point of intents forming an unstable API but our problem was 100% subverting your service won't start until you use it, but Google's approach is insanely heavy handed. A saner solution would to be to give a permission for daemon style services that comes with a warning to the user about battery life and network implications. Our service really is the most important service on the device because if our service goes down the device is essentially "bricked" (these are embedded android devices so we lose visibility on the installation), but adding our service to the image means managing images for every device variation we use (and some of those device's manufacturer's won't be happy to have someone else managing said images since it means more work for them [build image, send it to us, we modify it, send it back to them, they use it vs just building an image and using it]). It's a unique use case, but it's not hard to imagine more common software that could take advantage of daemons, even if it's just to provide smarter background processing than the "all-or-nothing" defaults provide (like START_STICKY). Besides being rather unique to our use case, I'd also say it doesn't have to do with apps from different creators working together... And I don't think the network is involved most cases of expensive services, because the OS (or more specifically, Google's services on most end user devices) already help solve that with things like the GCMNetworkManager and ConnectivityManager callbacks for optimizing network access.
        10y ago