web-dev-qa-db-ja.com

複数のクライアント向けにAndroidプライベートアプリを公開する

私たちが扱っているもの

このアプリは、オフラインでクライアントに配布しています（つまり、Playストアにアップロードされていません）。各クライアントに配布されるアプリのフレーバーは、あちこちで少し調整するだけでほぼ同じです。すべてのクライアントは、このアプリを従業員と共有して使用します。基本的にこれはエンタープライズアプリです。

何が問題なのですか

最近、私たちのクライアントの1人が、Google PlayからダウンロードされていないアプリをブロックするMDM（モビリティデバイス管理）ツールの使用を開始しました。明らかに、クライアントからこのアプリをGooglePlayにアップロードできるかどうかを確認するようリクエストがありました。

ここで重要なのは、100を超えるクライアントがあり、各クライアントに提供されるアプリのパッケージ名は実際には同じであるということです。だから、あちこちで少し微調整した同じアプリです。アプリをPlayストアに公開する道を進むと、大混乱に陥る可能性があります（100個の異なるアプリをPlayストアにアップロードしたくない-つまり、クライアントごとに1つ）。複数のクライアントが同じアプリを使用できるように、私たちは私たちの側からいくつかの最適化を行っています（ただし、100以上のクライアントすべてに同じアプリを使用させることはできません）。

私は何を見ているのですか？

私はAndroid For Work（AFW）、Googleプライベートアプリ、マネージドGoogle Playを見て、まだ内容を消化し始めました。しかし、私には、企業が特定のデバイスに特定のプロファイルでのみダウンロードできるアプリを展開/公開するための安全な方法のように見えました（これにより、ユーザーが同じ電話を個人用に使用する場合に備えて、ユーザーの個人用アプリやデータから物事を分離しますおよび作業目的）。

私が探している解決策は何ですか？

  1. アプリを非公開でデプロイし（Googleでホストするか、非公開でホストしますが、どちらの場合もGoogle Playでリストされます）、クライアントがこのアプリを従業員と共有できるようにします。

  2. 各クライアントの各プライベートアプリは、独自の小さなプライベートアイランドに配置する必要があります。同じパッケージ名のアプリをすべてのクライアントに配布したい（これまで読んだことから、これはGoogle Playでは不可能かもしれません。しかし、何かが足りない場合は誰かが事実を指摘してくれることを願っています）。

androidgoogle-playandroid-for-work
18
Dibzmania

これが私の解決策です：

バックエンドからデータと構成を取得し、独自のクライアントIDを使用してビューとデータをレンダリングするランタイム動的アプリを作成します。

単一のアプリを作成してGooglePlayにアップロードできますが、すべてのアプリの動作を分離するclientIdでクライアントを管理する必要があります。このclientIdは一意であり、クライアントごとに生成されます。このソリューションには2つの側面があります。 Android側とサーバー側。

1-Android side：このアプリには、定数で次のようなbaseUrlが必要です。

baseUrl = "http://yourCorporation.com/{clienId}/api/"

そして、すべてのクライアントのすべてのサービスが同じURLを使用します。 clientIdが重要なポイントです。クライアントアプリの違いはclientIdです。 api-callのURLを生成するには、次のようにする必要があります。

Constant.ClientId = scannedQRCode;
url = baseUrl.replace("{client_id}",Contant.ClientId) + apiUrl ;

アプリの最初の実行でスキャンする必要があるクライアントごとにQRコードを作成する必要があります。登録後にQRコードを彼/彼女（クライアントのクライアント）の電子メールに送信することをお勧めします。このQRコードにはclientIdがあります。そのため、すべてのクライアントには独自のサービスがあり、実際には分離されたアイランドとして機能します。サーバーアドレスを変更する場合でも、すべてのbaseUrlをQRコードに入れることができますが、クライアントごとにサーバーを作成する必要があり、これは頭痛の種であるため、お勧めしません。 。

次のように、customConfigDtoをjsonとして返すconfig apiを呼び出すことで、アプリのconfig要素とUI要素を処理することもできます。

public class CustomConfigDto {

String colorPrimary ;
String colroPrimaryDark ;
String colorAccent ;
int tabCounts;

//and more...


public String getColorPrimary() {
    return colorPrimary;
}

public void setColorPrimary(String colorPrimary) {
    this.colorPrimary = colorPrimary;
}

public String getColroPrimaryDark() {
    return colroPrimaryDark;
}

public void setColroPrimaryDark(String colroPrimaryDark) {
    this.colroPrimaryDark = colroPrimaryDark;
}

public String getColorAccent() {
    return colorAccent;
}

public void setColorAccent(String colorAccent) {
    this.colorAccent = colorAccent;
}

public int getTabCounts() {
    return tabCounts;
}

public void setTabCounts(int tabCounts) {
    this.tabCounts = tabCounts;
}
}

そして、この構成でビューをレンダリングします。これらはすべて、アプリごとにclientIdで区切られて機能します。 QRコードは非常に手軽で上品で、あなたのケースに合うので、私はQRコードを好みますが、このclientIdは他の多くの方法で入力できます。 This は最高の無料でシンプルなQRコード生成サービスの1つであり、 this はAndroid向けの最高のQRコードスキャナーライブラリの1つです。

