Почему вариант сборки релиза всегда доступен для отладки?

Создаю ли я «выпуск» APK:

  • Используйте Генерировать подписанный APK в Android Studio
  • Выберите вариант сборки Release и используйте Tools -> Build APK.
  • Запустите задачу assembleRelease

... произведенный APK всегда имеет debuggable=true, что я подтвердил, попытавшись загрузить их в Google Play, в котором говорится:

«Ошибка загрузки. Вы загрузили отлаживаемый APK. По соображениям безопасности вам необходимо отключить отладку, прежде чем его можно будет опубликовать в Google Play».

В (единственном) манифесте не указан атрибут отладки. Gradle указывает debuggable=false для выпуска и true для отладки, см. ниже.

Что мне не хватает? Откуда берется состояние отладки и почему значение debuggable=false в объявлении типа сборки релиза игнорируется? Я не хочу добавлять debuggable=false в манифест и постоянно включать/отключать его вручную.

приложение/build.gradle:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 26
    buildToolsVersion '26.0.0'
    defaultConfig {
        applicationId "com.myapp.android"
        minSdkVersion 14
        targetSdkVersion 26
        versionCode 5
        versionName 5
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }

    signingConfigs {
        release {
            storeFile rootProject.file("keystore.jks")
            if (storeFile.exists()) {
                def config = new Properties()
                config.load(new FileInputStream(rootProject.file("keystore.passwords")))
                storePassword config.KeystorePassword
                keyAlias config.KeyAlias
                keyPassword config.KeyPassword
            }
        }
    }

    buildTypes {
        release {
            debuggable false
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
        debug {
            debuggable true
            applicationIdSuffix ".debug"
        }
    }

    dataBinding {
        enabled = true
    }

    lintOptions {
        disable 'RtlHardcoded'
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    // Copy release APK to project root
    task copyReleaseApk(type: Copy) {
        from 'build/outputs/apk'
        into '..'
        include '**/*release.apk'
    }

    afterEvaluate {
        if (tasks.findByPath("packageRelease") == null) {tasks.create("packageRelease")}
        tasks.findByPath("packageRelease").finalizedBy(copyReleaseApk)
    }

}

ext {
    // Single place to specify the support library version
    supportLibraryVersion = '26.0.0-beta2'
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
        exclude group: 'com.google.code.findbugs'
        exclude module: 'espresso-idling-resource'
        exclude group: "javax.inject"
    })
    implementation 'com.android.support.test.espresso:espresso-contrib:2.2.2'

    // Dagger dependency injection
    implementation 'com.google.dagger:dagger:2.10'
    annotationProcessor 'com.google.dagger:dagger-compiler:2.10'
    implementation 'com.google.dagger:dagger-android:2.10'
    implementation 'com.google.dagger:dagger-android-support:2.10'
    annotationProcessor 'com.google.dagger:dagger-android-processor:2.10'

    implementation "com.android.support:appcompat-v7:$supportLibraryVersion"
    implementation "com.android.support:design:$supportLibraryVersion"
    implementation "com.android.support.constraint:constraint-layout:1.0.2"

    implementation "com.jakewharton.timber:timber:4.5.1"
    implementation "com.squareup.phrase:phrase:1.1.0"
    implementation "com.squareup.retrofit2:retrofit:2.2.0"
    implementation "com.squareup.retrofit2:converter-gson:2.2.0"
    implementation "com.squareup.okhttp3:logging-interceptor:3.7.0"
    implementation 'net.danlew:android.joda:2.9.9'

    testImplementation 'junit:junit:4.12'
    implementation 'com.google.firebase:firebase-crash:11.0.0'
    androidTestImplementation 'junit:junit:4.12'
}

apply plugin: 'com.google.gms.google-services'

Обновление 1: я попытался добавить debuggable=false в манифест, и это не имеет значения, созданный APK по-прежнему не может быть загружен в Google Play.

Обновление 2: я загрузил APK обратно в Android Studio с помощью анализатора APK, который упрощает просмотр манифеста, и все они включают... debuggable=true. Откуда это?

Обновление 3: assembleRelease создает отлаживаемый APK как на моем локальном компьютере, так и на сервере CI (BuddyBuild).

Обновление 4: чистая перестройка (включая удаление папок сборки) и перезапуск Android Studio с очищенными кэшами не имеет значения.

Обновление 5. Кажется разумным предположить, что состояние debuggable=true может исходить от одной из зависимостей, но если это так, то какую и как это можно переопределить?


