@Luksprogは基本的に、あなたの質問の最初にこれに答えましたが、その主張をさらにサポートするためのドキュメントがいくつかあります。
まず、javadoc を注意深く読んでください。関連するキーワードをいくつか強調しました。ActivityCompat#startActivity(Activity activity, Intent intent, Bundle options)
可能であれば、追加の起動情報を使用してアクティビティを開始します。
Android 4.1 以降では、アクティビティの起動アニメーションをより詳細に制御できるようにする追加のオプションが導入されました。アプリケーションは、ActivityOptionsCompat と共にこのメソッドを使用して、利用可能な場合にこれらのアニメーションを使用できます。この機能が存在しないバージョンのプラットフォームで実行すると、アクティビティは正常に起動されます。
基本的に、(オプションの) アニメーション機能は、それをネイティブにサポートするバージョンの Android でのみ動作することがわかります。他のすべてのプラットフォーム バージョンでは、Activity
は「通常どおり」、つまり、オプションのアニメーションなしで起動されます。
実際の証明は、次のソース コードでActivityCompat
簡単に見つけることができます。
public static void startActivity(Activity activity, Intent intent, Bundle options) {
if (Build.VERSION.SDK_INT >= 16) {
ActivityCompatJB.startActivity(activity, intent, options);
} else {
activity.startActivity(intent);
}
}
言い換えれば、このコードが JB 以前のデバイスで実行されると、単純な古いstartActivity()
呼び出しは異常になり、options
パラメーターが無視されます。最終的にそれを使用するのは JB デバイスだけです。
言及するのはおそらく冗長ですが、明らかに同じことがstartActivityForResult()
相手にも当てはまります。
要約すると: 現在、サポート ライブラリは、特定の機能を「下位互換性のある方法」で実行するための静的ヘルパー クラスを提供しているだけです。実際には、その機能を (まだ) バックポートしていません。この段階で行うことはif/else
、独自のアプリで条件を記述する必要がなくなることだけです。
そうは言っても、現在の実装では、実際の機能の将来のバックポートが可能です。それがおそらくActivityOptionsCompat
クラスが存在する理由でもあります。現在、このクラスは JB 以前のデバイス用に「空の」実装を提供していますが、理論上は後の段階で「埋められる」可能性があります。これらの互換性ヘルパーを介して呼び出すコードは、自動的に機能し始めます。
ActivityOptionsCompat
空の実装を返す呼び出しの例:
public static ActivityOptionsCompat makeCustomAnimation(Context context,
int enterResId, int exitResId) {
if (Build.VERSION.SDK_INT >= 16) {
return new ActivityOptionsImplJB(
ActivityOptionsCompatJB.makeCustomAnimation(context, enterResId, exitResId));
}
return new ActivityOptionsCompat();
}