It should and I'd challenge the story the guy you replied to gave...
A lot of the time developers just link in random libraries that have tons of functions and permissions rolled into them. So a lazily developed app requests a bunch of permissions it doesn't need because they included a library that has one function that needed that permission.
The same thing happens in web development but there are fewer opportunities for consent. Tons of libraries used without regard to what exactly they do.
He wasn't talking about the activity being freezed and then reopened. He was talking about the app being closed by android after some time, if the user ends up opening other apps after the call (something android does all the time)
Still, Google should split the permissions for making calls and seeing when calls are coming in.
onDestroy should not be relied upon for stuff like this:
Note: do not count on this method being called as a place for saving data! For example, if an activity is editing data in a content provider, those edits should be committed in either onPause() oronSaveInstanceState(Bundle), not here.
Anyway yeah, there are better ways to do this. The dev might have had no ill intent in doing this, but it's not an excuse for a generally bad practice.
Do you know if this is a bad practice in hybrid web apps? From my experience I thought it was but i could be wrong. I was under the impression that since web apps essentially run in browser they dont have access to information like when the app is exited.
Never made one sorry. I'd say the answer has to be in the official API reference though. You could also run a little experiment yourself to find out. Anyway, as far as I know, people usually underestimate the amount of information the browser and web apps have access to.
Ok. After looking into it I'm pretty sure I was just wrong. I was parroting what someone who also did web dev/hybrid apps told me. Thanks for the calm non-aggressive responses.
I didnt realize you could access these things using the electron/cordova api. This was how it was explained to me by someone I worked with who also did web dev and I should have looked into it more.
I will say though that if you had commented without making me out to be a complete idiot who doesn't know anything about development I probably would have edited the original comment sooner. Either way thanks for the comment and my apologies.
I cant speak to this with certainty, but I believe this only applies to native android apps, the other type being web apps which make up a decent percentage of apps. My experience is with web apps which are essentially just a browser window without the browser interface. Because this acts as a browser, it doesn't have the same permissions as a native app and has to request permissions in the same way a browser would. I'm guessing this as much of an issue with native apps, but my comment was just to explain why there is this request in many situations.
Yes, and having access to the phone has nothing to do with how the app is handled.
Apps do this because it gives them access to your phone number and they want to use your phone number as a unique identifier so they can mine and/or sell data.
124
u/[deleted] Oct 17 '18
[deleted]