1## Functionality {#functionality} 2 3### Network access {#functionality-network} 4 5Jetpack libraries may only access the network as part of the library's 6advertised functionality or at the explicit request of the client as part of a 7documented API contract. 8 9For example, an image loading library *may* download an image from the network 10as part of handling an API call to obtain a `Bitmap` from a `URL`. However, the 11image loading library **must not** report API usage metrics to a Google server 12because that is not required for image loading, nor is it behavior that the 13client explicitly asked for. 14 15### Notifications {#functionality-notifications} 16 17Jetpack libraries may only post notifications at the explicit request of the 18client as part of a documented API contract. 19 20For example, the `compat` library *may* post notifications as the result of a 21client calling `NotificationsCompat` APIs. However, the `compat` library **must 22not** post notifications to advertise a feature in the library. 23 24### Logging {#functionality-logging} 25 26Jetpack libraries should do no logging (`android.util.Log.v`, 27`android.util.Log.d`, `android.util.Log.i`, `System.out.println`, etc) in 28production library code by default. All error states must be handled through 29standard error return methanisms like return codes and exceptions with detailed 30messages instead of relying on logging. Logging is easy to miss and hard to 31build around. A library *may* provide an optional API to enable debug logging 32when library has complex state management. 33