2 votes

Doit-on inverser les APPLICATION_IDs (noms de packages) en DNS inverse ?

J'ai toujours pensé que com.google.android.packageinstaller ou pm refuserait d'installer un .APK si son manifeste ne comportait pas de DNS inversé pour le nom du package.

Cependant, adb shell cmd package list packages retourne package:android dans la liste des noms de packages standard. C'est la seule exception, ce qui le rend en fait plus surprenant.

Dans des gestionnaires de packages comparables qui utilisent une telle structure (comme flatpak), le rDNS est obligatoire dans le manifeste du package. Je m'attendais à ce que pm soit pareil.

En conséquence:

  • Cette règle est-elle vraie pour les applications que l'utilisateur installe mais pas pour le système, peut-être? Ou

  • Un package peut-il simplement être nommé n'importe quoi, mais la convention existe-t-elle en raison du Play Store, ou d'une autre force motrice au sein de l'écosystème?

5voto

John Dallman Points 123

Les instructions pour définir l'identifiant de l'application dans Android Studio sont claires sur le fait que ce nom n'a rien à voir avec les noms DNS. Il ressemble un peu à un nom DNS, mais ils n'ont pas de relation significative.

Cela est lié à l'espace de noms Java ou Kotlin utilisé dans l'application, mais ce n'est pas synonyme de celui-ci ; ils sont souvent les mêmes mais ce n'est pas une nécessité.

Chaque application Android a un identifiant d'application unique qui ressemble à un nom de package Java ou Kotlin, tel que com.example.myapp. Cet identifiant identifie de manière unique votre application sur l'appareil et dans le Google Play Store.

Bien que l'identifiant d'application ressemble à un nom de package Kotlin ou Java traditionnel, les règles de nommage pour l'identifiant d'application sont un peu plus restrictives :

  • Il doit avoir au moins deux segments (un ou plusieurs points).
  • Chaque segment doit commencer par une lettre.
  • Tous les caractères doivent être alphanumériques ou un tiret bas [a-zA-Z0-9_].

Il est recommandé de faire ce qui suit lors de la définition de l'identifiant d'application :

  • Gardez le même identifiant d'application que l'espace de noms. La distinction entre les deux propriétés peut être un peu confuse, mais si vous les gardez les mêmes, vous n'avez rien à craindre.
  • Ne modifiez pas l'identifiant d'application une fois que vous avez publié votre application. Si vous le modifiez, le Google Play Store traitera le chargement ultérieur comme une nouvelle application.
  • Définissez explicitement l'identifiant d'application. Si l'identifiant d'application n'est pas explicitement défini en utilisant la propriété applicationId, il prend automatiquement la même valeur que l'espace de noms. Cela signifie que changer l'espace de noms change l'identifiant d'application, ce qui n'est généralement pas ce que vous voulez.

Pour les raisons d'un ordre du plus grand au plus petit, inversé de l'ordre plus petit au plus grand des DNS, voir cette question sur Stack Overflow.

Je n'ai jamais personnellement défini un applicationId pour une application Android, mais j'ai dû utiliser des identités d'application très similaires dans iOS. Quand j'ai fait cela, j'ai délibérément évité d'utiliser le nom DNS de l'entreprise car cela avait changé plusieurs fois au cours de la décennie précédente. Il semblait préférable d'utiliser la forme longue du nom de l'entreprise, la ligne de métier (qui a changé entre plusieurs divisions plusieurs fois) et une identité pour l'application individuelle.

Vous constaterez que la direction exécutive des grandes entreprises se moque de toute relation que vous pourriez établir entre les noms DNS et les valeurs d' applicationId Android. Ils ont des gens pour s'occuper de ces choses pour eux, les développeurs d'applications. Si vous vous plaignez qu'ils créent des problèmes en réorganisant l'entreprise, ils entendront cela comme "Je ne peux pas faire mon travail correctement et je suis assez fou pour que cela soit évident."

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X