Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

モバイルアプリ生成のトラブルシューティング

この記事では、モバイルアプリをネイティブプラットフォームに生成するときの問題のトラブルシューティングに役立つ情報を提供しています。

注記:

一般的な問題

このセクションでは、頻繁に発生するいくつかの問題について説明し、モバイル生成に関する問題のトラブルシューティングにおいて役立つ可能性のある情報を提供しています。具体的には次のような問題です。

iOS 13でQRコードを使用したインストール中のエラー

SafariでQRコードをスキャンしてアプリケーションをインストールするとき、OSがiOS 13の場合にエラーが発生します。

この問題を解決するには、Platform Serverをバージョン10.0.1016または11.0.539に更新します。

Platform Serverの更新を選択できない場合、1つの回避策として、Safariの[Disable Web SQL]機能をオフにする方法があります。

  1. Settings > Safari Options]に移動します。

  2. Advanced > Experimental Features]に移動します。

  3. 最後に、[Disable Web SQL]というオプションをオフにします。

iOS 13のiPadOSでIPAをインストールできない

新しいiPadOSを使用している場合、OutSystemsストアからIPAをインストールすることができません。iOS 13のiPadOSではSafariでのダウンロードの処理方法が変わり、デバイスにIPAをインストールするのではなくIPAのダウンロードのみを行うようになりました。これは、デバイスのSafariがデスクトップブラウザとして機能するようになったため、デスクトップブラウザで開いたときと同じ動作をするためです。詳細については、こちらのリンクをご覧ください。

この問題を解決するには、[Request Mobile Website]を実行して(以下の画像を参照)、以前のiPadOSと同じ動作にすることができます。

UIWebViewの警告

アプリをApple Storeにパブリッシュするとき、そのアプリがMABSバージョン6.0未満でビルドされたものである場合、以下の警告が表示されます。

Apple will stop accepting submissions of apps that use UIWebView APIs.

これが発生するのは、AppleがUIWebViewを非推奨にしているためです。ただし、警告が表示されても、そのままアプリをストアに提出することができます。

現在、MABS 6.0ではこの警告が修正されていませんが、今後のベータリリースで修正される予定です。新しいWKWebViewエンジン(最新のiOS WebViewエンジン)でアプリが生成され、UIWebViewへの参照がなくなります。

MABS 6.0に変更した後も警告が引き続き表示される場合は、UIWebViewへの参照が残っていることが、Appleでアプリの提出時にコード分析を行うことにより検出された可能性があります。。たとえば、Cordovaプラグインを使用している場合、UIWebViewへの参照が含まれている可能性があります。Cordovaではこの問題の修正作業を続けていますが、修正完了時期は未定です。詳細については、こちらのCordovaに関する記事をご覧ください。

無効なiOS証明書の使用

iOS証明書に問題があるためにモバイルアプリの生成がブロックされる場合があります。ログファイルを確認すると、以下のいずれかの状況が発生している可能性があります。

  • Service Studioで入力された証明書には、同様にService Studioで導入されたプロビジョニングプロファイルとの互換性がありません。
    こちらの記事の手順を実行することを推奨します。

  • 証明書がコード署名として有効ではありません。
    証明書が取り消されたり、期限切れになったりしていないかを確認します。

ターゲットのネイティブSDKのバージョンが正しくない

iOSとAndroidのいずれの場合も、モバイルアプリの生成に使用される各MABSバージョンは特定のネイティブSDKバージョンをターゲットにしています。このとき、プラグインはこれらのネイティブSDKの異なるバージョンに依存している可能性があります。

以下の例(モジュールの拡張構成)では、Cordovaの設定を使用してアプリのネイティブSDKを変更し、ターゲットをAndroid SDK 22にしています。

この場合、MABS 5.0を使用しており、そのMABSバージョンの仕様によると、Android SDKはバージョン28である必要があります。valueをバージョン28に変更する必要があります。

ネイティブSDKのバージョンを強制的に適用するCordovaの設定がありますが、プラグインを調整してMABSの仕様のターゲットSDKバージョンに合わせる方法が最適です。

プラグインのタグ付けしたバージョンを使用していない

プラグインのタグ付けしたバージョンを使用することが推奨されています。使用していない場合、常にマスターブランチディレクトリの最新バージョンを使用します。この場合は開発者がメインブランチの変更を絶えずプッシュしている可能性があるため、不安定なバージョンのコードを利用することになります。

