Les deux applications ont le même ShareDuserid. Lorsque j'utilise ce code dans l'app1 Je reçois une exception me disant que le fichier contient un séparateur de chemin. J'essaie d'écrire un fichier d'app1 dans App2 espace de rangement. (Bien entendu, je dois bien sûr vous assurer que le répertoire des fichiers de l'APP2 existe d'abord) Idéalement, j'écrirais dans un répertoire spécifique à l'utilisateur au lieu d'un répertoire spécifique à l'application, mais je ne sais pas si cela peut être fait.
4 Réponses :
Tout d'abord, n'utilisez jamais un chemin complet sur le stockage interne comme Deuxièmement, vous le faites déjà! Contrairement au fichier , , Si vous pensez vraiment que c'est sûr et nécessaire, et si les deux applications partagent le même identifiant utilisateur à l'aide d'Android: SharedUserid dans le manifeste, vous pouvez obtenir un contexte de l'autre application en utilisant / données / données . Laissez le système d'exploitation vous donner le chemin (par exemple, via context.getfilesDir () ou environnement.getexternalstorestate () ). Ne faites pas l'hypothèse sur l'endroit où les données sont.
context.openfileOutput déjà compense / data / data / [package] sur votre chemin, vous n'avez donc pas besoin de préciser que . Spécifiez simplement le nom de fichier.
context.createpackagecontext () et utilisez context_restrét, puis utilisez OpenFileOutput avec seulement le nom de fichier.
Mais comment puis-je dire qu'Opp1 devrait écrire un fichier à l'APP2?
C'est généralement découragé. Vous ne devriez jamais écrire dans le stockage privé d'une autre application! Mode_private spécifiquement ne vous fera pas beaucoup de bien - les données ne seraient même pas lisibles par l'autre application! Si vous devez vraiment, utilisez fichier pour spécifier un chemin absolu. Mais cela ressemble à vous utiliser la mauvaise approche pour commencer.
Tout d'abord (je pense) mode_private fonctionnerait parce que j'utilise le même ShareDuserid. Deuxièmement, je prévois d'écrire des données partagées aux deux applications. Il est important que les applications inconnues n'aient pas accès aux données partagées.
Essayez de créer un contexte pour l'autre application à l'aide de context.createpackagecontent () , puis utilisez OpenFileOutput avec seulement le nom du fichier. N'a pas essayé cela, mais puisque vous avez un SharedUserid, cela peut simplement travailler. Je ne serais pas surpris si cela ne fonctionne pas cependant.
Ça a marché. J'ai été utilisé context_restrét pour le deuxième paramètre pour CreatePackagecontent
Cela ne répond pas à la question
Si vous déplacez les informations utiles des commentaires à la réponse, je vous donnerai un uppote.
Pourrait aussi bien ... vous y allez.
+ George Bailey + Ebomike Vous semblez avoir résolu ceci sans contenu de contenu ... Qu'avez-vous fait et comment cela a-t-il fonctionné pour vous? (Stackoverflow récompense activement les participants de leurs propres questions :))
@jaMesh La réponse doit contenir tout ce dont vous avez besoin. Avez-vous des problèmes ou des questions?
@Ebomike mon mauvais. J'ai eu des confidents.
Vous ne devriez pas écraser d'autres fichiers d'applications. Qui dit que vous avez deux solutions
EDIT: Le développeur possède les deux applications
Merci pour Kurik romain de pointer de la sorte. Un lien vers son poste sur Donc
de l'androïde Docs
Android: Shareduserid
Le nom d'un identifiant utilisateur Linux qui sera être partagé avec d'autres applications. Par Par défaut, Android attribue chacun Application son propre ID utilisateur unique. Cependant, si cet attribut est réglé sur la même valeur pour deux ou plus applications, ils partageront tous le même id - à condition qu'ils soient aussi signé par le même certificat. Application avec le même identifiant d'utilisateur peut accéder aux données de chacun et, si souhaité, courir dans le même processus.
Il s'agit donc exactement du fonctionnement de l'utilisateur de l'utilisateur sous Linux, essentiellement, vous êtes le propriétaire des deux et avoir un accès lu / écriture aux deux.
Les deux applications ont le même Shareduserid. Je contrôle les deux applications. Il est également important que les applications non liées n'aient pas accès à mes données. Donc, je ne pense pas que ce soit de ces deux options fonctionnera ... Mais qu'est-ce que c'est à propos de la racine. Dites-vous que je peux exécuter mon application en tant que root?
Il est possible de gagner un accès root sur la plupart des téléphones, c'est ainsi que les roms personnalisées peuvent être installées. De là, les applications peuvent demander une racine via l'application «SuperUser». Mais puisque vous contrôlez les deux, il devrait y avoir une solution plus simple, je vous recontacterai un peu.
Ouvrir un FileOutPutStream code> du fichier requis, relatif à ce chemin: String filePath = getPackageManager().
getPackageInfo("com.your2ndApp.package", 0).
applicationInfo.dataDir;
+1: J'ai pu utiliser ceci pour vérifier l'heure de modification / existe sur une autre application sans utiliser de chemin absolu .. Merci.
En fait, j'ai fini par utiliser CreatePackagecontent
Étant donné que cela a des mois, je suppose que vous avez déjà résolu votre problème, mais je vais contribuer quand même.
Partage de données entre les applications est ce que sont les fournisseurs de contenu. En supposant que vous sachiez écrire un fichier de contenu et y accéder, vous pouvez accéder aux fichiers via ParcelfileDedescriptor, qui comprend des constantes pour le mode dans lequel vous créez les fichiers.
Ce dont vous avez besoin maintenant consiste à limiter l'accès afin que Tout le monde ne peut pas lire les fichiers via le fournisseur de contenu et vous le faites via des autorisations Android. Dans le manifeste d'une vision de vos applications, celui qui hébergera les fichiers et le fournisseur de contenu, écrivez quelque chose comme ceci: et dans les deux apps ajoute ceci: à l'aide de protectionlosevel = "Signature", seules les applications signées par vous peuvent accéder à votre fournisseur de contenu, ainsi que vos fichiers.
Très intéressant. Je ne pourrai pas l'essayer cependant, car la solution a déjà été mise en œuvre, et toutes les applications / améliorations supplémentaires supplémentaires seront probablement réutiliser le système existant. +1 de toute façon. Je pense que votre solution est valide même si je n'ai pas été capable de le tester.