Можно ли поставить Java-приложение из Google Play Market на Windows?

Нет, к сожалению, так работать не будет. Приложения изначально написаны под Android. Мало того, что интерфейс не адаптивен по OS Windows, так еще они просто не запустятся. Если вам уж очень нужно, то можно запустить через эмулятор (Bluestacks, Nox...).

Да, импортирование возможно, как и компиляция, за счёт java-машины. Но, сама-то программа написана под Android. Если вы уверены в своей правоте, в чём смысл вопроса, если вы сейчас мне на него ответили?

Update: Ответ StateItPrimitive дает значительно более глубокое с технической точки зрение понимание различий между Java и Android приложениями.

Нет, поставить Java-приложение из Google Play Market на Windows нельзя.

Автор вопроса совершенно правильно указал, что Java-приложения 100% переносимы между устройствами, однако приложения под Android из Play Market'а Java-приложениями считаться (в общем случае) не могут.

Для корректной работы Android приложения помимо виртуальной машины Java необходимо так же специфическое окружение операционной системы, фалы стандартных ресурсов и многое другое.

Это достаточно просто понять, если взглянуть на исходный код Java-приложения и Android-приложения. В Android-приложении Вы не найдете функцию main(), запускающую, собственно, приложение. Android-приложения запускаются не пользователем, а операционной системой, которая полностью контролирует жизненный цикл программы. Вне ОС Android написанные под нее приложения запустить не получится.

Однако, хотя автор вопроса имел ввиду не совсем это, если Вы хотите установить приложение на Windows с целью тестирования (или игр), то можно попросту использовать эмулятор.

P.s. Некая аналогия. Можно сказать, что приложения Play Market'е - это куски приложений. Чтобы такой кусок стал полноценным Java приложением, его необходимо дополнить определенным Java-кодом и ресурсами. Эта часть хранится в ОС Android (причем своя для разных версий и производителей устройства).

P.P.s Нашел объяснение, где слова подобраны лучше javarush. Цитата оттуда

Как я уже упоминал, в операционной системе Android для разработки приложений используется Java. Вы можете написать код приложения для Android с помощью предоставляемого Google API Java, который затем будет скомпилирован в файлы классов. На этом схожесть заканчивается. Android не использует виртуальную машину Java (JVM) для выполнения файлов классов, вместо этого, в нём используется виртуальная машина Dalvik, не являющаяся истинной JVM и не работающая с Java-байткодом. Для выполнения на виртуальных машинах Dalvik, файлы классов компилируются в формат DEX (Dalvik EXecutable – исполняемые файлы Dalvik). После преобразования в формат DEX, файлы классов вместе с другими ресурсами объединяются в пакеты Android (APK) для распространения и инсталляции на различных устройствах.

Статья уже сильно устарела, но главную мысль вполне передает.

Дисклеймер:

Я не являюсь экспертом в разработке Android, т.к. практически все время уделяю web-приложениям, тем не менее, тема оказалась для меня весьма интересной, поэтому попробую её раскрыть подробно (настолько, насколько это было бы интересно лично мне).

Java как язык программирования:

Java является языком программирования, т.е. описанием некоторого контракта (описания и связанного с ним поведения (например, недопустимость недопустимость undefined behavior)), который можно реализовать различными способами.

Например, никто не запрещает написать свою собственную среду исполнения поверх языка Java, т.е. среду исполнения, которая была бы Java-like, которая в качестве исходного кода использовала бы возможности (features) из языка Java какой-то определенной версии. В таком случае, перед вами бы встала непростая задача: поддержка совместимости со всевозможными (хотя бы самыми популярными) архитектурами процессоров и API операционных систем.

Причем, в частном случае, ваша собственная реализация даже не обязана быть JVM-like: она не обязана компилироваться в bytecode (см. ниже), вместо этого выполнять компиляцию исходного кода сразу в машинный код (native machine code), т.е. использовать более традиционный подход, который используется во многих других языках (таких как Go, C, C++, Swift, ...).

Для того, чтобы осознать все особенности и сложности (из-за которых системы реализованы несколько по-разному) нужно разобраться в принципах работы приложений на Android и вне его:

Классическая реализация JVM-like:

Жизненный цикл типичного классического (не Android) Java-приложения можно описать следующим образом:

source code -(compiler)-> bytecode -(JVM)-> native machine code.

Конкретизируем на определенном примере:

.java -(javac)-> .class -(HotSpot)-> native machine code:

