From f9179a935429a8eae5061526eeb0f413f7a0ed19 Mon Sep 17 00:00:00 2001 From: Mark Renouf Date: Wed, 9 Mar 2022 10:40:27 -0500 Subject: Removes unused inheritence avoidance hacks Change-Id: Ied80d8fc3b12aa5503ba6c4f01063cea4f2cf7ea --- .../com/android/internal/app/ResolverActivity.java | 80 ---------------------- 1 file changed, 80 deletions(-) diff --git a/core/java/com/android/internal/app/ResolverActivity.java b/core/java/com/android/internal/app/ResolverActivity.java index b43699629699..b7080713c751 100644 --- a/core/java/com/android/internal/app/ResolverActivity.java +++ b/core/java/com/android/internal/app/ResolverActivity.java @@ -328,86 +328,6 @@ public class ResolverActivity extends Activity implements super.onCreate(savedInstanceState); } - /** - * Pass-through API to support {@link ChooserActivity} running in "headless springboard" mode - * where we hand over to the unbundled chooser (while violating many of the invariants of a - * typical ResolverActivity implementation). Subclasses running in this mode need to be able - * to opt-out of the normal ResolverActivity behavior. - * - * TODO: this should be removed later on in the unbundling migration, when the springboard - * activity no longer needs to derive from ResolverActivity. The hold-over design here is - * not good practice (e.g. there could be other events that weren't anticipated as - * requiring this kind of "pass-through" override, and so might fall back on ResolverActivity - * implementations that depend on the invariants that are violated in the headless mode). If - * necessary, we could instead consider using a springboard-only activity on the system side - * immediately, which would delegate either to the unbundled chooser, or to a - * (properly-inheriting) system ChooserActivity. This would have performance implications even - * when the unbundling experiment is disabled. - */ - protected void super_onRestart() { - super.onRestart(); - } - - /** - * Pass-through API to support {@link ChooserActivity} running in "headless springboard" mode - * where we hand over to the unbundled chooser (while violating many of the invariants of a - * typical ResolverActivity implementation). Subclasses running in this mode need to be able - * to opt-out of the normal ResolverActivity behavior. - * - * TODO: this should be removed later on in the unbundling migration, when the springboard - * activity no longer needs to derive from ResolverActivity. The hold-over design here is - * not good practice (e.g. there could be other events that weren't anticipated as - * requiring this kind of "pass-through" override, and so might fall back on ResolverActivity - * implementations that depend on the invariants that are violated in the headless mode). If - * necessary, we could instead consider using a springboard-only activity on the system side - * immediately, which would delegate either to the unbundled chooser, or to a - * (properly-inheriting) system ChooserActivity. This would have performance implications even - * when the unbundling experiment is disabled. - */ - protected void super_onSaveInstanceState(Bundle outState) { - super.onSaveInstanceState(outState); - } - - /** - * Pass-through API to support {@link ChooserActivity} running in "headless springboard" mode - * where we hand over to the unbundled chooser (while violating many of the invariants of a - * typical ResolverActivity implementation). Subclasses running in this mode need to be able - * to opt-out of the normal ResolverActivity behavior. - * - * TODO: this should be removed later on in the unbundling migration, when the springboard - * activity no longer needs to derive from ResolverActivity. The hold-over design here is - * not good practice (e.g. there could be other events that weren't anticipated as - * requiring this kind of "pass-through" override, and so might fall back on ResolverActivity - * implementations that depend on the invariants that are violated in the headless mode). If - * necessary, we could instead consider using a springboard-only activity on the system side - * immediately, which would delegate either to the unbundled chooser, or to a - * (properly-inheriting) system ChooserActivity. This would have performance implications even - * when the unbundling experiment is disabled. - */ - protected void super_onRestoreInstanceState(Bundle savedInstanceState) { - super.onRestoreInstanceState(savedInstanceState); - } - - /** - * Pass-through API to support {@link ChooserActivity} running in "headless springboard" mode - * where we hand over to the unbundled chooser (while violating many of the invariants of a - * typical ResolverActivity implementation). Subclasses running in this mode need to be able - * to opt-out of the normal ResolverActivity behavior. - * - * TODO: this should be removed later on in the unbundling migration, when the springboard - * activity no longer needs to derive from ResolverActivity. The hold-over design here is - * not good practice (e.g. there could be other events that weren't anticipated as - * requiring this kind of "pass-through" override, and so might fall back on ResolverActivity - * implementations that depend on the invariants that are violated in the headless mode). If - * necessary, we could instead consider using a springboard-only activity on the system side - * immediately, which would delegate either to the unbundled chooser, or to a - * (properly-inheriting) system ChooserActivity. This would have performance implications even - * when the unbundling experiment is disabled. - */ - public void super_onConfigurationChanged(Configuration newConfig) { - super.onConfigurationChanged(newConfig); - } - @Override protected void onCreate(Bundle savedInstanceState) { // Use a specialized prompt when we're handling the 'Home' app startActivity() -- cgit v1.2.3-59-g8ed1b