回答:
一般的な要因であるARMチップセットの領域では、Linuxベースのほぼ同一のカーネルからのAndroidスタック全体が、実際には32ビットであり、通常は32ビット/ 64ビットホスト環境、ホスト環境のいずれかからクロスコンパイルされます通常、Linuxのディストリビューションの1つです。Androidのビルドおよびクロスコンパイル用に推奨されているGoogleの配布はUbuntuです。
Androidランタイムライブラリ（メディア、グラフィックス、ファイルシステムなど）も32ビットですが、dalvikvmのレイヤーに到達すると、この時点でビット数は無関係になり、apksが来ますGoogle Playストアからは、ネイティブバイトコード（ポータブルバイトコードにコンパイルされた生成されたJavaコードの「副産物」）がDalvikVM（仮想マシン）をターゲットにしています。
Froyoは、ARMチップセットを対象にクロスコンパイルされた32ビットホスト環境でのコンパイルを可能にした最後のAndroidです。
Gingerbreadは、3年前の当時の「未来の」Androidの最初のものであり、それが構築された64ビットホスト環境を使用する要件を導入しました。32ビットのホスト環境でGingerbreadを構築するには、多くのハックがありました。
ICSおよびJB以降では、コンパイルを高速化し、ビルドの所要時間を短縮するために、64ビット環境が確実に必要になりました。
要約すると、Playストアで表示される内容は、32ビットと64ビットのどちらが使用されているか、つまり無関係であるかどうかには関係ありません。
サイドノート：典型的な16GB RAM / Quadコア/ 64ビットLinuxディストリビューション、ICSをゼロから構築するのにかかる時間、最大で30分かかります。これが32ビットLinuxディストリビューションだった場合、実際には時間がかかり、CPUのメルトダウンを引き起こす可能性があります単純に、クロスコンパイルされたコードをチャーンアウトおよびクランクアウトするのに十分な処理能力がないため、非常に要求が多く、負担のかかるプロセスです！
/system/binまたはにある任意のネイティブARMバイナリを取得します。/system/xbinたとえば/system/bin/dalvikvm、これは、JavaおよびAPKの上位層を担当するDalvik VMバイナリです。
ここで、次のコマンドを発行してバイナリを調べfile dalvikvmます。ファイルの種類の概要が表示され、予想される出力は次のようになります。
dalvikvm：ELF 32ビットLSB実行可能ファイル、ARM、バージョン1（SYSV）、動的リンク（共有ライブラリを使用）、削除
32ビットELFへの参照に注意してください。これはARMにクロスコンパイルされており、バイナリ実行可能ファイルです。
さて、/system/lib次に、/system/lib/libandroid_runtime.soで見つかったネイティブの共有ライブラリを調べてみましょう。たとえば、今号を発行するfile libandroid_runtime.soと、予想される出力は次のようになります。
libandroid_runtime.so：ELF 32ビットLSB共有オブジェクト、ARM、バージョン1（SYSV）、動的リンク、削除
繰り返しますが、ARMにクロスコンパイルされた共有ライブラリである32ビットELFに注目してください。
ホストのクロスコンパイルはAOSPのソースで見つけることができるの鍵となるのは、すなわち、ジンジャーブレッドのビルドは、もともと64ビットのホストシステム上に構築する必要性があったが、ここではニュースグループだLinkyはを参照することがで構築するために取得するためのスクリプトにパッチを適用する方法は、 AOSPのGerritレビューのためのbuild/core.mk、およびbuild/main.mk（結合された）2つのパッチを備えた32ビットホスト。
その後の結果として、このパッチはICSのビルドスクリプトに到達しました。そこでは、ビルドに3日かかった32ビットプラットフォームでICSをコンパイルする特権がありました（Zte BladeのICSの移植でした）。これで、要件が強化されました。ICSからAOSPをビルドするクロスコンパイルを有効にするには、64ビットホストが必ず必要です。
もともと、Androidは32ビットプロセッサのみ、具体的には32ビットARMプロセッサ向けに記述されていました。後に、IntelとMIPSは、Androidがそれらのアーキテクチャをサポートするようにするために多大な投資をしました。ほとんどのアプリはバイナリとして出荷されていないため、彼らは（多くの）互換性の問題なくこれを行うことができました。Javaで書かれており、代わりにバイトコードとして出荷されます。これは、携帯電話の仮想マシンがアプリの実行時に携帯電話のアーキテクチャにコンパイルします。一部のアプリにはネイティブバイナリとして出荷されるコンポーネント。これは、特定の種類のアプリ（特にゲーム）を高速化するため、またはJavaで利用できないCライブラリにアプリをアクセスさせるために行われます。これらのアプリには、異なるアーキテクチャで実行できるように、ネイティブコード部分に複数のバイナリを含めることができます。それでも、アプリの大部分はJava専用であるため、どのアーキテクチャでも動作します。
この質問（および他のほとんどの回答）が書かれた時点では、上記はすべて真実でしたが、現在はそうではありません。Lollipopは、新しい64ビットARMプロセッサのサポートを導入しました（ARMv8）およびIntelおよびAMDのx86_64プロセッサの場合、つまりAndroidが32ビットと64ビットの両方のプロセッサをサポートするようになりました。Nexus 9は、最初の主要な64ビットAndroidデバイスでした。64ビットのサポートは、新しい命令セット拡張機能へのアクセスを提供するだけでなく、アプリが4 GBを超えるRAMを使用できることを意味します。ほとんどのアプリはそれほど必要ではありませんが、ハイエンドのゲームや写真/ビデオ作成ソフトウェアは確かにそれを利用できます：Androidをコンソール品質のゲーム（VRゲームを含む）およびコンテンツの作成のためのプラットフォームに押し上げます。これを利用するためにJavaアプリを更新する必要はありません。これは、仮想マシンが常にそれらを携帯電話のアーキテクチャにコンパイルするためですが、ネイティブコードのアプリはコンパイルするためです。
ARMv8は32ビットコードと下位互換性があるため（x86_64がx86コードを実行できるのと同じ方法）、32ビットプロセッサのネイティブコードを含むアプリでも64ビットAndroidで実行できます。だから、アプリは、それがネイティブコードが含まれている場合は、64ビット用にコンパイルする必要がありますし、それが高いRAMの上限またはアーキテクチャの新機能を利用したいと考えています。
すべてのARMチップは現在32ビットです。このため、Androidは現在32ビット環境ですべてのコードを実行します。
2014年に発売予定の 64ビットプロセッサ。
Androidは32ビットまたは64ビットのOSですか？32ビットと64ビットの両方のバイナリをGoogle Playで強制的にホストするため、両方ではなく、いずれかであると想定します。
どちらでもない。AndroidはDalvik VMベースのOSであり、Google PlayはDalvikアプリケーションをホストしています。Dalvik VM自体は、Java VMと同様に、物理マシンのビット数に関係なく常に32ビットです。
ご想像のとおり、ネイティブバイナリとともに出荷されるアプリケーションとNDKアプリケーションは、実行対象のすべてのアーキテクチャ用にコンパイルされたバイナリとともに出荷する必要があります。Androidが実行される最も一般的なアーキテクチャは、ARM 32ビットです。ただし、x86およびMIPSで実行されるデバイスもあります。