[null,null,["最后更新时间 (UTC):2025-09-04。"],[],[],null,["\u003cbr /\u003e\n\nThe **Android Transport Layer** , along with the entire connection between your\nserver, FCM backends, and client devices, is secured using **Transport Layer\nSecurity (TLS)** . This provides strong **point-to-point encryption** for all\ndata while it's in transit, protecting it from being intercepted on the network.\nThis robust security model is suitable for the vast majority of applications.\nYou can find more details in the [FCM Architecture](https://firebase.google.com/docs/cloud-messaging/fcm-architecture)\ndocumentation.\n\nOne of the limitations of point to point encryption is that it's not encrypted\nfor its entire path where only the sender and receiver can decode the message.\nThis is why FCM recommends using end to end encryption for privacy\nsensitive communications like chat messages or authentication transcations. In\norder to get the most from end to end encryption, it must be implemented at a\nhigher level, such as within your servers and app code.\n\nAdd End-to-End Encryption for Sensitive Data\n\nFor applications handling particularly sensitive data, like private messages or\npersonal credentials, you can add an additional layer of protection with\n**end-to-end encryption (E2EE)** . The process involves encrypting the message payload on your server before\nsending it to FCM and decrypting it within your app on the user's device. This works with FCM data messages, as standard notification\npayloads are handled by the operating system and cannot be decrypted by your app\nbefore being displayed.\n\nNote that FCM doesn't provide a built-in solution for end-to-end encryption.\nYou are responsible for implementing this security layer within your\napplication. There are external libraries and protocols designed for this\npurpose, such as\n[Capillary](https://android-developers.googleblog.com/2018/06/project-capillary-end-to-end-encryption.html)\nor [DTLS](https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security).\n\nConceptual Example\n\nHere is how the FCM `data` payload changes when using E2EE.\n\nBefore Encryption (Standard Payload): \n\n {\n \"token\": \"DEVICE_REGISTRATION_TOKEN\",\n \"data\": {\n \"sender\": \"user123\",\n \"message_body\": \"Your 2FA code is 555-123\",\n \"timestamp\": \"1661299200\"\n }\n }\n\nAfter Encryption (E2EE Payload): \n\n {\n \"token\": \"DEVICE_REGISTRATION_TOKEN\",\n \"data\": {\n \"encrypted_payload\": \"aG9va2Vk...so much encrypted gibberish...ZW5jcnlwdA==\"\n }\n }\n\nIf you have implemented your e2e encryption correctly, the client application is\nthe only party capable of decrypting encrypted payload to reveal the original\nmessage.\n| **Caution:** When implementing end-to-end encryption, never store your encryption keys directly in your APK or in shared storage. This makes them vulnerable to decompilation or unauthorized access, compromising your entire security model.\n\nAlternative: Fetching Content Directly from Your Server\n\nIf end-to-end encryption isn't suitable for your app, you can instead send empty data\nmessages. These messages act as a signal for the app to\nfetch the content directly from your servers. This means the\nsensitive data is only transported between your app and your servers, bypassing\nFCM for the data transfer.\n\nA drawback of this method is the potential delay caused by the app connecting to\nyour server to retrieve the data. When an app receives a data message, it\ntypically has only a few seconds to display a notification before being\nbackgrounded. Fetching data from your server might not complete within this\nwindow. The success of this data fetch depends on factors like the user's\ndevice connectivity.\n\nTherefore, consider user experience alternatives for situations where the data\nfetch might take too long. For example, you could display a generic notification\nlike \"You have a new message\" and then update it once the full content is\nretrieved."]]