2-サーバー側：サーバー側でstep1を処理する必要があり、非常に簡単です。他のすべてのエンティティが持つエンティティ呼び出しClientを持つことができます。すべてのデータを1つの場所に保持する必要がありますが、クライアントによって分離する必要があるためです。 Springで次のようなAPIをマッピングすることもできます。

@RequestMapping(value = "http://yourCorporation.com/{clienId}/api/customers", method = RequestMethod.GET)
    Customers getCustomers(@PathVariable("clienId") Long clientId) {
        return customerService.findCustomerByClientId(clientId);
    }
8
Mahdi

あなたが言ったことに基づいて、これは、各クライアントに完全に別々のAPKを送信するよりも、構成管理でこれを解決できるように思えます。

Googleにはプライベートチャネルがありますが、ドキュメントに基づくと、高度にカスタマイズされたアクセス（つまり、特定の人がアクセスできる）ではなく、単一のメンバーシップリスト（つまり、アクセスが許可されると、プライベートチャネル全体にアクセスできる）を持つことをはるかに重視しているようです。チャネル内の特定のアイテムに）。

私が提案する代替案：すべてのクライアントに同じAPKをダウンロードさせる。それぞれに、アプリのクライアント固有の「アクティベーションコード」を提供します。アプリが初めて起動すると、Webサービスが呼び出され、アクティベーションコードが渡されます。サーバー側では、アクティベーションコードを使用してクライアントを識別し、正しい構成のデータをクライアントに返します。次に、同じAPKをプライベートチャネルの全員に配布し、インストールしたらリモートで構成できます。

このスキームの主な利点は、組織に複数の構成を設定できることです。クライアントにいくつかのアクティベーションコードの選択肢を与えるだけで、それぞれが特定の構成を提供します。たとえば、ドックワーカーと管理人の両方が使用するアプリがある場合（ここでは例を示しています）、ドックワーカーに1つのアクティベーションコードを、管理人に2番目のアクティベーションコードを与えると、簡単に与えることができます。それらは異なる構成です。

4
EJoshuaS - Reinstate Monica

良い、長い解決策：

異なるアプリに同じパッケージ名を使用しないでください。マルチモジュールプロジェクトを作成し、コア、共有のものに1つのモジュールを設定し、必要なものを微調整してパッケージ名を構成できるクライアントごとにモジュールを追加しますビルドタイプに基づいて動的に実行されます。これにより、CIサーバーとその他すべてに同じパッケージ名を使用し、アプリのリリース時に別のパッケージ名を使用できます。

うまくいくかもしれない短い回避策：

アプリをクローズドGooglePlayベータ版として公開し、このクライアントにのみ招待状を送信します。そうすれば、彼はPlayストアを通じて従業員にアプリを配布でき、他のクライアントは、あなたが直面しているMDMツールがわからなくても動作するかどうかはわかりませんが、ベータチャネルアプリは不明な発信​​元のアクセス許可を必要としないため、 、あなたは大丈夫なはずです。

3
Fco P.

同じパッケージ名が必要な場合は、EJoshuaSが提案したようなことを行う必要があります。つまり、1つのアプリバージョン内でさまざまな構成を管理します。同じパッケージで複数のアプリをGooglePlayにデプロイすることはできません。

さまざまなパッケージを用意している場合は、Androidマニフェストごとにパッケージ名を変更して、別のアプリとしてリリースするだけです。インポートするすべての場所でパッケージを変更する必要があります。 Rファイルであり、マニフェスト内のすべてのクラス参照にクラスパス全体が含まれていることを確認する必要があります（<activity Android:name="[full.package].MainActivity"> のではなく <activity Android:name=".MainActivity">）。これはかなり混乱し、構成管理の観点からはひどいので、一般的にはあまり優れたソリューションではありませんが、うまくいくかもしれません。

1
windedmoose

Android For Work（AFW）、Googleプライベートアプリ、マネージドGoogle Playを見て、それでも内容を消化し始めました。

これはおそらくAFWに適しています。

しかし、私には、特定のデバイスと特定のプロファイルでのみダウンロードできるアプリを企業が展開/公開するための安全な方法のように見えました。

それはMDMが行うことです、はい、しかしそれだけではありません。 Android for Work）を使用すると、 管理対象構成 もあり、アプリの構成を渡すことができます。これを使用して、バックエンドのURLなどを変更できます。

それは確かにあなたの2番目の要件をサポートしますが、私は最初の要件について確信が持てないほどほとんど知りません。 Google Play for Workでアプリを非公開でホストしてロールアウトすることはできますが、複数のクライアントに非公開で配布することについてはわかりません。

このGoogleAPIを使用することの明らかな利点は、自分で何も作成する必要がないことです。また、ほとんどのMDMはWorkAPIのAndroidをサポートしているため、ドメイン管理者はアプリをまとめて購入して従業員に配布できます。 AppConfig Community をご覧ください。 =これらのAPIとベストプラクティスを組み込んだMDMプロバイダーを示しています。

何を決めるにしても、あなたは間違いなくAndroid for Workをよく見る必要があります。あなたが説明しているのはまさにそれが意図していることだからです。初期設定は苦痛であり、wayすべてがどのように機能し、一緒に機能するかについての情報が少なすぎますが、それを理解するために数日を費やす方が、独自のマネージドソリューションを構築するよりも優れている可能性があります。維持する必要があります。

1
David Medenjak