Merge "Removes unused inheritence avoidance hacks" into tm-dev

1 files changed, 0 insertions, 80 deletions

diff --git a/core/java/com/android/internal/app/ResolverActivity.java b/core/java/com/android/internal/app/ResolverActivity.java
index ec1307908af0..ea8589bddabb 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
-     * <em>not</em> 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
-     * <em>not</em> 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
-     * <em>not</em> 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
-     * <em>not</em> 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()