Removes unused inheritence avoidance hacks

Change-Id: Ied80d8fc3b12aa5503ba6c4f01063cea4f2cf7ea
This commit is contained in:
Mark Renouf
2022-03-09 10:40:27 -05:00
parent 871b78954a
commit f9179a9354

View File

@@ -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()