Речь не только о пермишенах. Например могут быть разные apk для разхных xxhdpi и mdpi

не понял почему не надо то? мне такую задачу поставили.

если цель задачи решить проблему с пермишенами то собирать две сборки для этого не нужно, попробуй почитать про пермишены детальней все будет отлично работать и на одной сборке просто поведение для разных версий в коде учтёшь. Там всё просто

если цель задачи решить проблему с пермишенами то собирать две сборки для этого не нужно, попробуй почитать про пермишены детальней все будет отлично работать и на одной сборке просто поведение для разных версий в коде учтёшь. Там всё просто

ну смотри там в манифесте если указать пермишены, то они на <23 будут при установке даваться

на <23 мы просто не будем использовать пермишен и фишки, использующую этот пермишен просто не будет

да, и на 23 будут все что нормальные, а те что опасные будут спрашиваться

а на 23 будем в рантайме просить пермишен

ладно, поведусь на наброс и попробую в третий раз: на 23+ <uses-permission> с системеными пермишеннами игнорируется

иг

игнорируется

не дописал :(

ИГНОРИРУЮТСЯ

спасибо

ладно, поведусь на наброс и попробую в третий раз: на 23+ <uses-permission> с системеными пермишеннами игнорируется

да понял это

ну если для вас это принципиально, тогда flavors и разные классы с разными манифестами по разным папочкам закинь и чекни что всё верно работает после сборки

то есть можно в манифесте вообще не указывать?

чисто в рантайме просить?

то есть неважно, есть они в манифесте или нет

да

эффект один и тот же

нет, нельзя)

там вообще очень разное поведение может спокойно быть в зависимости от того написал ты пермишен в манифесте или нет, но не со всеми

нет, нельзя)

нельзя не указывать?

оу оу меня запутали(

во

короче в манифестах кроме пермишенов будет отличаться targetSdk

а кстати, да, я наркоман – нужно всегда указывать в манифесте для списка пермишенов у приложения в настройках

и правда: " The app has to list the permissions in the manifest, and it must request each dangerous permission it needs while the app is running. "

вот прямо всегда

вот вы меня запутали братцы(

нельзя не указывать?

TODO 1. Указывай все Permission которые надо будет использоват ьв manifeste. 2.а Для post23 устройств запрашивай их 2b. Для pre23 они будут браться из манифеста. 3.Profit!!!11

Кстати, ещё такая штука есть, что на некоторых китайцах ещё до 6ки есть возможность отобрать права

там не всё по доке, есть и кейсы где дока не валидна. Но это уже другая история ?

TODO 1. Указывай все Permission которые надо будет использоват ьв manifeste. 2.а Для post23 устройств запрашивай их 2b. Для pre23 они будут браться из манифеста. 3.Profit!!!11

да мне не надо 2b

pre 23 не должно вообще иметь пермишенов этих!

фича доступно только post23

дык вот с этого стоило начинать

вообще если для тебя критично что бы на pre23 не было то флаворы тебя спасут

дык вот с этого стоило начинать

я с этого и начал, но меня недопоняли(

ну, как сказал, так и поняли ¯\_(ツ)_/¯

ну, как сказал, так и поняли ¯\_(ツ)_/¯

?

ребят

вообщем у меня test,prod,preprod

добавил туда ещё post23, pre23. И стало 6 флавором блин!(( post23test, post23prod, post23preprod, pre23test, pre23prod,pre23preprod

flavorDimensions "targetApi", "serverType" productFlavors { flavorTest { dimension "serverType" } flavorPreprod { dimension "serverType" } flavorProd { dimension "serverType" } pre23{ dimension "targetApi" } post23{ dimension "targetApi" } }

можно ли в каждом указать сразу 2 дименшена ? т.е. flavorTest { dimension "serverType" , "targetApi" } типо хочу чтобы он мне собрал 2 апк flavorTestPre23.apk и flavorTestPost23.apk

как так объявить?

ибо при объявлении как у меня выше он просто строит декартово произведение всех возможных флаворов

ну типо как в бд)

А вот такой вопрос к адептам: Может ли конкретная система(версия андроида) менять порядок выполнения команд в байткоде?

может

честно гвооря я не понял нафига вообще flavorsDimensions нужны? также можно просто больше flavors сделать

все верно

gradle compile соберёт тебе все флаворы в дебаг и релиз варианте. Также можно собрать только релизные и только дебажные версии

а как вы обычно храните в проекте данные для подписывания сборки? ведь чтобы собрать релиз надо же их где-то в проекте держать или есть другие пути?

если только у тебя не 4 измерения

если только у тебя не 4 измерения

ну вообще-то их четыре...и у него и у тебя

честно гвооря я не понял нафига вообще flavorsDimensions нужны? также можно просто больше flavors сделать

они нужны если ты разделяешь флейворы по разным измерениям (параметрам) и не хочешь сам руками набивать все их сочетания

например у тебя есть Free/Paid и Test/Production

если только у тебя не 4 измерения

и 4 можно описать, то есть это тупо удобство не более?

ты настраиваешь каждое измерение со своими параметрами

и 4 можно описать, то есть это тупо удобство не более?

нет дублирования параметров в настройке

ты настраиваешь каждое измерение со своими параметрами

получается тупо удобство? фии бле. я думал они позволяют много апк на 1 флейворк генерить

и 4 можно описать, то есть это тупо удобство не более?

4 по 4 варианта это уже 256 вариаций, что несколько трудоемко )

4 по 4 варианта это уже 256 вариаций, что несколько трудоемко )

ясно, ну это не мой случай

позволяют геренирь более одного апк на одно значение одного параметра (то есть по одному апк на каждую комбинацию всех параметров)

4 по 4 варианта это уже 256 вариаций, что несколько трудоемко )

почему 256 то? не 16 разве ? 4х4 ?

1 2 3 4 a b c d 1a 1b 1c

1d

ERROR: S client not available

4 * 4 * 4 * 4

4 измерения по 4 вариации

аа понял

например сервера, пакаджи, сезонные билды, версии сдк

делает дохерищща разных апк

)

