The current size of the APK is 820 bytes.
Там ещё PR до 678 висит. Ещё чуть-чуть, и можно остановится на 666.
Ах, здорово. Вот что называется настоящий гольф.
А то, помню, на stackoverflow был какой-то странный гольф, где можно было использовать всевозможные «читерские» ухищрения, вроде использования специализированных языков для гольфа, и даже — своих собственных!

Конечно, дело ещё не дошло до файла состоящего из двух символов, но всё же, сжатие кода под громоздкий C куда более интересный труд, чем использования других языков.
Использование DSA Keystore, уменьшение размера манифеста (1295 байт, сокращение на 26%)
Манифест дополнительно оптимизирован с использованием скомпилированного XML-файла, и использования DSA Keystore меньше по размеру, чем его создаёт Android Studio.

Сплошное сжатие zopfli (1180 байт, сокращение на 9%)
Улучшение сжатия APK.

Использование сигнатуры эллиптической кривой (922 байта, сокращение на 16%)
Подписи эллиптической кривой еще меньше чем DSA, и поддерживаются в подписи APK v2.

Удаление classes.dex (824 байта, уменьшение на 11%)
Если в манифесте отсутствует элементы кода, для PackageParser не требуется файл classes.dex.

Дальнейшая ручная настройка манифеста (820 байт, сокращение на 0,5%),
Дальнейшая оптимизация байтового уровня манифеста.
Что происходит с отображением самого apk файла? Он запускается, или после всех ухищрений остаётся только сам факт валидности APK?
Второе. Он устанавливается и всё :)

Скиньте статью разработчикам из фейсбука кто-нибудь

Простите, но это прекрасно!
Теперь сделайте тоже самое с APK, собираемым QtCreator
Да вроде приемлемого размера получается.
Да там же кутишные библиотеки вшиваются, министро или как их там. Вообще, меня это нисколько не смущает.

министро- это отдельный apk, но да же без него у меня на простых приложениях получалось в районе 9 Mb.

Кто-то из нас двоих что-то путает. Насколько помню, при сборке можно выбрать встраивать библиотеки qt или нет. Вот с ними получается ~9мб, без них значительно меньше, но без них у меня и с установленным министро никогда ничего не запускалось, даже hello world.
круто. разбалованы железом мы.
Однако 1,5 Мб для Hello world это очень и очень!
Почитать интересно, но в реальной жизни большинство не пригодится…
Как минимум как уже обойтись без support library? Не говоря уже о сокращении манифест файла, смене иконки, и тем более о keystore.
Некоторые могут быть не в курсе про proguard, как он работает и настраивается. Кто-то не следит за тем, какие именно файлы попадают в apk. Да даже support library можно подключить не целиком, а только -core-ui, если не требуются все возможности библиотеки одновременно. Причём, несмотря на использование proguard для удаления неиспользуемого кода, подключение лишь части библиотеки вместо полной версии даёт ощутимую разницу в размере релизного приложения.
Был у меня проект (с конфигами по-умолчанию) на Eclipse без Gradle, который по умолчанию собирал apk до размера 200Кб. Перенос в Android Studio увеличил файл до 1Мб.
Смена системы сборки ничего не добавляет сама по себе. Возможно, автоматически подключились библиотеки совместимости (support library), от которых в статье избавлялись на втором шаге.
Покупал как-то чайник Redmond, который с управлением через Bluetooth, поставил программу на смартфон для удалённого управления чайником. 47 Мб…

Эту штуку делают Ready for Sky, раньше пилили приложение на C++/Qt, но похоже перешли на Java

Интересно, что такой высокотехнологичный чайник я сдал через два месяца использования по гарантии, так как у него просто-напросто лопнуло крепление крышки. Я подозреваю, что из-за несоответствия прочности пластика и силы удерживающей его пружины.
Интересно, хоть один заявит, что нет корреляции между качеством чайника и качеством приложения, уровнем инженерной проработки решения девайса и инженерной проработки софта? )
Я бы лучше спросил, нафига там с самого начала блютуз (понятно, что с ним все становится круче), если он все равно до кухни не добивает? %)

Чтобы можно было гордо отвечать статусом 418 I'm a teapot в ближайшем IOT-окружении.

Ухаха, точно! С другой стороны, и в чайнике уже без веба не обошлось… %)
В этих чайниках нет самого очевидного — нельзя удаленно узнать, сколько в нем воды. Можно вкл/выкл и цвет подсветки менять. А зачем его включать, если в нем кончилась вода?..
Неужели ни в одном нет?! Тогда это вообще жесть какая-то. Буквально. %)
Недавно тоже купил такой. Не особо полезно, но юзкейсы всё же есть — подогреть чайник, чтобы налить вторую кружку чая, например. В этом случае вода в нём остаётся, но после первой кружки могло пройти достаточно времени. Так вот, теперь включаю его, не вставая из-за компьютера.
но
(на самом деле всё это не важно и не нужно, я просто поиграться его купил, потому что это клево, и оправдываюсь теперь)

Там есть цифровая регуляция температуры чайника — вот это реально нужная мегафича ) Запарить дрожжи — греем чайник до 40, горячая не обжигающая вода — 60… вообщем до 100 градусов чайник греем редко. И через синийзуб можно выставлять температуру с точностью до градуса ))

Представил себе чайник-криптоферму… :)
создать приложение минимально возможного размера, которое можно установить на Android 8.0 Oreo

Почему нельзя было бы установить на android 8?

Статья как нельзя кстати рассказывает почему не смотря на рост производительности устройств и выходов новых версий ОС устройства в среднем все равно работают медленно)
Существует такая игрушка .kkrieger 96кб с графикой уровня Q3 но никому не нужна такая оптимизация, нужно чтобы заводы штамповали девайсы а кодеры писали тонны кода под который были бы нужны все более емкие хранители, а потом это все потребляет больше энегрии и так далее… :)
Ну, ради честности — что пример из статьи (после определенного момента, когда пример уже не мог запускаться), что та игрушка, это не совсем оптимизация, это уже, скорее, выжимание всех соков, экстрим. :)
Оптимизация требует времени программиста (а также тестировщика и менеджера), а следовательно большего бюджета. Все хотят оптимизированные программы, но мало кто захочет переплачивать вдвое/втрое за оптимизацию.
При этом ВСЕ переплачивают за НЕоптимизацию. :) Новым железом, электричеством, временем…
Все равно основная оптимизация приложений под Андроид — разрешение на установку на сменный носитель. Таким приложениям памяти хватает.
Не во всех устройствах есть этот сменный накопитель. И начиная с какой-то версии Android API значение этого параметра сменилось с дефолтного (перенос разрешён пользователем) на отключённое, нужно явно разрешать в манифесте. Из-за этого многие программы потеряли возможность переноса, даже если раньше её имели.
Не во всех, но почему не прописать один параметр, облегчая пользователям жизнь?
Есть какое-то логическое обоснование отключения переноса во умолчанию?
Есть какое-то логическое обоснование отключения переноса во умолчанию?

Как всегда: загнать всех пользователей на устройства без флешек.
Затягивание гаек. Возможно, ради безопасности и уменьшения количества ошибок непредвиденного поведения. Чтобы каждый разработчик сначала сам проверил перенос приложения, и только потом включал эту опцию для всех.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.