誰かがそれが何を意味するのか教えてもらえますか?
すべてがうまくいきました、私は何も変更していません、それはちょうど起こった、これはバインダー565のコードです:
try {
res = onTransact(code, data, reply, flags);
} catch (RemoteException | RuntimeException e) {
if (LOG_RUNTIME_EXCEPTION) {
Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
}
if ((flags & FLAG_ONEWAY) != 0) {
if (e instanceof RemoteException) {
Log.w(TAG, "Binder call failed.", e);
} else {
Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
}
} else {
reply.setDataPosition(0);
reply.writeException(e);
}
res = true;
}
エミュレーターにapkをインストールしようとしたときにこの問題が発生し、アプリのapkの古いバージョンをアンインストールする必要があるというエラーメッセージが常に表示されていました。
私はこのように解決しました:
1。ファイル->設定->ビルド、実行、展開。
2。インスタントラン->「インスタントランを有効にして、デプロイ時にコード/リソースの変更をホットスワップする」を有効にします。
3。適用-> OK
その後、プロジェクト(Build-> Clean project)をクリーンアップし、インスタントランを再度有効にして、インスタントランを再び機能させることができます。
インスタントランを無効にする( Android Document )
インスタントランを無効にするには:
APKのインストール中の不明なエラー(Android.os.Binder.execTransact(Binder.Java:702))エラー
このエラーには2つの解決策が考えられます。
解決策1:モバイルの「開発者向けオプション」で「INSTALL VIA USB」オプションを有効にしていることを確認します(特にXiomiデバイスを使用している場合)
解決策2: https://stackoverflow.com/a/46102740/5582162 -@Mithorによって投稿された解決策。
同様のエラーメッセージが表示されました。私のシステムおよび/またはエミュレータがストレージスペースを使い果たし、APKをインストールできなかったことが判明しました。 Mithorのソリューションは、メモリ不足エラーを明らかにしました。その後、スペースを解放してからインスタントランを有効にすることができました。
こんにちは私はインスタントランを無効にし、魅力のように動作します。
私の場合、プロジェクトをクリーンアップしてから、コードを再構築しました。そして、Mi or Xiomi
電話では、開発者オプションで「INSTALL VIA USB」を有効にしました。
同様のエラーメッセージが表示されました。私の場合、プロジェクトのフォルダを変更したためです。プロジェクトを別のフォルダーに移動し、apkをデバイスにインストールしようとすると、同様のエラーで失敗しました。私の場合、データの削除、古いアプリのアンインストール、プロジェクトのクリーニング、新しいapkの構築が役立ちました。
同様の問題がありました。私の電話スペースは非常に少なかった。携帯電話のスペースを増やしただけで、うまくいきました。
あなたのソリューションは私のもので機能しましたが、アプリが正常に実行されたときでも、問題を有効に戻すと再発しました。次に、Build Projectドキュメントに従い、Dhaval Jardoshのアドバイスに従って Android Documentation で、アプリが実行を開始したクリーンなプロジェクトを実行しますInstant Runを有効にします。
このクラッシュは、理由もなく突然現れました。 Android Studioとデバイスを再起動しました。そしてそれは働いた。両方のソリューションが必要なのか、どちらか一方だけが必要なのかはわかりません。
また、アプリをインストールするのに十分な空きディスクがデバイスにあることも確認してください。実際、アプリが10か月であっても、デバイスで300か月以下の空きがある場合、この問題が発生する可能性があります。
これは通常、デバイスとJNIが一致しないためです。たとえば、デバイスはX86 ABIですが、ARMにはJNIを使用します。