Should we revert PreviewDevice (and associated code)?

@andrewkolos

I am working on a totally unrelated set of features in #162649.

As part of this, I noticed that <FlutterCommand>.verifyThenRunCommand always checks for "allowed plugins":

flutter/packages/flutter_tools/lib/src/runner/flutter_command.dart

Lines 1897 to 1904 in f5e8fc3

    
           // null implicitly means all plugins are allowed 
        
           List<String>? allowedPlugins; 
        
           if (stringArg(FlutterGlobalOptions.kDeviceIdOption, global: true) == 'preview') { 
        
             // The preview device does not currently support any plugins. 
        
             allowedPlugins = PreviewDevice.supportedPubPlugins; 
        
           } 
        
           await project.regeneratePlatformSpecificTooling( 
        
             allowedPlugins: allowedPlugins,

This is problematic, today regeneratePlatformSpecificTooling is called once (implicitly when --no-pub is omitted), even on so-called "meta builds" such as flutter build aar or flutter build ios-framework which, by default, build debug, profile, and release mode builds.

With an upcoming change (--explicit-pacakge-dependencies), we need to inform regeneratePlatformSpecificTooling what the current build mode is. So, this code to regenerate platform specific tooling needs to be run differently for meta-builds. @andrewkolos mentioned this project is on indefinite hiatus, so if so, should we revert/remove the associated code (it can always be restored via Git-foo in the future)?

@christopherfujino assigning to you - if you are OK with this revert, LMK, otherwise we can chat further.

@matanlurey

@matanlurey reverting sounds good to me, productionizing this is blocked on figuring out how to link a debug flutter windows app with the release VC++ runtime.

Revert the `preview-device` feature, tests, and code that only existe…

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Should we revert `PreviewDevice` (and associated code)? #162693

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// null implicitly means all plugins are allowed
	List<String>? allowedPlugins;
	if (stringArg(FlutterGlobalOptions.kDeviceIdOption, global: true) == 'preview') {
	// The preview device does not currently support any plugins.
	allowedPlugins = PreviewDevice.supportedPubPlugins;
	}
	await project.regeneratePlatformSpecificTooling(
	allowedPlugins: allowedPlugins,

Should we revert PreviewDevice (and associated code)? #162693

Description

Activity

christopherfujino commented on Feb 5, 2025

github-actions commented on Feb 22, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Should we revert `PreviewDevice` (and associated code)? #162693