• java в качестве исходного кода;
• javac в качестве компилятора исходного кода, написанного на Java, в bytecode;
• HotSpot (от Oracle) в качестве JVM, т.е. среды исполнения/интерпретации bytecode команд в команды машинного кода для конкретного CPU, т.е. определенного процессора, ядра которого исполняют машинный код (native machine code) вашего приложения;
• machine code - набор инструкций для определенной архитектуры процессоров и API операционной системы.

Разберем детальней:

1. source code (исходный код) - код вашей программы на JVM-based языке программирования:

   1. .java-файл - код на Java;
   2. .kt-файл - код на Kotlin;
   3. .clj-файл - код на Clojure;
   4. .scala-файл - код на Scala;
   5. .groovy-файл - код на Groovy;
   6. и так далее...

2. compiler - компилятор исходного кода в bytecode (выбор компилятора однозначно зависит от языка программирования, использованному в исходном коде):

   1. Java - javac CLI tool;
   2. Kotlin - kotlinc CLI tool;
   3. Clojure - leiningen CLI tool или посредством стандартных средств компиляции;
   4. Scala - scalac CLI tool;
   5. Groovy - groovyc CLI tool;
   6. и так далее...

3. bytecode - набор инструкций, исполняемых JVM:

   • существует всего 256 инструкций (см. Chapter 7), из которых в текущий момент реально используется лишь около 200;
   • .class-файл - набор инструкций, являющийся результатом компиляции исходного кода в bytecode;
     • если рассматривать на примере Java-кода, то каждый Java-класс попадает в отдельный .class-файл, вне зависимости от того, являлся ли он Top Level Class или нет;

4. native machine code (машинный код) - набор инструкций (для определенной архитектуры процессоров и API ОС), исполняемый процессором:

   • результат интерпретации bytecode в инструкции конкретной архитектуры процессоров;

     • в общем случае, в рамках одной JVM требуется вести поддержку команд всех используемых для исполнения кода CPU.

Реализации JVM:

Вы уже могли догадаться, что реализаций JVM множество, и каждая из них самостоятельно отвечает за трансляцию стандартного для всех bytecode в специфичный для каждой архитектуры процессоров native machine code.

Для наглядности приведу вам примерный список наиболее популярных реализаций JVM:

1. HotSpot VM (от Oracle);
2. OpenJVM;
3. MSJVM / Microsoft VM;
4. IBM JVM;
5. JRockit;
6. Dalvik (от Android, Inc.):
   • позднее, Android, Inc. (вместе с их ранней версией продукта Android) была куплена Google;
7. Android Runtime, он же, ART (от Google):
   • разработка от Google, которая создана на замену доставшегося при покупке Android Dalvik VM (Dalvik была заменена на ART начиная с Android 5.0 "Lollipop");
8. ...

В рамках каждой из этих реализаций спецификаций JVM самостоятельно решаются следующие вопросы:

1. поддержка API различных операционных систем:
   • предоставляются отдельные дистрибутивы для каждой из поддерживаемых ОС (это можно увидеть на примере JVM от Oracle);
2. поддержка команд различных архитектур процессоров (CISC, RISC, MISC):
   • в рамках каждой из архитектур процессоров поддержка команд различных линеек процессоров.

Packaging (упаковка) классических JVM-like приложений:

С точки зрения упаковки (packaging) классических JVM-like приложений существует несколько вариантов:

• JAR:
  • не исполняемый (использоваться в качестве подключаемой библиотеки);
  • исполняемый;
    • имеет класс, содержащий метод public static void main(String[] args), указание на который описано в META-INF/MANIFEST.MF;
    • с появлением SpringBoot, MicroProfile.IO и подобных им решений исполняемые JAR вытесняют остальные варианты packaging'а (за исключением не исполняемых JAR-библиотек, конечно же);
  • EJB JAR - является стандартом архивации EJB модулей (в виде JAR файлов) в рамках Jakarta EE (бывшего Java EE):
    • описание EJB модуля добавляется в META-INF/ejb-jar.xml, либо посредством аннотаций (посредством Java SPI (Service Provider Interfaces), в частности, Java Annotation Processing API);
• WAR (Web application ARchive):
  • является стандартом архивации веб модулей в рамках Jakarta EE (бывшего Java EE);
  • является модулем, загружаемым в Web Container в рамках Application Server'а (сервера приложений);
  • может содержать несколько EJB JAR;
  • описание веб модуля добавляется в WEB-INF/web.xml, либо посредством аннотаций (посредством Java SPI (Service Provider Interfaces), в частности, Java Annotation Processing API);