たとえば、GitHubリポジトリでは、 <GitHubLink>#<TagVersion>を以下のモジュールの拡張構成の例で示されているように使用する必要があります。

プラグインのタグ付けしたバージョンの依存関係を使用していない

プラグインの依存関係がライブラリの特定のバージョンをターゲットにしていない場合、そのライブラリの最新バージョンが取得され、ネイティブの生成で不整合が発生します。

たとえば、Google Analyticsプラグインはplay-services-analyticsを使用しますが、任意のバージョンを使用することができます。これは、plugin.xmlファイルの以下のセクションでわかります。

「+」記号があると、アプリを生成するときに最新バージョンを使用することができますが、play-services-analyticsに大きな変更が加えられた場合、MABS要件やその他のプラグインとの互換性がなくなる可能性があります。

これらのエントリを有効なバージョンで維持することで、結果が予測可能になります。

これはほんの一例ですが、仕様で「+」を使用して(プラグインの依存関係を取得するという)同じ目的で使用されるエントリがこの他にもあります。これには、dependencyエントリ(同じplugin.xmlファイル内)やdependencyブロック(Gradleファイル内)などがあります。

同じメタデータタグを複数定義している

メタデータタグが異なる値で複数定義される場合があります。プラグインでこれがよく発生するのは、AndroidManifest.xmlファイルを作成または変更して、同じキーのメタデータタグの値を再定義したり上書きしたりするときです。

たとえば、以下のログファイルは、独自のライブラリによって文字列リソースとしてすでに定義されているSOME_APP_KEYメタデータタグの値をプラグインが上書きすることによって衝突が発生していることを示しています。

* What went wrong: > Manifest merger failed : Attribute meta-data#SOME_APP_KEY@value value=(1234567890) from AndroidManifest.xml:18:54-130 is also present at [com.some.some:library:1.2.3] AndroidManifest.xml:22:13-47 value=(@string/some_app_key). Suggestion: add 'tools:replace="android:value"' to <meta-data> element at AndroidManifest.xml:18:9-133 to override.

この場合の解決策は、プラグインの実装を確認して、メタデータタグの値の上書きを修正することです。

AndroidXサポートライブラリとの衝突

AndroidXサポートライブラリを使用するプラグイン(またはプラグインの依存関係)を含むアプリを作成する場合、サポートライブラリにMABSバージョンとの互換性がないことがあります。

このタイプの問題では、ログファイルには、以下のような内容が含まれます。

* What went wrong: Execution failed for task ':app:processReleaseManifest'. > Manifest merger failed : Attribute application@appComponentFactory value=(android.support.v4.app.CoreComponentFactory) from [com.android.support:support-compat:28.0.0] AndroidManifest.xml:22:18-91 is also present at [androidx.core:core:1.0.0] AndroidManifest.xml:22:18-86 value=(androidx.core.app.CoreComponentFactory). Suggestion: add 'tools:replace="android:appComponentFactory"' to <application> element at AndroidManifest.xml:5:5-20:19 to override.

この問題を修正するには、プラグインの実装を確認して、Android Xを使用する可能性のあるGradleの依存関係を探します。

以下の例のようにバージョンがロックされていないGoogleへの依存関係によってこのような状況が発生する場合もあります。

