Loading core/java/com/android/internal/app/ResolverActivity.java +0 −80 Original line number Diff line number Diff line Loading @@ -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() Loading Loading
core/java/com/android/internal/app/ResolverActivity.java +0 −80 Original line number Diff line number Diff line Loading @@ -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() Loading
