通过街景直接上传
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
2.1 版
背景
在早期版本的 API 中，符合 OSC 标准的相机会创建一个 Google 街景 iOS 和 Android 应用可连接的 Wi-Fi 接入点。该应用将引导 OSC 相机拍摄照片，并从相机下载拍摄的内容，然后发布到 Google 街景。为了加快内容的发布内容速度，我们引入了一个新的可选工作流，可让 OSC 相机将内容直接上传到街景服务器。这样就消除了将内容从相机传输到应用再从应用传输到街景服务器的漫长双重传输。此 API 是在 API 级别 2.1 中添加的，仅与 OSC 相机相关，这些相机既能提供 Wi-Fi 接入点，又能连接到可访问互联网的基础架构 Wi-Fi 接入点。
概览
新的上传工作流需要相机提供一种方式（例如，专用的实体按钮或现有按钮的组合），让用户能够在两种 Wi-Fi 模式之间切换：
- 直接模式：在此模式下，相机可作为接入点，供移动设备用来连接到相机。在此模式下，移动设备可以控制相机来执行拍照等任务。移动设备还可以为相机提供 Wi-Fi 接入点凭据，然后相机可以使用该凭据切换到互联网模式。
- 互联网模式：在此模式下，相机会连接到可连接到互联网的 Wi-Fi 接入点。当相机之前处于直接模式时，它将使用应用提供给它的接入点标识符和密码。在此模式下，移动设备可以直接启动从相机到街景服务器的上传操作。他们还可以继续控制相机以执行拍照等任务。
在摄像头关闭并重新开启后，摄像头模式应保持不变。此外，强烈建议摄像头提供信号（例如灯光、声音或屏幕上的指示标志），告知用户当前 Wi-Fi 模式。
相机还应实现发现协议（请参阅发现），以便在相机处于互联网模式时处理通信。
互联网模式设置
- 用户开启摄像头。由于尚未设置互联网模式，因此它以直接模式启动。
- 移动设备会连接到相机的 Wi-Fi 网络。
- 应用会生成自签名证书。
- 应用向相机发送
switchWifi 命令，其中包含相机需要连接到的基础架构 Wi-Fi 接入点的 SSID、该接入点的密码以及相机稍后用于对应用进行身份验证的自签名证书。
- 请注意，相机应安全地存储 Wi-Fi 凭据和应用的自签名证书。
- 建议相机存储多个 Wi-Fi 凭据，因为相机可能需要连接到不同基础架构的 Wi-Fi 接入点。对该相机的最低要求是存储最新的 Wi-Fi 凭据。
- 相机通过其自签名证书进行响应，应用稍后会使用该证书对相机进行身份验证。
- 用户现在可以直接通过摄像头（例如使用实体切换按钮）在直接模式和互联网模式之间切换。
发现广告系列
OSC 相机发现是一项基于 Zeroconf 的协议。摄像头必须实现 IPv4 链路本地地址，并且必须符合 mDNS（多播 DNS）和 DNS-SD（基于 DNS 的服务发现）规范：
服务实例名称
对于服务实例名称的 <Service> 部分，OSC 相机应使用 _osc._tcp。对于服务实例名称的 <Domain> 部分，OSC 相机应使用 local.。请注意，local 后面有一个 .。
TXT 记录
我们要求相机在 TXT 记录中发送以下键值对：txtvers、ty 和 id。
文本文件
若要允许未来更新 TXT 版本，请使用键值对 txtvers=1。
ty
提供用户可读的相机名称，例如 ty=Google Street View Optimized Spherical Camera Model XYZ。
id
提供相机的唯一 ID，例如 id=A unique id of the camera。id 的值必须与 /osc/info 输出中的 cameraId 相同。
通告
在摄像头启动或关闭时，摄像头必须执行 mDNS 规范中所述的通知步骤。应至少发送两次相应的通告，两次之间至少应间隔 1 秒。
初创公司
在摄像头启动时，它必须执行探测和公告步骤，如 mDNS 规范中所述。在这种情况下，应发送 SRV、PTR 和 TXT 记录。如果可能，建议将所有记录分组到一个 DNS 响应中。否则，建议按以下顺序排列：SRV、PTR、TXT 记录。
关停
摄像头关闭时，应尝试通过发送包含 TTL=0 的“再见数据包”来通知所有相关方（如 mDNS 文档的第 10.1 节中所述）。
自签名证书
应用和相机可以使用在互联网模式设置期间共享的自签名证书相互进行身份验证，并使用 SSL 双向身份验证构建一个安全通道来保护交换的数据。
在互联网模式下，应用充当 SSL 服务器，相机充当客户端。相机会检查服务器的证书是否与应用的自签名证书一致，然后应用会检查客户端的证书是否与相机的证书一致。
在互联网模式下，您可以使用任何支持双向身份验证的 SSL 库（例如 OpenSSL）在应用和相机之间建立 SSL 连接。
新上传流程
- 如果相机未处于互联网模式，用户会将其切换为互联网模式。
相机使用存储的凭据连接到基础架构 Wi-Fi。
- 移动设备还会连接到基础架构 Wi-Fi 并发现相机。
- 这需要相机实现本地发现协议 mDNS/DNS-SD（请参阅发现）。
- 对其实现方式没有特定要求（mDNSResponder 是一个很好的参考信息）。
- 在互联网模式设置期间，应用和相机都会生成并共享自签名证书。在互联网模式下，应用和相机均通过双向 SSL 身份验证相互进行身份验证。
- 发现相机后，可基于 HTTP 1.1 直接通过本地网络与相机进行客户端通信。数据格式基于 JSON。请求可以是 GET 或 POST 请求。
- 应用使用
listFiles 命令向相机查询文件列表。
- 应用使用
uploadFile 命令启动上传，将图片或视频直接从相机上传到街景服务器。
- 该应用使用
status 命令定期轮询相机，以查看上传进度。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-25。
[null,null,["最后更新时间 (UTC)：2025-07-25。"],[[["\u003cp\u003eAPI level 2.1 introduces a new workflow enabling OSC cameras to upload content directly to Street View servers, eliminating the need for a mobile intermediary.\u003c/p\u003e\n"],["\u003cp\u003eCameras must support two Wi-Fi modes: Direct mode for initial setup and device control, and Internet mode for direct uploads via an infrastructure Wi-Fi connection.\u003c/p\u003e\n"],["\u003cp\u003eThe setup involves exchanging self-signed certificates between the camera and the mobile app for secure communication and authentication during Internet mode.\u003c/p\u003e\n"],["\u003cp\u003eCameras are required to implement a local discovery protocol (mDNS/DNS-SD) for the mobile app to locate them on the infrastructure Wi-Fi network.\u003c/p\u003e\n"],["\u003cp\u003eThe new upload flow involves discovering the camera, querying for files, initiating uploads directly from the camera, and monitoring progress via status commands.\u003c/p\u003e\n"]]],["OSC cameras with API level 2.1 can use a new workflow to upload content directly to the Street View server. Cameras must support \"Direct mode\" (as an access point) and \"Internet mode\" (connected to Wi-Fi). In \"Internet mode setup\", the app provides Wi-Fi credentials and a self-signed certificate to the camera, and the camera responds with its certificate. In this mode, the camera uses mDNS/DNS-SD for discovery. Content is uploaded using the `uploadFile` command after the app requests the file list, then monitored with the status command.\n"],null,["# Direct Upload via Street View\n\nVersion 2.1\n\nBackground\n----------\n\nIn earlier versions of the API, an OSC compliant camera would create a Wi-Fi\naccess point that the Google Street View iOS and Android apps could connect to.\nThe app would both direct the OSC camera to capture photos and also download the\ncaptured content from the camera to then publish it to Google Street View. To\nexpedite the publication of content, we have introduced a new optional workflow\nthat allows OSC cameras to upload content to the Street View server directly.\nThis eliminates the lengthy double transfer of content first from the\ncamera to the app and then from the app to the Street View server. **This was\nadded in API level 2.1 and is only relevant to OSC cameras that can both provide\na Wi-Fi access point and also connect to an infrastructure Wi-Fi access point\nwith access to the Internet.**\n\nOverview\n--------\n\nThe new upload workflow requires cameras to provide a way (e.g. a dedicated\nphysical button or a combination of existing buttons) to allow users to switch\nbetween two Wi-Fi modes:\n\n- **Direct mode:** In this mode, the camera acts as an access point which allows a mobile device to connect to it. In this mode, mobile devices can control the camera to perform tasks such as capturing photos. Mobile devices can also provide the camera with Wi-Fi access point credentials that the camera can then use to switch to **Internet mode**.\n- **Internet mode:** In this mode, the camera connects to a Wi-Fi access point with Internet access. It will use the access point identifier and password that was provided to it from the app when the camera was previously in **Direct mode**. Mobile devices can initiate uploads from the camera directly to the Street View server in this mode. They can also continue to control the camera to perform tasks such as capturing photos.\n\nThe camera mode should persist across the camera being turned off and being\nturned back on again. Also, it is highly recommended that the camera offer a\nsignal (e.g. light, sound or indicator on a screen) to inform users of the\ncurrent Wi-Fi mode.\n\nThe camera should also have discovery protocols\n(see [Discovery](/streetview/open-spherical-camera/guides/direct-upload#discovery))\nimplemented to handle communication while the camera is in **Internet mode**.\n\nInternet Mode Setup\n-------------------\n\n1. The user turns on the camera. It starts in **Direct mode** since **Internet mode** is not yet set up.\n2. The mobile device connects to camera's Wi-Fi.\n3. The app generates a self-signed certificate.\n4. The app sends the [`switchWifi`](/streetview/open-spherical-camera/reference/camera/switchwifi) command to the camera with the **SSID** of the infrastructure Wi-Fi access point the camera will need to connect to, the **password** for that access point, and its **self-signed certificate** that the camera uses to authenticate the app later.\n - Please note that the camera should store both the Wi-Fi credential and the app's self-signed certificate securely.\n - It is recommended that the camera store multiple Wi-Fi credentials since the camera may need to connect to different infrastructure Wi-Fi access points. The minimum requirement is for the camera to store the most recent Wi-Fi credential.\n5. The camera responds with its self-signed certificate that the app uses to authenticate the camera later.\n6. The user can now switch between **Direct mode** and **Internet mode** directly from the camera, e.g. with a physical toggle button.\n\nDiscovery\n---------\n\nDiscovery for OSC cameras is a zeroconf based protocol. The camera MUST\nimplement IPv4 Link-Local Addressing and MUST comply with the mDNS (Multicast\nDNS) and DNS-SD (DNS-Based Service Discovery) specifications:\n\n- [IPv4 Link-local](http://www.rfc-editor.org/rfc/rfc3927.txt)\n- [mDNS](http://www.rfc-editor.org/rfc/rfc6762.txt)\n- [DNS-SD](http://www.rfc-editor.org/rfc/rfc6763.txt)\n\n### Service Instance Names\n\nFor the `\u003cService\u003e` portion of the Service Instance Name, OSC cameras should use\n`_osc._tcp`. For the `\u003cDomain\u003e` portion of the Service Instance Name, OSC\ncameras should use `local.`. Note that there is a trailing `.` after `local`.\n\n### TXT record\n\nWe require the camera to send the following key/value pairs in the TXT record:\n`txtvers`, `ty`, and `id`.\n\n#### txtvers\n\nTo allow for updates to the TXT version in the future, use the key/value pair\n`txtvers=1`.\n\n#### ty\n\nProvides a user-readable name of the camera, e.g.\n`ty=Google Street View Optimized Spherical Camera Model XYZ`.\n\n#### id\n\nProvides a unique id of the camera, e.g.\n`id=A unique id of the camera`. The value for `id` MUST be the same as the\n`cameraId` in\n[`/osc/info`](/streetview/open-spherical-camera/guides/osc/info#output) output.\n\n### Announcements\n\nOn camera startup or shutdown, the camera MUST perform the announcement step as\ndescribed in the mDNS specification. It SHOULD send the corresponding\nannouncement at least twice with at least a one-second interval between them.\n\n#### Startup\n\nOn camera startup it MUST perform probing and announcing steps as described in\nthe mDNS specification. SRV, PTR and TXT records should be sent in this case. It\nis recommended to group all records into one DNS response if possible. If not,\nthe following order is recommended: SRV, PTR, TXT records.\n\n#### Shutdown\n\nOn camera shutdown it SHOULD try to notify all interested parties by\nsending a \"goodbye packet\" with `TTL=0` as described in section 10.1 of the\nmDNS documentation.\n\nSelf-signed certificate\n-----------------------\n\nThe app and the camera can use the self-signed certificates shared during the\n**Internet mode setup** to authenticate each other and build a secure channel to protect\nexchanged data, using SSL mutual authentication.\n\nDuring the **Internet mode**, the app would act as a SSL server and the camera as a\nclient. The camera would check that the server's certificate matches the app's\nself-signed certificate, and the app would check that the client's certificate\nmatches the camera's.\n\nAny SSL library supporting mutual authentication (e.g. OpenSSL) can be used to\nestablish SSL connection between the app and the camera during the **Internet mode**.\n\nNew Upload Flow\n---------------\n\n1. If the camera is not in **Internet mode** , the user switches it to **Internet mode**. The camera connects to the infrastructure Wi-Fi using stored credentials.\n2. The mobile device also connects to the infrastructure Wi-Fi and discovers the camera.\n - This requires the camera to implement a local discovery protocol mDNS/DNS-SD (see [Discovery](/streetview/open-spherical-camera/guides/direct-upload#discovery)).\n - There is no specific requirement on how it is implemented ([mDNSResponder](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/NetServices/Articles/faq.html) is a good reference).\n - Both the app and the camera generate and share self-signed certificates during the **Internet mode setup** . During **Internet mode**, both the app and the camera authenticate each other through mutual SSL authentication.\n - After the camera has been discovered, client communication is enabled with it directly over the local network based on HTTP 1.1. Data formats are JSON based. Requests may be GET or POST requests.\n3. The app queries the camera for a list of files with the [`listFiles`](/streetview/open-spherical-camera/reference/camera/listfiles) command.\n4. The app initiates upload with the [`uploadFile`](/streetview/open-spherical-camera/reference/camera/uploadfile) command to upload an image or video directly from the camera to the Street View server.\n5. The app polls the camera periodically for upload progress with the [`status`](/streetview/open-spherical-camera/guides/osc/commands/status) command."]]
