Wear App et avec un type de construction personnalisé avec applicationIdSuffix

J'ai une application où j'aimerais ajouter une extension d'application Android Wear. L'application principale comporte trois types de construction (débogage, version bêta et version). Les versions bêta ont une applicationIdSuffix qui me permet d'installer parallèlement la version Play-Store et la version de développement actuelle sur le même périphérique. Cela a bien fonctionné jusqu'à ce que j'ai ajouté l'application d'usure.

Le build.gradle de l' build.gradle principale ressemble à ceci:

  • Est-ce que nous pouvons utiliser iBeacon pour transférer des données via bluetooth dans iOS - Android?
  • Comment obtenir une instance de service local Android
  • Numéro arabe en texte arabe dans Android
  • Lire la vidéo m3u8 dans Android
  • RecyclerVoir différents élémentsDécoration pour différents articles
  • Logcat ne peut pas détecter les noms d'application ou de package
  •  apply plugin: 'com.android.application' android { ... defaultConfig { ... applicationId "com.example.mainApp" ... } buildTypes { debug { applicationIdSuffix '.debug' } beta { applicationIdSuffix '.beta' } release { } } } dependencies { ... wearApp project(':wear') } 

    L'application Wear a les mêmes types de construction avec les mêmes valeurs applicationIdSuffix. Cependant, lorsque je gradle assembleBeta application bêta (en appelant gradle assembleBeta ), le build build builds :wear:assembleRelease au lieu de :wear:assembleBeta c'est pourquoi je reçois le message d'erreur suivant lors de la compilation:

     FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':app:handleBetaMicroApk'. > The main and the micro apps do not have the same package name. 

    Comment puis-je indiquer au processus de construction de créer le type de construction correct lors de l'emballage de l'application principale avec le type de construction beta ?

  • Envoyer des mises à jour de localisation à IntentService
  • Comment modifier les sous-titres dans mediaplayer
  • Comment utiliser SwipeRefreshLayout?
  • Existe-t-il des sons intégrés / par défaut qui peuvent être utilisés dans une application?
  • Les boutons Eclipse comme Step in, Step out, resume etc. ne fonctionnent pas
  • Extraire l'image en noir et blanc du format NV21 de la caméra Android
  • 4 Solutions collect form web for “Wear App et avec un type de construction personnalisé avec applicationIdSuffix”

    Suite au lien publié par Scott Barta ( http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication ) Je suis venu avec ceci:

    Dans build.gradle de l'application d'usure, ajoutez publishNonDefault true (pour publier toutes les variantes):

     android { publishNonDefault true } 

    Dans build.gradle de l'application principale,
    Remplacer

     wearApp project(':wear') 

    Par

     debugWearApp project(path:':wear', configuration: 'debug') releaseWearApp project(path:':wear', configuration: 'release') 

    Vous ne pouvez pas faire ce que vous voulez; La variante de construction d'un module ne se propage pas aux builds des modules dépendants lors de la construction. Ceci est suivi dans https://code.google.com/p/android/issues/detail?id=52962

    Il existe une possibilité de faire en sorte qu'un module dépend d'une variante spécifique d'un autre, tel que documenté dans http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication , mais Je ne pense pas que ce mécanisme puisse être étendu pour faire un emballage différentiel des applications Wear.

    MISE À JOUR Maintenant, il existe un soutien officiel pour les variantes de construction (voir la réponse de Cyril Leroux ). Par conséquent, cette réponse est obsolète.


    J'ai trouvé une solution très (très) moche qui présente certains inconvénients, mais fonctionne pour l'instant jusqu'à ce qu'il y ait un support pour les variantes de construction pour les applications d'usure.

    J'ai configuré une variable globale dans le répertoire racine qui contient l' applicationIdSuffix de l'application principale actuellement créée.

    Dans build.gradle de l'application principale, j'ai ajouté ce qui suit:

     // Set a global variable, depending on the currently built build-type. // This allows us to set the applicationIdSuffix of the wear app depending on // the build-type of the main app. android.applicationVariants.all { variant -> def task = variant.checkManifest def suffix = variant.buildType.applicationIdSuffix task.doLast { rootProject.ext.currentApplicationIdSuffix = suffix } } 

    Dans le build.gradle de l'application d' usure, j'ai ajouté les suivants:

     android.applicationVariants.all { variant -> def task = variant.generateBuildConfig task.dependsOn(propagateApplicationIdSuffix) } task propagateApplicationIdSuffix << { project.android.buildTypes.all { type -> if (rootProject.hasProperty('currentApplicationIdSuffix')) { type.applicationIdSuffix = rootProject.ext.currentApplicationIdSuffix } } } 

    Cela présente plusieurs inconvénients:

    1. Vous ne pouvez pas créer de multiples variantes (c.-à-d. gradle assembleBeta assembleRelease ), car l'application d'usure n'est construite qu'une seule fois et, par conséquent, le deuxième type de construction échoue
    2. gradle check échoue en raison de la raison 1
    3. L'application d'usure est toujours construite avec la version de type de construction, mais le nom du paquet est simplement modifié selon le suffixe de l'application ID de l'application principale

    Ne vous inquiétez pas, vous pouvez faire ce que vous voulez faire. Je l'ai fait pour l'application d'entreprise sur laquelle je travaille.

    La clé NE DOIT PAS utiliser le projet wearApp (': wear'), car cela ne fonctionne que lorsque vous avez la même application dans votre application d'usure que votre application principale. Et faisons-nous face, combien de fois dans la vie réelle est-ce que cette situation se produit? Si cela se produit, vous n'utilisez probablement pas Gradle au meilleur de sa capacité.

    Vous souhaitez suivre les instructions pour le paquetage manuellement dans les docs google usages https://developer.android.com/training/wearables/apps/packaging.html#PackageManually

    Malheureusement, cela vous obligera à créer votre application d'usure avec le même application que la variante de construction particulière que vous faites à l'heure, mais cela vous permet de bien remplacer l'application d'usure dans une application avec plusieurs applications.

    En outre, un truc que je fais aide est de ne pas mettre l'apk d'habillement à l'intérieur / res / raw, mais dans / assets, de cette façon, vous n'avez pas à faire face à Andriod Studio en compriant l'apk.

    J'espère que cela t'aides! Je me suis fou de quelques jours pour trouver une solution. Et le seul tutoriel est en français, et j'ai dû traduire le site pour le lire! https://translate.google.com/translate?hl=fr&sl=auto&tl=en&u=http%3A%2F%2Fblog.octo.com%2Fpackager-une-application-android -wear-dans-la-vraie-vie% 2F

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.