简介本资源是一份面向Android开发初学者与中级工程师的日历日程功能实战源码包聚焦系统级日历数据的读写、增删改查及异步处理等核心场景适用于生产力工具、事件管理类App开发学习。压缩包共33个文件含6个Java主逻辑文件实现ContentResolver调用与CalendarContract交互、14个XML配置与布局文件含AndroidManifest权限声明与UI定义、5个PNG图标资源以及基础构建配置project.properties、.classpath等整体体积仅622KB轻量易导入。已有286人下载学习代码结构清晰完整覆盖日历权限申请、Cursor遍历查询、ContentValues构造插入、事件ID精准更新与删除等关键流程并包含日期时间转换Calendar/LocalDateTime与后台线程实践建议。预览可见AndroidManifest.xml明确声明READ/WRITE_CALENDAR权限src目录下Java类封装了典型CRUD操作是理解Android原生日历API集成的优质入门范例。1. 这不是“调个 API”就能跑的日历 Demo它暴露了 Android 日历权限演进的真实断层很多开发者第一次在 Android 上加日程功能时会直接复制一段ContentResolver.insert()代码发现模拟器能跑、真机点开就闪退——不是代码写错了而是你根本没意识到从 Android 6.0API 23开始WRITE_CALENDAR已经是运行时危险权限而到了 Android 12API 31系统日历 Content Provider 的 URI 路径、事件字段语义、甚至默认日历账户的判定逻辑全被重构过。这个名为“Android系统日历日程操作”的源码包表面看是十年前的老项目.project.classpathproguard-project.txt是 ADT 时代的典型痕迹但它恰恰卡在权限模型切换的临界点上AndroidManifest.xml里声明了权限但src/下的 Java 文件里没有ActivityCompat.requestPermissions()也没有适配CalendarContract.Events.DTSTART在不同时区下的毫秒精度陷阱。它不适合直接上线但极其适合做「权限迁移沙盘」——你能在同一套代码里一边复现 Android 5.1 的静默写入一边亲手打补丁让它在 Android 13 上通过CalendarContract.Events.CALENDAR_ID校验。如果你正在维护一个需要兼容 Android 814 的会议类 App或者正被SecurityException: Permission Denial卡在测试阶段这个压缩包就是你的故障注入靶场。2. 权限与 Provider从 Manifest 声明到 Runtime 检查的完整链路2.1 权限声明的三重校验Manifest、Runtime、Target SDK 版本这个源码包的AndroidManifest.xml中明确写了两行权限uses-permission android:nameandroid.permission.READ_CALENDAR / uses-permission android:nameandroid.permission.WRITE_CALENDAR /但这只是起点。Android 系统在运行时会执行三重校验Manifest 存在性校验编译期检查AndroidManifest.xml是否包含该权限声明Runtime 授权校验API ≥ 23 时必须在 Activity 或 Fragment 中显式调用requestPermissions()且用户点击“允许”后才能访问Target SDK 语义校验当targetSdkVersion ≥ 30Android 11系统会强制要求WRITE_CALENDAR必须配合QUERY_ALL_PACKAGES仅限特殊场景或使用android:maxSdkVersion29降级兼容——但后者已被 Google Play 商店拒绝。提示该源码包的project.properties显示targetandroid-19说明它默认只适配到 Android 4.4。若你将其升级到targetSdkVersion 34必须重写权限请求逻辑否则insert()调用会直接抛出SecurityException且 Logcat 中不会显示具体原因只会报java.lang.SecurityException: Permission Denial。2.2 CalendarContract 的 URI 结构与字段映射Android 日历数据通过content://com.android.calendar/...开头的 Content URI 暴露但该 URI 并非硬编码。源码中src/com/example/calendar/CalendarHelper.java使用了如下常量// 源码中的老式写法已弃用 private static final String CALENDAR_URI_BASE content://com.android.calendar; public static final Uri EVENTS_URI Uri.parse(CALENDAR_URI_BASE /events);这种写法在 Android 8.0 上会失败因为系统不再保证com.android.calendar包名稳定。正确做法是使用CalendarContract提供的静态 URI// 替换为标准写法兼容 API 14 import android.provider.CalendarContract; ... Uri eventsUri CalendarContract.Events.CONTENT_URI; // 自动适配底层实现更重要的是字段映射。源码中插入事件时使用values.put(title, 会议); values.put(eventLocation, 会议室A); values.put(dtstart, startTimeMillis); values.put(dtend, endTimeMillis);这些字符串键在新版本中已失效。必须改用CalendarContract.Events定义的常量源码旧键正确常量说明titleCalendarContract.Events.TITLE字符串类型长度限制 255 字符eventLocationCalendarContract.Events.EVENT_LOCATION支持地理坐标扩展需额外字段dtstartCalendarContract.Events.DTSTART必须为毫秒时间戳UTC非本地时间dtendCalendarContract.Events.DTEND同上且必须 DTSTART2.2.1 时间戳陷阱为什么你的日程总比预期早/晚 8 小时源码中startTimeMillis很可能来自Calendar.getInstance().getTimeInMillis()这返回的是本地时区时间戳。但CalendarContract.Events.DTSTART要求的是UTC 时间戳。例如在上海GMT8创建一个 2024-06-01 09:00 的事件若直接传入1717203600000对应北京时间系统会将其解释为 UTC 时间 2024-06-01 09:00最终在日历中显示为北京时间 17:00。正确转换方式Java 8ZonedDateTime zdt ZonedDateTime.of(2024, 6, 1, 9, 0, 0, 0, ZoneId.of(Asia/Shanghai)); long utcMillis zdt.withZoneSameInstant(ZoneId.of(UTC)).toInstant().toEpochMilli(); values.put(CalendarContract.Events.DTSTART, utcMillis);或使用Calendar兼容低版本Calendar cal Calendar.getInstance(TimeZone.getTimeZone(UTC)); cal.set(2024, Calendar.JUNE, 1, 9, 0, 0); long utcMillis cal.getTimeInMillis();2.3 查询日历账户从硬编码 ID 到动态枚举源码中常见写法是直接指定calendar_id 1values.put(CalendarContract.Events.CALENDAR_ID, 1L);这是严重错误。calendar_id是系统分配的唯一整数不同设备、不同账户、甚至同一设备重装日历 App 后都可能变化。必须先查询可用日历// 查询所有可写的日历账户 String[] projection { CalendarContract.Calendars._ID, CalendarContract.Calendars.ACCOUNT_NAME, CalendarContract.Calendars.CALENDAR_DISPLAY_NAME, CalendarContract.Calendars.CALENDAR_ACCESS_LEVEL }; String selection CalendarContract.Calendars.VISIBLE 1 AND CalendarContract.Calendars.CALENDAR_ACCESS_LEVEL CalendarContract.Calendars.CAL_ACCESS_OWNER; Cursor cursor getContentResolver().query( CalendarContract.Calendars.CONTENT_URI, projection, selection, null, null ); if (cursor ! null cursor.moveToFirst()) { do { long id cursor.getLong(cursor.getColumnIndexOrThrow(CalendarContract.Calendars._ID)); String account cursor.getString(cursor.getColumnIndexOrThrow(CalendarContract.Calendars.ACCOUNT_NAME)); String name cursor.getString(cursor.getColumnIndexOrThrow(CalendarContract.Calendars.CALENDAR_DISPLAY_NAME)); Log.d(Calendar, ID: id , Account: account , Name: name); // 选择第一个可写日历或按业务逻辑筛选 if (id 0) selectedCalendarId id; } while (cursor.moveToNext()); } cursor.close();注意CalendarContract.Calendars.CALENDAR_ACCESS_LEVEL返回的是整数值CAL_ACCESS_OWNER 700表示完全控制权。不能仅靠VISIBLE 1判断可用性。3. CRUD 实战从插入事件到处理异步冲突的完整流程3.1 插入事件带事务保护与冲突检测源码中insertEvent()方法直接调用ContentResolver.insert()但生产环境必须包裹事务并检查返回值ContentValues values new ContentValues(); values.put(CalendarContract.Events.CALENDAR_ID, selectedCalendarId); values.put(CalendarContract.Events.TITLE, 项目评审会); values.put(CalendarContract.Events.EVENT_LOCATION, 3F-会议室B); values.put(CalendarContract.Events.DTSTART, startUtcMillis); values.put(CalendarContract.Events.DTEND, endUtcMillis); values.put(CalendarContract.Events.EVENT_TIMEZONE, Asia/Shanghai); // 关键指定事件时区 values.put(CalendarContract.Events.ALL_DAY, 0); // 0非全天1全天 values.put(CalendarContract.Events.HAS_ALARM, 1); // 是否有提醒 // 启动事务防止部分写入 getContentResolver().acquireContentProviderClient(CalendarContract.AUTHORITY).getLocalContentProvider() .getContext().getContentResolver().beginTransaction(); try { Uri uri getContentResolver().insert(CalendarContract.Events.CONTENT_URI, values); if (uri ! null) { long eventId ContentUris.parseId(uri); // 获取插入后的 _ID Log.d(Calendar, Event inserted with ID: eventId); // 设置提醒需单独插入 alarms 表 setAlarmForEvent(eventId, -30); // 提前30分钟 getContentResolver().setTransactionSuccessful(); } else { throw new RuntimeException(Insert failed: uri is null); } } finally { getContentResolver().endTransaction(); }3.1.1 提醒设置必须通过CalendarContract.Reminders表源码中未实现提醒功能。正确做法是插入事件后向Reminders表添加记录private void setAlarmForEvent(long eventId, int minutesBefore) { ContentValues reminderValues new ContentValues(); reminderValues.put(CalendarContract.Reminders.EVENT_ID, eventId); reminderValues.put(CalendarContract.Reminders.METHOD, CalendarContract.Reminders.METHOD_ALERT); reminderValues.put(CalendarContract.Reminders.MINUTES, minutesBefore); getContentResolver().insert(CalendarContract.Reminders.CONTENT_URI, reminderValues); }METHOD_ALERT表示弹窗提醒MINUTES为负数如-15表示提前15分钟。3.2 更新与删除基于_ID的精确操作与软删除策略源码中更新事件使用update()方法但未处理WHERE子句的 SQL 注入风险。正确写法应使用参数化查询// 安全更新避免 WHERE title title ContentValues updateValues new ContentValues(); updateValues.put(CalendarContract.Events.TITLE, 已延期项目评审会); updateValues.put(CalendarContract.Events.DTSTART, newStartUtcMillis); updateValues.put(CalendarContract.Events.DTEND, newEndUtcMillis); int rows getContentResolver().update( CalendarContract.Events.CONTENT_URI, updateValues, CalendarContract.Events._ID ?, new String[]{String.valueOf(eventId)} // 参数化占位符 ); Log.d(Calendar, Updated rows rows);提示CalendarContract.Events.DELETED字段用于软删除值为1而非物理删除。物理删除会触发同步服务清除云端副本软删除仅隐藏本地视图。生产环境推荐优先使用软删除。3.3 异步操作为什么 AsyncTask 已淘汰以及现代替代方案源码中使用AsyncTask执行日历操作但AsyncTask在 Android 11 已废弃且存在内存泄漏风险。现代方案有二方案一使用WorkManager推荐用于后台持久任务// 创建日历插入任务 OneTimeWorkRequest insertWork new OneTimeWorkRequest.Builder(CalendarInsertWorker.class) .setInputData(new Data.Builder() .putLong(start_millis, startUtcMillis) .putLong(end_millis, endUtcMillis) .putString(title, 自动同步事件) .build()) .build(); WorkManager.getInstance(this).enqueue(insertWork);CalendarInsertWorker继承CoroutineWorker在doWork()中执行ContentResolver操作。方案二使用ExecutorsLiveData轻量级 UI 绑定private void insertEventAsync(ContentValues values) { Executors.newSingleThreadExecutor().execute(() - { try { Uri result getContentResolver().insert(CalendarContract.Events.CONTENT_URI, values); // 切回主线程更新 UI runOnUiThread(() - { if (result ! null) { Toast.makeText(this, 日程添加成功, Toast.LENGTH_SHORT).show(); } }); } catch (Exception e) { runOnUiThread(() - Toast.makeText(this, 添加失败: e.getMessage(), Toast.LENGTH_LONG).show() ); } }); }4. 兼容性验证与调试技巧定位 “Permission Denied” 的真实源头4.1 分层日志诊断从 Logcat 到 adb shell dumpsys当遇到SecurityException: Permission Denial不要只看堆栈。分三层排查第一层检查权限是否真正授予adb shell pm list permissions -g | grep calendar adb shell dumpsys package com.your.app.package | grep -A 10 android.permission.WRITE_CALENDAR输出中应包含grantedtrue。若为false说明用户拒绝或未请求。第二层验证 ContentProvider 是否可访问# 查看日历 Provider 状态 adb shell dumpsys activity provider com.android.calendar # 或直接尝试查询需 root adb shell content query --uri content://com.android.calendar/calendars若返回SecurityException说明 Provider 层拦截非 App 层问题。第三层抓取实际执行的 URI 和权限在ContentResolver.insert()前插入日志Log.d(CalendarDebug, Inserting to: CalendarContract.Events.CONTENT_URI); Log.d(CalendarDebug, Values: values.toString()); Log.d(CalendarDebug, Calling UID: Binder.getCallingUid());对比adb shell dumpsys package | grep -A 5 userId中的 UID确认调用者身份匹配。4.2 真机调试必备ADB 命令快速验证日历状态以下命令无需 Root可在任意 Android 8 设备执行用于验证环境是否就绪命令用途预期输出adb shell cmd package list packages | grep calendar列出所有日历相关包com.google.android.calendar,com.samsung.android.app.calendaradb shell content query --uri content://com.android.calendar/calendars --projection _id:account_name:calendar_display_name查询可用日历多行 JSON含_id和calendar_display_nameadb shell content query --uri content://com.android.calendar/events --where dtstart1717200000000 --limit 5查询近期事件若权限不足则报错否则返回事件列表注意content query命令在 Android 10 需要adb shell用户具有shell权限普通adb连接即可。4.3 源码包改造 checklist让老项目跑在 Android 14 上将该 ZIP 包升级为现代项目必须完成以下 7 项改造缺一不可改造项操作位置关键代码/配置1. 权限请求MainActivity.javaif (ContextCompat.checkSelfPermission(...) ! PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(...); }2. Target SDK 升级build.gradletargetSdkVersion 34compileSdkVersion 343. URI 替换所有content://com.android.calendar/...替换为CalendarContract.Events.CONTENT_URI等静态常量4. 时间戳修正CalendarHelper.java所有dtstart/dtend赋值前强制转为 UTC 毫秒5. 日历 ID 动态获取CalendarHelper.java删除硬编码calendar_id 1改用query(Calendars.CONTENT_URI)6. 提醒集成CalendarHelper.java新增setAlarmForEvent()方法插入Reminders.CONTENT_URI7. 异步封装CalendarHelper.java将insert/update/delete方法改为suspend fun或WorkRequest完成上述改造后该源码包就不再是“教学示例”而是一个可嵌入企业级会议 App 的日历操作 SDK 基础模块——它覆盖了从 Android 8 到 14 的全部兼容边界且所有操作均通过CalendarContract标准接口杜绝了厂商定制 ROM 的 URI 差异问题。本文还有配套的精品资源点击获取