person Ollie C    schedule 21.06.2017    source источник
comment
Вы уверены, что загружаете правильный APK?   -  person Eselfar    schedule 21.06.2017
comment
Да, я пробовал много APK из нескольких папок, созданных различными способами, описанными выше, и очищал папку перед созданием нового APK.   -  person Ollie C    schedule 21.06.2017
comment
это происходит, если вы удалите использование copyReleaseApk?   -  person petey    schedule 21.06.2017
comment
@petey Я пытался отключить это, но это не дало результата - APK все еще содержал данные отладки.   -  person Ollie C    schedule 22.06.2017
comment
Кажется разумным предположить, что состояние debuggable=true может исходить от одной из зависимостей, но если это так, то какую и как это можно переопределить? -- в Android Studio откройте свой манифест, затем выберите вложенную вкладку «Объединенный манифест». Кроме того, если вы используете aapt, сообщает ли он также, что APK можно отлаживать?   -  person CommonsWare    schedule 22.06.2017
comment
@CommonsWare Тайна углубляется, поскольку в объединенном манифесте отладка ложна.   -  person Ollie C    schedule 22.06.2017
comment
Если aapt говорит, что APK является отлаживаемым, то это может означать, что Gradle делает ваше приложение отлаживаемым, и я не понимаю, почему. Если aapt говорит, что ваше приложение недоступно для отладки, вероятно, ваша проблема связана с Play Store.   -  person CommonsWare    schedule 22.06.2017
comment
@commonsware './aapt dump xmltree MyApp v0.22.0-release.apk AndroidManifest.xml | grep debuggable» выдает следующий вывод: A: android:debuggable(0x0101000f)=(type 0x12)0xffffffff, поэтому APK по определению отлаживаемый.   -  person Ollie C    schedule 22.06.2017
comment
На данный момент единственный способ, который я вижу, чтобы определить источник проблемы, — это классическая отладка с бинарным поиском: клонировать проект, вырвать половину его, посмотреть, можно ли это отладить. Если это так, вырвите больше и повторите. Если это не так, начните добавлять материал обратно и повторите. Вспеньте и промойте по мере необходимости. Или создайте совершенно новый проект, подтвердите, что release сборки не подлежат отладке, а затем начните добавлять вещи, пока состояние не изменится.   -  person CommonsWare    schedule 22.06.2017
comment
См. также stackoverflow.com/questions /40886001/   -  person Ollie C    schedule 17.04.2018


Ответы (2)


Поскольку проект нацелен на API 26 и использует 3.0.0-alpha4 плагина Android Gradle, инструменты сборки 26.0.0-beta2 и Gradle 4.0-rc1, я подумал, что должен проверить, что проблема не связана с проблемой с этими предварительными -освобождение инструментов. Поэтому я вернулся к API 25 и стабильным выпускам gradle 3.3, плагину gradle 2.3.3 и инструментам сборки 25.0.3. Это было немного утомительно, так как мне пришлось понизить весь синтаксис Java 8 с исходного кода до Java 7. Но после этого процесс сборки теперь работает должным образом и создает артефакты APK выпуска, которые не содержат флага debuggable="true" и могут быть загружены в Google Play. ????

Я не совсем понимаю, в чем причина, но я зарегистрировал это в системе отслеживания ошибок инструментов Android, так как возможно, что это ошибка: https://issuetracker.google.com/issues/62899843

ОБНОВЛЕНИЕ: Команда инструментов ответила, что это ожидаемое поведение, поскольку приложение нацелено на API 26 и находится в предварительной версии. Я думал, что, поскольку 26 API-интерфейсов были окончательными, APK-файлы могут быть созданы для них и выпущены в Google Play, но это явно не так.

person Ollie C    schedule 22.06.2017
comment
Похоже, что манифест все еще должен содержать явное значение debuggable=false - person Ollie C; 22.06.2017

Это связано с тем, что у вас, вероятно, есть добавочные сборки, по умолчанию все добавочные сборки предполагаются debuggable.

В разделе Общие примечания к SDK Tools, редакция 8, состояния:

Поддержка настоящей отладочной сборки. Разработчикам больше не нужно добавлять атрибут android:debuggable к тегу в манифесте — инструменты сборки добавляют этот атрибут автоматически. В Eclipse/ADT все добавочные сборки считаются сборками отладки, поэтому инструменты вставляют android:debuggable="true". При экспорте подписанной сборки выпуска инструменты не добавляют атрибут. В Ant команда ant debug автоматически вставляет атрибут android:debuggable="true", а ant release - нет. Если android:debuggable="true" установлен вручную, то ant release фактически выполнит сборку отладки, а не сборку выпуска.

person Dayan    schedule 21.06.2017
comment
При экспорте сборки подписанного выпуска инструменты не добавляют атрибут — если это означает использование Generate Signed APK или Build APK, то это не проблема, так как оба этих подхода по-прежнему создают отлаживаемый APK. Я пробовал чистые полные перестроения без успеха. - person Ollie C; 21.06.2017