• EAR (Enterprise application ARchive):
  • является стандартом архивации enterprise приложений в рамках Jakarta EE (бывшего Java EE);
  • состоит из нескольких WAR.

Подробнее см. здесь и здесь.

Android реализация JVM-like:

При разработке приложений под Android ребята из Android, Inc. (создатели Android, позднее купленные Google) предпочли использовать уже довольно популярный язык программирования Java, реализовав его возможности (features) из определенной версии (например, java 6) и периодически обновляя их, тем или иным образом (например, до java 8). Подробнее смотрите здесь, здесь и здесь.

Таким образом, они не стали изобретать язык программирования с нуля (как это сделал Apple в случае языка Swift), но зато они сильно изменили среду его исполнения.

Теперь жизненный цикл кода стал несколько варьироваться в зависимости от конкретной реализации. Рассмотрим пример с использованием стандартных инструментов сборки:

source code -(classic JVM compiler)-> bytecode -(dexer)-> dex -(Android JVM)-> machine code.

Конкретизируем на определенном примере: java -(javac)-> .class -(dexer)-> classes.dex -(Dalvik / ART)-> machine code:

• java в качестве исходного кода;
• javac в качестве классического компилятора исходного кода в классический JVM bytecode;
• .class - файлы, хранящие в себе команды классического формата JVM bytecode;
• dexer в качестве утилиты для конвертации классического JVM bytecode в проприетарный формат bytecode - dex (Dalvik executable);
• classes.dex (Dalvik executable) - файл (обычно один), хранящий в себе команды проприетарного формата bytecode для JVM Dalvik и ART;
• Android Runtime (ART) и Dalvik (от Google) в качестве JVM, т.е. среды исполнения/интерпретации команд dex (проприетарного bytecode) в machine code (подробнее см. здесь):
  • Dalvik использует парадигму JIT (Just-In-Time), т.е. компиляцию в машинный код во время исполнения программы;
    • Dalvik был заменен на Android Runtime начиная с Android 5.0 "Lollipop";
  • Android Runtime (ART) использует парадигму AOT (Ahead-Of-Time), т.е. компиляцию в машинный код перед исполнением программы (в случае Andoid - во время установки .apk из play market):
    • Android Runtime использует файлы dex (Dalvik executable), поэтому является обратно совместимым с Dalvik на уровне проприетарного bytecode приложений в рамках Android;
• machine code - набор инструкций для определенной архитектуры процессоров.

Примечание: стоит понимать, что, например, при использовании инструментария Jack tools процесс сборки выглядел бы несколько иначе: .java -> .jack -> .dex, но в рамках данного ответа, пожалуй, не будем отклоняться от рассмотрения стандартных средств, поэтому опустим его использование.

Жизненный цикл приложения в Android:

С точки зрения упаковки (packaging) и установки (installing) приложения перед исполнением в Android JVM имеются ряд отличий от классического JVM-like варианта. Процесс можно описать следующим образом:

1. сборка исходников:

   • .java -(javac)-> .class -(dexer)-> classes.dex;

2. сборка apk (Android package):

   • classes.dex + resources files -(aapt)-> .apk;

3. подпись apk:

   • .apk -(jarsigner + zipalign)-> signed .apk;

4. установка apk:

   1. Dalvik:

      • classes.dex -(dexopt)-> odex (optimized dex) или же quickened dex:
      • оптимизированный вариант файла dex: оптимизирует коды операций, подстановка адреса/индекса вызываемого метода из таблицы vtable и так далее;

   2. Android Runtime (ART):

      • classes.dex -(dex2oat)-> OAT version of classes.dex (dex + native machine code), т.е. выполняется конвертация проприетарного формата bytecode в машинный код, специфичный для процессора (CPU), который установлен на device, на который производится установка. Результат кладется в ELF (Executable and Linkable Format) shared object;