implementation "com.google.android.gms:play-services-maps:+"`

この場合は最新バージョンが使用され、そのバージョンがAndroid Xである可能性があります。このような問題を修正するには、Android Xへの依存元のプラグインを特定し、それらのバージョンをロックして、Android X以外のバージョンを使用するようにします。

Android Xが動作する必要があるプラグインのバージョンを使用している場合は、Android Xを使用しないバージョンへのプラグインのアップグレードまたはダウングレードを検討します。

Androidサポートライブラリ間に互換性がない

異なるバージョンをターゲットとするAndroidサポートライブラリの依存関係を使用するアプリを作成すると、モバイル生成に関する問題が発生する場合があります。

以下のログメッセージの例は、バージョンが異なる複数のサポートライブラリが使用されており、それらによって異なるandroid.support.VERSIONメタデータタグの値が定義される場合のものです。

* What went wrong: > Manifest merger failed : Attribute meta-data#android.support.VERSION@value value=(25.4.0) from [com.android.support:exifinterface:25.4.0] AndroidManifest.xml:25:13-35 is also present at [com.android.support:support-v4:26.1.0] AndroidManifest.xml:28:13-35 value=(26.1.0). Suggestion: add 'tools:replace="android:value"' to <meta-data> element at AndroidManifest.xml:23:9-25:38 to override.

この問題を解決するには、互換性がない原因となっている可能性のあるプラグインをアップグレード(またはダウングレード)します。または、MABSのバージョンを変更し、MABSのビルトインプラグインが使用するAndroidサポートライブラリとの互換性が確保されるようにします。

問題が続く場合は、プラグインの実装を変更し、問題のある依存関係のバージョンの互換性が確保されるようにします。

Googleサービス構成ファイルに関する問題

Googleサービスを使用するアプリは、特定のJSON(Androidの場合)構成ファイルまたはPlist(iOSの場合)構成ファイルを正しいディレクトリ内に配置して適切に構成する必要があります。Googleサービスを使用するプラグインでは、Service Studioのリソースとして追加された構成ファイルが必要です。

たとえば、Googleサービスプラグインを使用しているときにgoogle-services.jsonファイルが正しいディレクトリ内にない場合、ログメッセージは以下のようになります。

Execution failed for task ':app:processDebugGoogleServices'. > File google-services.json is missing. The Google Services Plugin cannot function without it.

別の例として、google-services.jsonは正しいディレクトリ内にあるものの、その中にあるJSONのパッケージ名がアプリケーションのパッケージ名と一致していない場合、ログメッセージは以下のようになります。

Execution failed for task ':app:processDebugGoogleServices'. > No matching client found for package name 'com.some.some'

この問題を解決するには、以下の手順を実行します。

  • プラグインのドキュメントを参照し、プラグインが適切に構成されていることを確認します。
  • JSONファイルまたはPlistファイルに正しい情報が含まれていることを確認します。

問題が続く場合:

Forgeのサポート対象プラグインであるPushWooshの場合に限り、Android用のJSON構成ファイルを含むZIPファイルが必要です。詳細については、プラグインのドキュメントをご覧ください。

サポート対象プラグインであるPushWooshの場合に限り、Android用のJSON構成ファイルを含むZIPファイルが必要です。詳細については、プラグインのドキュメントをご覧ください。

Google Playサービスのバージョンに互換性がない

Google Playサービスの依存関係を複数使用するアプリを作成する場合、それらのバージョンが衝突し合い、アプリの生成時に問題が発生する場合があります。

この例のログファイルには、Google Playサービスライブラリの依存関係を2つ以上使用するプラグインを含むアプリを生成するときに、これらの依存関係に互換性がない場合のエラーメッセージが含まれます。

Failed to capture fingerprint of input files for task ':app:preDebugBuild' property 'compileManifests' during up-to-date check. > In project 'app' a resolved Google Play services library dependency depends on another at an exact version (e.g. "[11.0. 0]", but isn't being resolved to that version. Behavior exhibited by the library will be unknown.

この問題を解決するには、プラグインを更新し、互換性のあるGoogle Playサービスライブラリバージョンを使用するバージョンにします。

さらに問題が続く場合は、プラグインを変更し、互換性のある依存関係のバージョンを強制的に適用します。

トラブルシューティングの手法

このセクションでは、モバイル生成に関する問題のトラブルシューティングにおいて役立つ手法をいくつか説明しています。

ログを確認する

トラブルシューティングの手法の1つとして、ログファイルで問題を探します。

1.ログファイルを取得する

OutSystems logs the generation steps of a mobile app package, including the stack trace with additional details in case of error.

To get this mobile app package generation log, do the following:

  1. If you are in Service Studio, go to the details page of the mobile app and click Application Management... to open the mobile app's page in Service Center console. The page opens in a separate browser.

    Otherwise, open the Service Center console of the environment (https://<your_server>/ServiceCenter), go to Factory » Applications, and click the mobile app name to go to the app details page.

  2. Go to the Native Platforms tab. You will see the information about the latest mobile app package generation for each mobile platform.

  3. Click the Log File icon to save the file.

If you are getting this log by request of OutSystems Support, fetch the file you saved from the local download folder and attach it to your support case.

2.ログファイルで問題を探す

ログファイルを開き、エラーがある行を探します。検索を絞り込むため、エラーが発生した時刻に近いタイムスタンプの行を探します。

2つのトラブルシューティングの例を以下に示します。

ログによるトラブルシューティングの例

例1

モバイルアプリの生成中に「Error fetching Cordova plugin」エラーが発生しました。

ログを確認したところ、以下の詳細メッセージがありました。

これは、プラグインで定義されている1.5.0タグがGitHubに存在しないことを示しています。

プラグインの実装を確認して適切なタグを使用する必要があります。

例2

前の例と同様に、「Error fetching Cordova plugin」エラーが発生しました。

ログを確認したところ、以下の詳細メッセージがありました。

この場合のログは、PushWooshプラグインの構成のアーカイブがないことを示しています。プラグインに関する指示で、「google-services」アーカイブを含める必要があることが示されており、これは失敗したCordovaフックの名前に関連しています。

プラグインを確認する

モバイルアプリでプラグインを使用する場合、プラグインが問題の原因になる場合があります。このセクションでは、プラグインに関連する可能性のある問題のトラブルシューティングの方法に関するガイドラインを提供しています。

プラグインとMABSの適合を確認する

プラグインを使用する場合、プラグインの実装がMABSのバージョン要件に適合していることを確認しします。適合していない場合、それが問題の原因になる可能性があります。

たとえば、plugin.xmlファイルに以下の画像のようなエンジンエントリが含まれている場合、これらにCordova CLIまたはAndroid/iOSエンジンと互換性があることを確認します。

問題の原因になっているプラグインを特定する

プラグインを含むアプリをトラブルシューティングする場合、まず、問題の根本的な原因になっているプラグインを特定します。1つのプラグインに注目すると、分析が容易になります。

このセクションでは、問題の原因になっているプラグインを特定するための手法をいくつか説明します。

クリーンなOutSystemsアプリで再現する

これはプラグインに関する問題の再現を試みるときのローコードによる手法です。通常、問題の原因となっているプラグインに関して有力なヒントがあるときにこれを使用します。

以下の手順を実行し、クリーンなアプリを作成してプラグインを追加します。

  1. Service Studioで新しいモバイルアプリを作成します。

  2. そのアプリにプラグインを追加し、モバイルアプリを生成します。

  3. 問題が再現された場合は中止し、ログを使用して問題をトラブルシューティングします。

  4. 別のプラグインを追加し、手順2以降を繰り返します。

クリーンなCordovaプロジェクトで再現する

この方法では、Cordovaプロジェクトでの作業と若干の設定作業に関する知識が必要になります。しかし、主にこの方法ではモバイルアプリをすばやく生成できるため、複数のプラグインを使用している場合や問題の原因に関するヒントがない場合に、前の方法よりも適切に解明することができます。

以下の手順を実行し、Cordovaプロジェクトを作成してプラグインを追加します。

  1. MABSのバージョン要件で示されたCordova CLIバージョンのCordovaの手順に従って、Cordova環境を設定します。
    注記: iOSの場合は、macOS環境を使用する必要があります。

  2. Cordovaプロジェクトを作成します。

    cordova create <app_name>
  3. Cordovaプロジェクトフォルダに移動してコマンドを実行します。

    cd <app_name>
  4. プラットフォームを追加します。

    cordova platform add <platform>@<engine version>

    このとき、以下のようになります。
    <platform>: 「android」または「ios」。
    <engine version>: MABSバージョンで要求されるエンジンのバージョン。

  5. プラグインを追加してプロジェクトを作成します。

    cordova plugin add <plugin_repo_url> cordova build <platform>
  6. 問題が再現された場合は中止し、ログを使用して問題のトラブルシューティングを行います。

  7. 問題が再現されなかった場合は、手順5以降を繰り返します。

この方法では、MABSバージョンのCordova Android/iOSエンジンに対してプラグインをテストすることができます。しかし、OutSystemsにより生成されたモバイルアプリには、OutSystemsが内部で使用するビルトインプラグインを持つネイティブシェルがあります。この場合はそれらがインストールされていないため、プラグインとビルトインプラグインに互換性がないことを検出できません。

プラグインを1つずつ削除して生成する

問題の原因になっているプラグインを特定する別のローコードによる手法は、プラグインを1つずつ削除し、削除するたびにアプリを生成することです。問題が解消されたとき、そのプラグインが問題の原因であったことがわかります。

まだ問題がある場合

このドキュメントに問題のトラブルシューティングに役立つ手法がなかった場合は、サポートケースを開いてOutSystems Supportのサポートを受けることを検討してください。

  • Was this article helpful?