Android Studio (utilisant les SDK 19, 21 ou 22) indique une erreur non détectée par Eclipse ADT (utilisant le SDK 19):
Erreur: image 9 correctifs D:\Espaces de travail ....\res\drawable-hdpi\btn_bg_common_press.9.png malformés . Erreur: les pixels de l'image doivent être soit pleins, soit transparents (et non des alphas intermédiaires). - Trouvé au pixel n ° 4 le long du bord supérieur.
Ou une autre erreur :
Erreur: Les graduations dans le cadre transparent doivent être en noir ou en rouge.
à la fois dans aapt
Erreur: Erreur: com.Android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: processus 'commande' E:\Android\sdk-Android-Studio\build-tools\19.1.0\aapt .exe '' fini avec une valeur de sortie non nulle 42
L'exemple de fichier est ci-dessus, mais il existe plus de 20 fichiers de ce type qui ont bien fonctionné.
Comment puis-je obliger Android Studio ou Gradle à ignorer cette erreur et à ne pas échouer sans avoir à modifier ces fichiers un par un?
Si cela n’est pas possible avec Gradle, quel outil de ligne de commande puis-je utiliser pour remplacer tous les pixels transparents par des pixels non transparents?
Le fichier build.gradle du module d'application (où se trouvent les ressources) est présenté ci-dessous.
J'ai essayé les deux avec SDK 19 et SDK 21 et construire les outils 19.1, 21.1.2, 22 .
Un problème similaire sur AOSP, Issue 159464: Studio Android: mergeDebugResources FAILED lors de l’importation du projet Eclipse .
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.Android.tools.build:gradle:1.1.+'
}
}
allprojects {
repositories {
jcenter()
}
}
//---
task wrapper(type: Wrapper) {
gradleVersion = '2.2.1'
}
apply plugin: 'com.Android.application'
dependencies {
compile fileTree(dir: 'libs', include: '*.jar')
compile project(':afinal')
compile 'com.Android.support:appcompat-v7:19.0.+'
//compile 'com.Android.support:appcompat-v7:21.0.+'
}
//---
Android {
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
res.srcDirs = ['res']
assets.srcDirs = ['assets']
}
}
compileSdkVersion 19
buildToolsVersion "19.1.0"
//compileSdkVersion 21
//buildToolsVersion "21.1.2"
//compileSdkVersion Integer.parseInt(project.COMPILE_SDK_VERSION)
//buildToolsVersion project.BUILD_TOOLS_VERSION
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-Android.txt'), 'proguard-rules.txt'
zipAlignEnabled true
//signingConfig signingConfigs.release
}
debug {
zipAlignEnabled true
}
}
lintOptions {
//checkReleaseBuilds false
// Or, if you prefer, you can continue to check for errors in release builds,
// but continue the build even when errors are found:
abortOnError false // false also required by https://wiki.jenkins-ci.org/display/JENKINS/Android+Lint+Plugin
}
}//Android
Les sources des plugins Android Gradle sont à https://Android.googlesource.com/platform/tools/build/+/master .
Comment résoudre automatiquement le problème (sans vérifier toutes les images dans des résolutions différentes)
Pas possible. Puisque vous voulez que le fichier .png se comporte comme un correctif neuf (développez le long des bords, ne déployez pas le bitmap en entier), vous devrez les formater de manière ergo vous devez modifier les fichiers}. .
Alternative proposée
Étant donné que la forme est si simple, il serait préférable de supprimer toutes les variantes de ce fichier (gain de temps, d'espace et de mal de tête) et de créer /res/drawable/btn_bg_common_press.xml
pouvant être dessiné avec le contenu suivant:
<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:Android="http://schemas.Android.com/apk/res/Android"
Android:shape="rectangle">
<corners Android:radius="16dp"/>
<solid Android:color="#ccc"/>
<stroke
Android:color="#0c0"
Android:width="2dp"/>
</shape>
Vous pouvez utiliser les ressources dimen
et color
au lieu de valeurs codées en dur. De plus, vous voudrez peut-être ajouter l'élément padding
à l'intérieur de shape
<shape...>
<padding
Android:top="8dp"
Android:left="8dp"
Android:bottom="8dp"
Android:right="8dp"/>
</shape>
et/ou envelopper l'élément shape
dans un élément inset
.
<inset
xmlns:Android="http://schemas.Android.com/apk/res/Android"
Android:insetTop="8dp"
Android:insetLeft="8dp"
Android:insetBottom="8dp"
Android:insetRight="8dp">
<shape...>
</inset>
Si vous faites cela, le dessinable aura un remplissage implicite et vous n’aurez pas à le définir lorsque vous stylisez des widgets. Puisque vous avez plusieurs états pouvant être dessinés pour le bouton, je vous suggère de les convertir tous en XML pour vous assurer que l'épaisseur de la ligne et les coins correspondent.
Malgré le nom de l'élément racine, le <shape>
est gonflé à GradientDrawable
(ce qui signifie que vous pouvez le remplir avec un dégradé au lieu d'une couleur unie). Passez en revue GradientDrawable
docs pour toutes ses options. Ne pas (jamais} _ utiliser ShapeDrawable
par programme, cela ne fonctionne tout simplement pas.
Analyse de 9 patchs
Considérez les trois images agrandies suivantes.
Le candidat n ° 1 est un patch neuf. Il a réservé 1px de chaque côté pour les spécifications d'étirement et de rembourrage. Celui-ci se comportera comme un bitmap ordinaire lorsqu'il sera étiré. Si la largeur est supérieure à la hauteur, l'épaisseur de la bordure sur les côtés l'est également. La frontière sera proportionnelle.
Le candidat n ° 2 est également un correctif de neuf correctifs et dit en fait qu'il va tout étirer en plus de la bordure 1px et qu'il impliquera un remplissage de 3px de chaque côté. Il aura une belle frontière 1px Nice lorsqu'il est étiré.
Le candidat n ° 3 est ET NON un neuf patch. Il évolue de la même manière que le n ° 1.
Voyons maintenant la version agrandie de l'image que vous avez incluse dans OP:
Comme vous pouvez le constater, ce n'est pas un correctif neuf, il ne sera donc pas interprété comme tel et les outils de compilation sont assez gentils pour vous en avertir. Même si les anciens outils de construction étaient plus tolérants et ajoutaient 1px transparent de chaque côté pour vous, le résultat se comporterait comme un bitmap ordinaire, ce qui signifie que, une fois étendu, il ressemblerait à l'échantillon A au lieu du résultat attendu B.
Voici plus de lecture sur neuf patchs . Ceci explique pourquoi 1px supplémentaire de chaque côté est utilisé.
L'exemple donné n'est pas une image de 9 patch, comme cela a été dit.
Si vous ne souhaitez pas modifier chaque ressource afin de la transformer en une ressource corrective 9 valide, vous pouvez essayer de supprimer ".9" dans le nom de la ressource. De cette façon, le comportement devrait être identique et vous ne recevrez pas d'erreurs de construction.
Android a maintenant deux crunchers PNG, l'un AAPT et un Java. Pour ignorer l'erreur PNG dans le processus de construction, vous pouvez forcer la génération Gradle à utiliser l'ancien AAPT en définissant la ligne ci-dessous dans votre fichier build.gradle:
Android.aaptOptions.useAaptPngCruncher = true
Néanmoins, cela peut vous donner la même erreur, car l’outil AAPT du dernier SDK peut également rechercher cette erreur. Donc, vous avez deux options:
Recherchez un ancien AAPT, par exemple, <chemin du SDK> /build-tools/17.0.0/aapt, remplacez votre SDK AAPT actuel par l'ancien. Vos problèmes de construction peuvent maintenant être résolus. Si cela ne fonctionne pas, essayez l'option ci-dessous.
Écrivez un simple script Bash ou Perl, nommez-le "aapt" et placez-le dans votre dossier actuel d'outils de compilation du SDK. Ce script appelle l'ancienne version 17 AAPT pour votre * 9.png et utilise le nouvel AAPT pour tout le reste. Voir cette réponse de débordement de pile pour un exemple de script.
Pour résoudre ce problème, assurez-vous de remplir tous les bords avec des points noirs ou rouges. Cela a résolu mon problème pour toutes les versions du SDK. Si vous ne souhaitez pas redimensionner verticalement ou horizontalement ou les deux, remplissez simplement tous les bords. Dans ce cas, l'image n'est pas à l'échelle.