6

I am almost ready to upload an application to the Google Play, but I want to do it well, without mistakes (or trying to avoid them), so I have followed this question: “To Do” list before publishing android app to market [closed]

But, there I have seen an answer that makes me pay more attention because I did not know about that attributes. This is the answer that I refer to.

The answer suggests to declare android:process and android:sharedUserId attributes so I looked for that documentation.

Looking for some information about both attributes, I have found this answer for android:process attribute that makes me see more clear how this attribute can be used. What I could get from there is that you can declare that your Activities will be launched in different process to avoid memory limits when you run the main process. Correct me if I am wrong.

Far from encountering a detailed documentation for android:sharedUserId attribute, I tried looking in some questions here:

And what I could get from there is that I can share some information between applications. Again correct me if I am wrong about it.

In my application, I only use Google Maps inside of it so some questions came to my head:

  • Should I always declare android:process and android:sharedUserId as the answer that I linked before suggests?

  • If it is true, can it generate some security problems? I do not know if it can be possible, but I think that if some applications can access to your data application it can maybe be a security problem (depending of the type of data that you have on your application).

  • What name should I use on android:sharedUserId? Can it be whatever I want or has to be a specific name (for example, the package name) so other applications can access to my application data? Is that android:sharedUserId public?

  • If I do not want that my application share information by the moment, but in the future I want to do that. Should I declare that android:sharedUserId the first time I publish it on the market? Could the rest of applications access to my data then?

  • Should I declare android:process to, for example, execute my maps that is on a Fragment?

Note: I am totally confused about those attributes so maybe that questions are not totally well-formed (in a syntactic or concept way). Please correct me in any mistake that I could make on this question. I tried to recopile as much information I could, but it is not enough to solve my doubts.

Thanks in advance!

Community
  • 1
  • 1
Francisco Romero
  • 12,787
  • 22
  • 92
  • 167
  • 2
    "Should I always declare android:process and android:sharedUserId as the answer that I linked before suggests?" -- IMHO, no. Use `android:process` only in rare cases, where you are certain that you need a separate process. Use `android:sharedUserId` if you are building your own custom ROM, plan on shipping a suite of apps on that ROM that need to exchange data, and are too lazy to write real APIs for those apps to use for communication. – CommonsWare Dec 26 '16 at 00:58
  • 1
    @CommonsWare Thank you for your answer! So, should I avoid those attributes by the moment? I mean, I think that I do not have to care about those attributes by the moment because I only have one application right now. As I can understand from what you have detailed is that I can, instead of using an API to connect all the applications that I need to share data, share directly that data using `android:sharedUserId`. Am I right? – Francisco Romero Dec 26 '16 at 01:09
  • 3
    "should I avoid those attributes by the moment?" -- IMHO, yes. If you do wind up with several apps, and you do wind up needing for them to exchange data, you can implement some sort of API to do so (e.g., service, broadcast, provider). The primary thing that `android:sharedUserId` enables is for multiple apps to access each other's private files, but that is considered to be poor form pretty much everywhere in software development. For example, if two apps try writing to the same file at the same time, you can run into coordination problems. – CommonsWare Dec 26 '16 at 01:11
  • 3
    With respect to `android:process`, as the saying goes, "there is no free lunch". You taking up multiple process' worth of system RAM puts more pressure on Android to terminate other apps, to give you their RAM. This can harm the user's ability to rapidly switch between apps. Occasionally, temporarily, using a second process may be useful, where the net benefit to the user is worth the cost. – CommonsWare Dec 26 '16 at 01:15
  • 1
    @CommonsWare Thanks for all that extra info. I find it very useful to clarify myself about these methods. One more question: If they can access the private files of each application, can it also be a security problem? Or is there just simple data stored in those files (not users information or passwords to share between applications)? But I think this will depends on what the programmer will store there. Or is the information automatically stored by the different applications? – Francisco Romero Dec 26 '16 at 01:33
  • 2
    "If they can access the private files of each application, can it also be a security problem?" -- yes, to the extent that if one app in the suite gets hacked, the hacker has access to the files of all apps in the suite. APIs would provide similar access but frequently are more difficult for a hacker to exploit. "Or is there just simple data stored in those files" -- they are your files, so they hold whatever you put in them. "Or is the information automatically stored by the different applications?" -- only a few things are saved automatically (e.g., `WebView` cookies). – CommonsWare Dec 26 '16 at 12:23
  • @CommonsWare Wow. Nice information. You helped me to clear my mind. Thank you again! – Francisco Romero Dec 26 '16 at 15:43

0 Answers0