4 измерения по 4 вариации

1 2 3 4 a b c d 1a, 1b, 1c, 1d 2a, 2b, 2c, 2d 3a, 3b, 3c, 3d 4a, 4b, 4c, 4d что пропустил?

у тебя 2 измерения

а как вы обычно храните в проекте данные для подписывания сборки? ведь чтобы собрать релиз надо же их где-то в проекте держать или есть другие пути?

Обычно или в спец файле, который не попадает в Git, у меня сейчас вообще прописаны в переменных среды окружения, и оттуда читаю

Обычно или в спец файле, который не попадает в Git, у меня сейчас вообще прописаны в переменных среды окружения, и оттуда читаю

то есть это файл просто тупо в гитигноре?

да, какой нить keys.properties

да, какой нить keys.properties

ясно, спасибо

Обычно или в спец файле, который не попадает в Git, у меня сейчас вообще прописаны в переменных среды окружения, и оттуда читаю

А как быть если ты решил на другом компе собрать сборку?

а как вы обычно храните в проекте данные для подписывания сборки? ведь чтобы собрать релиз надо же их где-то в проекте держать или есть другие пути?

CI

всмысле на сервере сборки лежат только и забекапленные, доступ к релизному ключу должен быть у как можно меньшего количества людей

но в целом наплевав на безопастность можно в git-е том же держать

безопасность задается ключем, а не хранилищем

но в целом наплевав на безопастность можно в git-е том же держать

Да только в опенсорс репозитории так не стоит делать

ключи можно отдельным сервером раздавать

а его уже анально отгородить от левых личностей

а его уже анально отгородить от левых личностей

Смысл фразы мне видится так: чувак смотрит в проект и вместо ключа видит картинку анального прохода.

безопасность задается ключем, а не хранилищем

ключь можно и брутфорсить

ключь можно и брутфорсить

Сложный ключ не забрутфорсишь

Смысл фразы мне видится так: чувак смотрит в проект и вместо ключа видит картинку анального прохода.

как-то так

ключь можно и брутфорсить

может и можно, но я не вижу способов, как эти ключи потом применить

может и можно, но я не вижу способов, как эти ключи потом применить

Тогда зачем его вообще прятать?

так я и храню в гите и ключ и пароль )

Применить можно если доступ есть в консоль этого чела. Можно релизнуть апп.

Апдейт выкатить.

сомнительный кейс, конечно

так я и храню в гите и ключ и пароль )

так 2FA же должна быть