android 系统自始至终要求打印操作必须在 activity 上下文中执行，service 中调用 printmanager 会抛出 illegalstateexception，即使在 android 11+ 也无效；正确做法是通过 activity 启动打印流程，或使用 activityresultlauncher 回调驱动。
在 Android 开发中，PrintManager 是一个受严格上下文约束的系统服务。正如异常信息明确指出的那样：
IllegalStateException: Can print only from an activity
该限制并非 Android 11 或更高版本新增的限制，而是自 PrintManager API（API 19+）引入以来就存在的设计约束。其根本原因在于：打印流程涉及用户交互（如选择打印机、设置页边距、预览文档等），而这些 UI 操作必须依附于具有生命周期和窗口令牌（Window Token）的 Activity 上下文。Service 属于无界面组件，不具备启动系统打印对话框所需的 UI 能力，因此即使你持有有效的 Context（如 getApplicationContext() 或 Service.this），调用 printManager.print(...) 仍会失败。
✅ 正确实现方式（推荐 AndroidX + Activity Result API）
不要在 Service 内部触发打印，而是将打印逻辑“委托”给前台 Activity。典型方案如下：
- Service 检测到需打印时，发送通知或广播，唤醒/跳转至目标 Activity；
- Activity 接收参数（如 PDF 路径），使用 ActivityResultLauncher<Intent> 启动打印流程。
示例代码（Kotlin，基于 androidx.activity:activity-ktx:1.8.0+）：
// 在 Activity 中声明 launcher
private val printLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
if (result.resultCode == Activity.RESULT_OK) {
Log.d("Print", "Print job submitted successfully")
}
}
// 触发打印（例如响应 Service 的 Intent 或本地按钮）
fun startPdfPrint(pdfPath: String) {
val printManager = getSystemService(Context.PRINT_SERVICE) as PrintManager
val printAdapter = PdfDocumentAdapter(pdfPath) // 自定义 PrintDocumentAdapter
val jobName = getString(R.string.app_name) + "_document"
// ✅ 关键：必须在 Activity 中调用
printManager.print(jobName, printAdapter, PrintAttributes.Builder().build())
}⚠️ 注意事项：PdfDocumentAdapter 必须正确实现 onLayout() 和 onWrite()，并妥善处理异步写入（建议使用 ParcelFileDescriptor + OutputStream）；若 PDF 文件位于私有目录（如 getFilesDir()），需通过 FileProvider 提供 content:// URI，否则 PdfDocumentAdapter 可能因权限拒绝读取；Android 12+（API 31）起，后台服务受限更严，绝对禁止从前台服务或绑定服务中尝试绕过 Activity 启动打印；不要尝试使用 ContextThemeWrapper 或反射伪造 Activity Context —— 这不仅无效，还可能触发 SecurityException 或静默失败。
? 替代思路（无 UI 场景）
若应用为纯后台工具（如 Kiosk 模式或企业定制设备），且需免交互打印，可考虑：
- 使用厂商 SDK（如 Zebra、Brother 提供的专用打印 SDK）；
- 通过网络协议直连打印机（IPP、ESC/POS）；
- 利用 WorkManager + ForegroundService 预生成打印数据，再由 Activity 在前台一键提交。
总之，“Service 中打印”在标准 Android 架构下不可行，也不是版本兼容问题，而是平台级设计原则。坚持将用户感知型操作（打印、分享、拍照、文件选择）交由 Activity 承载，既是合规要求，也是保障用户体验与系统稳定性的最佳实践。
