OSに付属しているものよりも新しいバージョンのopensslをアプリで実行する必要があります。新しいバージョンをコンパイルするためにAndroidソースにパッチを適用し、アプリで使用する共有ライブラリを抽出することができました。
その後、opensslの新しいバージョンでのみ関数を必要とするネイティブコードをコンパイルして、新しい共有ライブラリに対してリンクすることができました（新しいopensslへのパッチが機能しました）。
期待どおりに機能するいくつかのjni関数を作成することもできましたが、アプリのローカルにある新しいopenssl共有ライブラリにのみある関数を追加するとすぐに、満足できないリンクエラーが発生します。
私の仮定は、libcryptoとlibsslのシステムバージョンが/libs/armeabi/libcrypto.soと/libs/armeabi/libssl.soのローカルバージョンを上書きしているということです....これを修正するにはどうすればよいですか？
システムにはすでに、と呼ばれるライブラリが付属しており、ライブラリlibcryptoよりも先に選択されます。最も簡単な解決策は、ライブラリに別の名前を付けて、それをSystem.loadLibrary(...)呼び出しで使用することです。
アップデート
ご指摘のとおり、ファイルの名前を変更するだけでなく、新しい名前でライブラリを再構築する必要があります。
はい、JNIはシステムバージョンを取得しています。パッチが適用されたバージョンはまったく使用されませんでした。-Djava.library.path=/libs/armeabiスタンドアロンJVMでは、環境変数を言うか変更しますLD_LIBRARY_PATH。Androidでは、システムプロパティjava.library.pathを検索して、ライブラリを既知の場所（ただし、システムバージョンがあるフォルダーの前）に配置するか、実際にプロパティを変更して、ローカルバージョンへのパスを追加することができます。私はAndroidの経験はありますが、特にNDKの経験はありません。