5. запуск приложения:

   1. при нажатии на приложение служебный процесс (ActivityManagerService) записывает команду старта приложения в socket входящих команд.
   2. linux процесс Zygote, в рамках которого загружена Android JVM (Dalvik / ART), прослушивает этот socket и выполняет fork() своего процесса при поступлении команды на старт приложения;
      • в рамках процесса Zygote предварительно загружены базовые Android библиотеки из соображений оптимизации, поэтому дочерний процесс получит предварительно разогретую виртуальную машину:
      • создание процесса с нуля, загрузка в него всех необходимых библиотек и прогрев JVM занял бы куда больше времени;
      • иными словами, каждое приложение в рамках Android запускается в собственном экземпляре JVM и в рамках дочернего процесса относительно Zygote (название процесса, как бы, намекает);
      • Android работает поверх облегченной ОС Linux, поэтому процесс Zygote стартует за счет скриптов инициализации ОС (init.rc, подробнее см. здесь);
   3. загрузка в дочерний forked процесс ELF shared object (см. пункт выше) соответствующего запускаемого Android приложения.

Подробнее см. здесь, здесь и здесь.

Заключение:

Я очень надеюсь, что изучив принцип работы классических JVM совместимых и Android приложений вы уже сами пришли примерно к следующему выводу (весь ответ вел к тому, чтобы вы осознали это самостоятельно):

• создание приложений на основании концепций с использованием некоторого абстрактного/промежуточного кода (bytecode), само по себе, дает вам лишь возможность заложиться на будущее для реализации интерпретации этого bytecode под соответствующую архитектуру CPU и API ОС;
• .apk файлы Android содержат уже совсем не классический JVM bytecode, который умеют интерпретировать стандартные JVM (по типу HotSpot), а некоторый проприетарный для Android специфичных JVM (Dalvik и ART) - classes.dex;
• точка входа в программу:
  • классические исполняемые JVM приложения (JAR'ники) имеют явную точку входа:
    • создается класс, содержащий метод public static void main(String[] args), указание на который должно быть описано в META-INF/MANIFEST.MF;
  • приложения под Android не имеют явной точки входа:
    • они описывают собственный файл AndroidManifest.xml, за счет которого "подписываются" на определенные события (например, на onCreate в Activity), т.е. система является event driven;
• теоретически, исходный код вашей программы можно попробовать написать таким образом, что вы на основании его соберете, как исполняемый jar-файл (см. выше), так и Andorid .apk (см. выше), но это будут два независимых друг от друга файла, имеющих различное содержимое:
  • например, посредством подготовки конфигурации для двух разных сборок в рамках одного проекта (общие, переиспользуемые файлы исходного кода и ресурсов не разделять, конечно же):
    1. разграничить файлов ресурсов для Android и Classic JVM;
    2. разграничить некоторые исходные файлы:
    3. файл с точкой входа для classic JVM и конфигурацией для него в META-INF/MANIFEST.MF;
    4. файлы с подпиской на события (events) от ядра Android и конфигурацией для них в AndroidManifest.xml;
    5. создать два разных профиля в системе сборки (например, в maven или gradle), каждый из которых при сборке будет использовать не только общие ресурсы, но и специально выделенные для него (см. пункты выше);
• теоретически, вы можете запустить ваше Andorid приложение на иной ОС, если вы полностью имитируете окружение системы Andorid, т.е. если вы будете самостоятельно реализовывать event driven движок, имитирующий поведение ОС Android, а также обрабатывать соответствующие команды от Andorid приложения, использующие Android API, т.е. транслировать команды Andorid API на API ОС, в рамках которой запущено приложение (Linux, MacOS, Windows), либо посредством использования средств виртуализации системы:
  • также остается ряд вопросов касательно поддержки VM Dalvik и Android Runtime трансляции bytecode команд в команды машинного кода (native machine code) не только ряда линеек мобильных процессоров (Qualcomm Snapdragon, Huawei Kirin, Samsung Exynos, т.е. процессоров, базирующиеся на архитектуре ARM, т.е. RISC), но и десктопных (Intel, AMD, т.е. процессоров, базирующихся на архитектуре x86 и x64, т.е. CISC):
    • данные различия в используемых архитектурах процессоров возникают из-за различий, которые были заложены на этапе проектирования решений:
    • Classic JVM базируется на концепции stack machines (stack-based architecture);
    • Android JVM базируется на концепции register machine (register-based architecture);
      • о разнице между stack и register machines можно почитать здесь и здесь;
    • пожалуй, данную проблему проще всего решить посредством применения средств виртуализации;
    • подробнее касательно различий в архитектурах процессоров можно почитать здесь;
  • как вы понимаете, это довольно трудоемкая задача, в результате решения которой, окажется, что вы написали свой собственный эмулятор для Andorid на вашу ОС.

Краткое описание сравнения Java и Android API можно найти здесь.