Executive summary
facebook/fresco scores 50 out of 100 and is rated Adequate, while three of its six lenses score higher still: Architecture at 96, rated Exemplary, Code Health at 85, rated Strong, and Performance at 69, rated Adequate.
The score is lower than those three because the weakest lens counts most, and here that is Maturity, which scores 45 and is rated Weak. Its Architecture documentation dimension scores 0 out of 10, and until that reaches 4, Maturity can't be rated higher than Adequate. The first actions are to record your significant design decisions and to resolve the 22 High secret finding(s) in Secrets (history). The weakest lenses score close to each other, so improving any of them moves the score.
40 findings are critical: 23 in Secrets (history), 11 in Static Analysis (SAST), four in Change Coupling and two in Knowledge Freshness.
Watchdog couldn't measure 11 dimensions in this code, among them Code Coverage, Test Reliability and Navigability, so they are left out of the score. The product code is 97,605 lines, which would take an estimated 0.9 person-years, around €130,000, to rebuild.
The weakest lenses score close to each other, so improving any of them moves the score.
New since the last survey: 32 findings
- Cyclomatic Complexity · ProgressiveDecoder.doDecode (cyclomatic 19) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt
- Cognitive Complexity · ProgressiveDecoder.doDecode (cognitive 23) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt
- God Classes · MethodTooLong: ProgressiveDecoder.doDecode imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt
- God Classes · TooManyMethods: BaseProducerContext imagepipeline/src/main/java/com/facebook/imagepipeline/producers/BaseProducerContext.java
- God Classes · FileTooLong: fresco/FrescoFlipperPlugin.java tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java
- Code Duplication · Duplicated block (11 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/SettableProducerContext.java
- Churn × Complexity Hotspots · Hotspot: imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Supply-chain Provenance & Signing · REDACTED
Fixed since the last survey: 6 findings
- Cognitive Complexity · SampleDownloader.downloadImageAsync (cognitive 17) ig-image-loader-sample/src/main/java/com/facebook/fresco/ig/imageloader/sample/SampleDownloader.kt
- Cognitive Complexity · ProgressiveDecoder.doDecodeWithSession (cognitive 16) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt
- God Classes · FileTooLong: producers/DecodeProducer.kt imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt
- Code Duplication · Duplicated block (11 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/SettableProducerContext.java
- Knowledge Freshness · Orphaned knowledge tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java
- Supply-chain Provenance & Signing REDACTED
Rebuild cost: about €130,000 · Estimate
| Cost to rebuild | €44,000 to €220,000, for 733 to 2,326 hours of work, about 0.9 person-years for 1 to 2 engineers |
|---|---|
| Difficulty of the problem | Standard, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write. |
| Quality factor | ×0.7 at a score of 50. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it. |
| Size | Medium: 97,605 lines of product code |
Top priorities
Diagnosis: what the measurements show together
Architecture — module dependency graph
Architecture: which parts of the code depend on which
| uses → | 1 cache.common | 2 common.internal | 3 common.references | 4 drawee.components | 5 fresco.ui.common.ControllerListener2 | 6 imageformat | 7 imagepipeline.transformation | 8 cache.disk | 9 common.memory | 10 fresco.ui.common | 11 imagepipeline.animated.base | 12 imagepipeline.listener | 13 drawee.controller | 14 drawee.drawable | 15 fresco.vito.listener | 16 imagepipeline.image | 17 imagepipeline.memory | 18 fresco.vito.source | 19 imagepipeline.bitmaps | 20 imagepipeline.producers | 21 fresco.urimod | 22 imagepipeline.core.ImagePipelineExperiments | 23 imagepipeline.core.ImagePipelineConfig | 24 imagepipeline.core | 25 imagepipeline.request | 26 drawee.view | 27 flipper.plugins.fresco | 28 imagepipeline.decoder | 29 imagepipeline.common | 30 fresco.vito.options | 31 imagepipeline.cache | 32 drawee.backends.pipeline | 33 drawee.span | 34 fresco.vito.core | 35 fresco.animation.bitmap | 36 fresco.vito.core.impl.debug | 37 fresco.vito.litho | 38 fresco.animation.factory | 39 fresco.vito.core.impl | 40 fresco.vito.tools.liveeditor |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 cache.common | ||||||||||||||||||||||||||||||||||||||||
| 2 common.internal | ||||||||||||||||||||||||||||||||||||||||
| 3 common.references | ||||||||||||||||||||||||||||||||||||||||
| 4 drawee.components | ||||||||||||||||||||||||||||||||||||||||
| 5 fresco.ui.common.ControllerListener2 | ||||||||||||||||||||||||||||||||||||||||
| 6 imageformat | ||||||||||||||||||||||||||||||||||||||||
| 7 imagepipeline.transformation | ||||||||||||||||||||||||||||||||||||||||
| 8 cache.disk | 9 | 3 | ||||||||||||||||||||||||||||||||||||||
| 9 common.memory | 2 | |||||||||||||||||||||||||||||||||||||||
| 10 fresco.ui.common | 5 | |||||||||||||||||||||||||||||||||||||||
| 11 imagepipeline.animated.base | 3 | 2 | ||||||||||||||||||||||||||||||||||||||
| 12 imagepipeline.listener | 5 | 1 | ||||||||||||||||||||||||||||||||||||||
| 13 drawee.controller | 2 | 3 | 1 | 5 | ||||||||||||||||||||||||||||||||||||
| 14 drawee.drawable | 1 | |||||||||||||||||||||||||||||||||||||||
| 15 fresco.vito.listener | 3 | |||||||||||||||||||||||||||||||||||||||
| 16 imagepipeline.image | 1 | 9 | 2 | 1 | 2 | 1 | ||||||||||||||||||||||||||||||||||
| 17 imagepipeline.memory | 6 | 12 | ||||||||||||||||||||||||||||||||||||||
| 18 fresco.vito.source | 1 | |||||||||||||||||||||||||||||||||||||||
| 19 imagepipeline.bitmaps | 2 | 1 | 5 | |||||||||||||||||||||||||||||||||||||
| 20 imagepipeline.producers | 13 | 6 | 12 | 2 | 20 | 1 | 38 | 18 | 16 | 1 | 14 | 28 | ||||||||||||||||||||||||||||
| 21 fresco.urimod | 1 | 2 | ||||||||||||||||||||||||||||||||||||||
| 22 imagepipeline.core.ImagePipelineExperiments | 2 | 1 | 2 | 11 | 2 | 4 | ||||||||||||||||||||||||||||||||||
| 23 imagepipeline.core.ImagePipelineConfig | 1 | 1 | 1 | 1 | 7 | 2 | 5 | |||||||||||||||||||||||||||||||||
| 24 imagepipeline.core | 1 | 2 | 5 | 1 | 2 | 4 | 7 | 1 | 3 | 1 | 19 | 2 | 1 | 6 | 1 | 21 | ||||||||||||||||||||||||
| 25 imagepipeline.request | 2 | 2 | 2 | 2 | 2 | 2 | 10 | |||||||||||||||||||||||||||||||||
| 26 drawee.view | 1 | 1 | 1 | 2 | 1 | |||||||||||||||||||||||||||||||||||
| 27 flipper.plugins.fresco | 3 | 2 | 1 | 1 | 1 | 4 | 1 | 1 | 1 | 1 | ||||||||||||||||||||||||||||||
| 28 imagepipeline.decoder | 1 | 2 | 1 | 1 | 10 | 4 | 2 | |||||||||||||||||||||||||||||||||
| 29 imagepipeline.common | 1 | 2 | 2 | |||||||||||||||||||||||||||||||||||||
| 30 fresco.vito.options | 1 | 1 | 3 | |||||||||||||||||||||||||||||||||||||
| 31 imagepipeline.cache | 9 | 6 | 4 | 1 | 7 | 2 | 1 | 3 | ||||||||||||||||||||||||||||||||
| 32 drawee.backends.pipeline | 3 | 9 | 2 | 2 | 7 | 2 | 6 | 1 | 6 | 6 | 3 | 2 | ||||||||||||||||||||||||||||
| 33 drawee.span | 1 | 1 | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||
| 34 fresco.vito.core | 2 | 10 | 1 | 3 | 3 | 3 | 7 | |||||||||||||||||||||||||||||||||
| 35 fresco.animation.bitmap | 2 | 2 | ||||||||||||||||||||||||||||||||||||||
| 36 fresco.vito.core.impl.debug | 9 | 5 | 4 | |||||||||||||||||||||||||||||||||||||
| 37 fresco.vito.litho | 2 | 1 | 2 | 2 | 1 | 2 | 2 | |||||||||||||||||||||||||||||||||
| 38 fresco.animation.factory | 1 | 2 | 2 | 2 | ||||||||||||||||||||||||||||||||||||
| 39 fresco.vito.core.impl | 1 | 6 | 7 | 9 | 5 | 2 | 3 | 3 | 23 | 51 | 7 | |||||||||||||||||||||||||||||
| 40 fresco.vito.tools.liveeditor | 2 | 5 | 9 | 2 | 1 |
8→1 cache.disk uses cache.common✕
- Connections
- 9 pairs of types, where a type in cache.disk uses a type in cache.common.
- The types involved
com.facebook.cache.disk.Builder→com.facebook.cache.common.CacheErrorLoggercom.facebook.cache.disk.Builder→com.facebook.cache.common.CacheEventListenercom.facebook.cache.disk.DiskCacheConfig→com.facebook.cache.common.CacheErrorLoggercom.facebook.cache.disk.DiskCacheConfig→com.facebook.cache.common.CacheEventListenercom.facebook.cache.disk.DynamicDefaultDiskStorage→com.facebook.cache.common.CacheErrorLoggercom.facebook.cache.disk.Inserter→com.facebook.cache.common.WriterCallbackcom.facebook.cache.disk.SettableCacheEvent→com.facebook.cache.common.CacheEventcom.facebook.cache.disk.SettableCacheEvent→com.facebook.cache.common.CacheKeycom.facebook.cache.disk.SettableCacheEvent→com.facebook.cache.common.EvictionReason
- Direction
- cache.disk uses cache.common, so a change to cache.common can break cache.disk, while a change to cache.disk can't break cache.common.
- Position
- Below the diagonal: cache.disk uses a module listed above it, which is the healthy direction.
8→2 cache.disk uses common.internal✕
- Connections
- 3 pairs of types, where a type in cache.disk uses a type in common.internal.
- The types involved
com.facebook.cache.disk.Builder→com.facebook.common.internal.Suppliercom.facebook.cache.disk.DiskCacheConfig→com.facebook.common.internal.Suppliercom.facebook.cache.disk.DynamicDefaultDiskStorage→com.facebook.common.internal.Supplier
- Direction
- cache.disk uses common.internal, so a change to common.internal can break cache.disk, while a change to cache.disk can't break common.internal.
- Position
- Below the diagonal: cache.disk uses a module listed above it, which is the healthy direction.
9→3 common.memory uses common.references✕
- Connections
- 2 pairs of types, where a type in common.memory uses a type in common.references.
- The types involved
com.facebook.common.memory.Pool→com.facebook.common.references.ResourceReleasercom.facebook.common.memory.PooledByteArrayBufferedInputStream→com.facebook.common.references.ResourceReleaser
- Direction
- common.memory uses common.references, so a change to common.references can break common.memory, while a change to common.memory can't break common.references.
- Position
- Below the diagonal: common.memory uses a module listed above it, which is the healthy direction.
10→5 fresco.ui.common uses fresco.ui.common.ControllerListener2✕
- Connections
- 5 pairs of types, where a type in fresco.ui.common uses a type in fresco.ui.common.ControllerListener2.
- The types involved
com.facebook.fresco.ui.common.BaseControllerListener2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.ui.common.ControllerListener2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.ui.common.ForwardingControllerListener2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.ui.common.ImagePerfData→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.ui.common.ImagePerfState→com.facebook.fresco.ui.common.ControllerListener2.Extras
- Direction
- fresco.ui.common uses fresco.ui.common.ControllerListener2, so a change to fresco.ui.common.ControllerListener2 can break fresco.ui.common, while a change to fresco.ui.common can't break fresco.ui.common.ControllerListener2.
- Position
- Below the diagonal: fresco.ui.common uses a module listed above it, which is the healthy direction.
11→3 imagepipeline.animated.base uses common.references✕
- Connections
- 3 pairs of types, where a type in imagepipeline.animated.base uses a type in common.references.
- The types involved
com.facebook.imagepipeline.animated.base.AnimatedDrawableBackend→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.animated.base.AnimatedImageResult→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.animated.base.AnimatedImageResultBuilder→com.facebook.common.references.CloseableReference
- Direction
- imagepipeline.animated.base uses common.references, so a change to common.references can break imagepipeline.animated.base, while a change to imagepipeline.animated.base can't break common.references.
- Position
- Below the diagonal: imagepipeline.animated.base uses a module listed above it, which is the healthy direction.
11→7 imagepipeline.animated.base uses imagepipeline.transformation✕
- Connections
- 2 pairs of types, where a type in imagepipeline.animated.base uses a type in imagepipeline.transformation.
- The types involved
com.facebook.imagepipeline.animated.base.AnimatedImageResult→com.facebook.imagepipeline.transformation.BitmapTransformationcom.facebook.imagepipeline.animated.base.AnimatedImageResultBuilder→com.facebook.imagepipeline.transformation.BitmapTransformation
- Direction
- imagepipeline.animated.base uses imagepipeline.transformation, so a change to imagepipeline.transformation can break imagepipeline.animated.base, while a change to imagepipeline.animated.base can't break imagepipeline.transformation.
- Position
- Below the diagonal: imagepipeline.animated.base uses a module listed above it, which is the healthy direction.
12→20 imagepipeline.listener uses imagepipeline.producers part of a loop✕
- Connections
- 5 pairs of types, where a type in imagepipeline.listener uses a type in imagepipeline.producers.
- The types involved
com.facebook.imagepipeline.listener.BaseRequestListener2→com.facebook.imagepipeline.producers.ProducerContextcom.facebook.imagepipeline.listener.ForwardingRequestListener2→com.facebook.imagepipeline.producers.ProducerContextcom.facebook.imagepipeline.listener.RequestListener→com.facebook.imagepipeline.producers.ProducerListenercom.facebook.imagepipeline.listener.RequestListener2→com.facebook.imagepipeline.producers.ProducerContextcom.facebook.imagepipeline.listener.RequestListener2→com.facebook.imagepipeline.producers.ProducerListener2
- Direction
- imagepipeline.listener uses imagepipeline.producers, so a change to imagepipeline.producers can break imagepipeline.listener, while a change to imagepipeline.listener can't break imagepipeline.producers.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
12→25 imagepipeline.listener uses imagepipeline.request part of a loop✕
- Connections
- 1 pair of types, where a type in imagepipeline.listener uses a type in imagepipeline.request.
- The types involved
com.facebook.imagepipeline.listener.RequestListener→com.facebook.imagepipeline.request.ImageRequest
- Direction
- imagepipeline.listener uses imagepipeline.request, so a change to imagepipeline.request can break imagepipeline.listener, while a change to imagepipeline.listener can't break imagepipeline.request.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
13→2 drawee.controller uses common.internal✕
- Connections
- 2 pairs of types, where a type in drawee.controller uses a type in common.internal.
- The types involved
com.facebook.drawee.controller.2→com.facebook.common.internal.Suppliercom.facebook.drawee.controller.AbstractDraweeControllerBuilder→com.facebook.common.internal.Supplier
- Direction
- drawee.controller uses common.internal, so a change to common.internal can break drawee.controller, while a change to drawee.controller can't break common.internal.
- Position
- Below the diagonal: drawee.controller uses a module listed above it, which is the healthy direction.
13→4 drawee.controller uses drawee.components✕
- Connections
- 3 pairs of types, where a type in drawee.controller uses a type in drawee.components.
- The types involved
com.facebook.drawee.controller.AbstractDraweeController→com.facebook.drawee.components.DeferredReleasercom.facebook.drawee.controller.AbstractDraweeController→com.facebook.drawee.components.DraweeEventTrackercom.facebook.drawee.controller.AbstractDraweeController→com.facebook.drawee.components.RetryManager
- Direction
- drawee.controller uses drawee.components, so a change to drawee.components can break drawee.controller, while a change to drawee.controller can't break drawee.components.
- Position
- Below the diagonal: drawee.controller uses a module listed above it, which is the healthy direction.
13→5 drawee.controller uses fresco.ui.common.ControllerListener2✕
- Connections
- 1 pair of types, where a type in drawee.controller uses a type in fresco.ui.common.ControllerListener2.
- The types involved
com.facebook.drawee.controller.AbstractDraweeController→com.facebook.fresco.ui.common.ControllerListener2.Extras
- Direction
- drawee.controller uses fresco.ui.common.ControllerListener2, so a change to fresco.ui.common.ControllerListener2 can break drawee.controller, while a change to drawee.controller can't break fresco.ui.common.ControllerListener2.
- Position
- Below the diagonal: drawee.controller uses a module listed above it, which is the healthy direction.
13→10 drawee.controller uses fresco.ui.common✕
- Connections
- 5 pairs of types, where a type in drawee.controller uses a type in fresco.ui.common.
- The types involved
com.facebook.drawee.controller.AbstractDraweeController→com.facebook.fresco.ui.common.ControllerListener2com.facebook.drawee.controller.AbstractDraweeController→com.facebook.fresco.ui.common.ForwardingControllerListener2com.facebook.drawee.controller.AbstractDraweeControllerBuilder→com.facebook.fresco.ui.common.ControllerListener2com.facebook.drawee.controller.ForwardingControllerListener→com.facebook.fresco.ui.common.DimensionsInfocom.facebook.drawee.controller.ForwardingControllerListener→com.facebook.fresco.ui.common.OnDrawControllerListener
- Direction
- drawee.controller uses fresco.ui.common, so a change to fresco.ui.common can break drawee.controller, while a change to drawee.controller can't break fresco.ui.common.
- Position
- Below the diagonal: drawee.controller uses a module listed above it, which is the healthy direction.
14→10 drawee.drawable uses fresco.ui.common✕
- Connections
- 1 pair of types, where a type in drawee.drawable uses a type in fresco.ui.common.
- The types involved
com.facebook.drawee.drawable.FadeDrawable→com.facebook.fresco.ui.common.OnFadeListener
- Direction
- drawee.drawable uses fresco.ui.common, so a change to fresco.ui.common can break drawee.drawable, while a change to drawee.drawable can't break fresco.ui.common.
- Position
- Below the diagonal: drawee.drawable uses a module listed above it, which is the healthy direction.
15→10 fresco.vito.listener uses fresco.ui.common✕
- Connections
- 3 pairs of types, where a type in fresco.vito.listener uses a type in fresco.ui.common.
- The types involved
com.facebook.fresco.vito.listener.BaseImageListener→com.facebook.fresco.ui.common.DimensionsInfocom.facebook.fresco.vito.listener.ForwardingImageListener→com.facebook.fresco.ui.common.DimensionsInfocom.facebook.fresco.vito.listener.ImageListener→com.facebook.fresco.ui.common.OnDrawControllerListener
- Direction
- fresco.vito.listener uses fresco.ui.common, so a change to fresco.ui.common can break fresco.vito.listener, while a change to fresco.vito.listener can't break fresco.ui.common.
- Position
- Below the diagonal: fresco.vito.listener uses a module listed above it, which is the healthy direction.
16→2 imagepipeline.image uses common.internal✕
- Connections
- 1 pair of types, where a type in imagepipeline.image uses a type in common.internal.
- The types involved
com.facebook.imagepipeline.image.EncodedImage→com.facebook.common.internal.Supplier
- Direction
- imagepipeline.image uses common.internal, so a change to common.internal can break imagepipeline.image, while a change to imagepipeline.image can't break common.internal.
- Position
- Below the diagonal: imagepipeline.image uses a module listed above it, which is the healthy direction.
16→3 imagepipeline.image uses common.references✕
- Connections
- 9 pairs of types, where a type in imagepipeline.image uses a type in common.references.
- The types involved
com.facebook.imagepipeline.image.BaseCloseableStaticBitmap→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.image.BaseCloseableStaticBitmap→com.facebook.common.references.ResourceReleasercom.facebook.imagepipeline.image.CloseableImage→com.facebook.common.references.HasBitmapcom.facebook.imagepipeline.image.CloseableStaticBitmap→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.image.CloseableStaticBitmap→com.facebook.common.references.ResourceReleasercom.facebook.imagepipeline.image.DefaultCloseableStaticBitmap→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.image.DefaultCloseableStaticBitmap→com.facebook.common.references.ResourceReleasercom.facebook.imagepipeline.image.EncodedImage→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.image.EncodedImage→com.facebook.common.references.SharedReference
- Direction
- imagepipeline.image uses common.references, so a change to common.references can break imagepipeline.image, while a change to imagepipeline.image can't break common.references.
- Position
- Below the diagonal: imagepipeline.image uses a module listed above it, which is the healthy direction.
16→6 imagepipeline.image uses imageformat✕
- Connections
- 2 pairs of types, where a type in imagepipeline.image uses a type in imageformat.
- The types involved
com.facebook.imagepipeline.image.EncodedImage→com.facebook.imageformat.ImageFormatcom.facebook.imagepipeline.image.EncodedImageDimensionsDecoderRegistry→com.facebook.imageformat.ImageFormat
- Direction
- imagepipeline.image uses imageformat, so a change to imageformat can break imagepipeline.image, while a change to imagepipeline.image can't break imageformat.
- Position
- Below the diagonal: imagepipeline.image uses a module listed above it, which is the healthy direction.
16→9 imagepipeline.image uses common.memory✕
- Connections
- 1 pair of types, where a type in imagepipeline.image uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.image.EncodedImage→com.facebook.common.memory.PooledByteBuffer
- Direction
- imagepipeline.image uses common.memory, so a change to common.memory can break imagepipeline.image, while a change to imagepipeline.image can't break common.memory.
- Position
- Below the diagonal: imagepipeline.image uses a module listed above it, which is the healthy direction.
16→11 imagepipeline.image uses imagepipeline.animated.base✕
- Connections
- 2 pairs of types, where a type in imagepipeline.image uses a type in imagepipeline.animated.base.
- The types involved
com.facebook.imagepipeline.image.CloseableAnimatedImage→com.facebook.imagepipeline.animated.base.AnimatedImagecom.facebook.imagepipeline.image.CloseableAnimatedImage→com.facebook.imagepipeline.animated.base.AnimatedImageResult
- Direction
- imagepipeline.image uses imagepipeline.animated.base, so a change to imagepipeline.animated.base can break imagepipeline.image, while a change to imagepipeline.image can't break imagepipeline.animated.base.
- Position
- Below the diagonal: imagepipeline.image uses a module listed above it, which is the healthy direction.
16→29 imagepipeline.image uses imagepipeline.common part of a loop✕
- Connections
- 1 pair of types, where a type in imagepipeline.image uses a type in imagepipeline.common.
- The types involved
com.facebook.imagepipeline.image.EncodedImage→com.facebook.imagepipeline.common.BytesRange
- Direction
- imagepipeline.image uses imagepipeline.common, so a change to imagepipeline.common can break imagepipeline.image, while a change to imagepipeline.image can't break imagepipeline.common.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
17→3 imagepipeline.memory uses common.references✕
- Connections
- 6 pairs of types, where a type in imagepipeline.memory uses a type in common.references.
- The types involved
com.facebook.imagepipeline.memory.1→com.facebook.common.references.ResourceReleasercom.facebook.imagepipeline.memory.BitmapCounter→com.facebook.common.references.ResourceReleasercom.facebook.imagepipeline.memory.OOMSoftReferenceBucket→com.facebook.common.references.OOMSoftReferencecom.facebook.imagepipeline.memory.SharedByteArray→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.memory.SharedByteArray→com.facebook.common.references.OOMSoftReferencecom.facebook.imagepipeline.memory.SharedByteArray→com.facebook.common.references.ResourceReleaser
- Direction
- imagepipeline.memory uses common.references, so a change to common.references can break imagepipeline.memory, while a change to imagepipeline.memory can't break common.references.
- Position
- Below the diagonal: imagepipeline.memory uses a module listed above it, which is the healthy direction.
17→9 imagepipeline.memory uses common.memory✕
- Connections
- 12 pairs of types, where a type in imagepipeline.memory uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.memory.BasePool→com.facebook.common.memory.Poolcom.facebook.imagepipeline.memory.BitmapPool→com.facebook.common.memory.Poolcom.facebook.imagepipeline.memory.GenericByteArrayPool→com.facebook.common.memory.ByteArrayPoolcom.facebook.imagepipeline.memory.LruBitmapPool→com.facebook.common.memory.MemoryTrimTypecom.facebook.imagepipeline.memory.LruBitmapPool→com.facebook.common.memory.MemoryTrimmableRegistrycom.facebook.imagepipeline.memory.MemoryChunkPool→com.facebook.common.memory.MemoryTrimmableRegistrycom.facebook.imagepipeline.memory.MemoryPooledByteBuffer→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.memory.MemoryPooledByteBufferOutputStream→com.facebook.common.memory.PooledByteBufferOutputStreamcom.facebook.imagepipeline.memory.SharedByteArray→com.facebook.common.memory.MemoryTrimTypecom.facebook.imagepipeline.memory.SharedByteArray→com.facebook.common.memory.MemoryTrimmablecom.facebook.imagepipeline.memory.SharedByteArray→com.facebook.common.memory.MemoryTrimmableRegistry
- Direction
- imagepipeline.memory uses common.memory, so a change to common.memory can break imagepipeline.memory, while a change to imagepipeline.memory can't break common.memory.
- Position
- Below the diagonal: imagepipeline.memory uses a module listed above it, which is the healthy direction.
18→14 fresco.vito.source uses drawee.drawable✕
- Connections
- 1 pair of types, where a type in fresco.vito.source uses a type in drawee.drawable.
- The types involved
com.facebook.fresco.vito.source.SmartImageSource→com.facebook.drawee.drawable.SizingHint
- Direction
- fresco.vito.source uses drawee.drawable, so a change to drawee.drawable can break fresco.vito.source, while a change to fresco.vito.source can't break drawee.drawable.
- Position
- Below the diagonal: fresco.vito.source uses a module listed above it, which is the healthy direction.
19→3 imagepipeline.bitmaps uses common.references✕
- Connections
- 2 pairs of types, where a type in imagepipeline.bitmaps uses a type in common.references.
- The types involved
com.facebook.imagepipeline.bitmaps.PlatformBitmapFactory→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.bitmaps.SimpleBitmapReleaser→com.facebook.common.references.ResourceReleaser
- Direction
- imagepipeline.bitmaps uses common.references, so a change to common.references can break imagepipeline.bitmaps, while a change to imagepipeline.bitmaps can't break common.references.
- Position
- Below the diagonal: imagepipeline.bitmaps uses a module listed above it, which is the healthy direction.
19→9 imagepipeline.bitmaps uses common.memory✕
- Connections
- 1 pair of types, where a type in imagepipeline.bitmaps uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.bitmaps.EmptyJpegGenerator→com.facebook.common.memory.PooledByteBuffer
- Direction
- imagepipeline.bitmaps uses common.memory, so a change to common.memory can break imagepipeline.bitmaps, while a change to imagepipeline.bitmaps can't break common.memory.
- Position
- Below the diagonal: imagepipeline.bitmaps uses a module listed above it, which is the healthy direction.
19→17 imagepipeline.bitmaps uses imagepipeline.memory✕
- Connections
- 5 pairs of types, where a type in imagepipeline.bitmaps uses a type in imagepipeline.memory.
- The types involved
com.facebook.imagepipeline.bitmaps.Api31BitmapFactory→com.facebook.imagepipeline.memory.BitmapPoolcom.facebook.imagepipeline.bitmaps.ArtBitmapFactory→com.facebook.imagepipeline.memory.BitmapPoolcom.facebook.imagepipeline.bitmaps.HoneycombBitmapCreator→com.facebook.imagepipeline.memory.FlexByteArrayPoolcom.facebook.imagepipeline.bitmaps.HoneycombBitmapCreator→com.facebook.imagepipeline.memory.PoolFactorycom.facebook.imagepipeline.bitmaps.PlatformBitmapFactoryProvider→com.facebook.imagepipeline.memory.PoolFactory
- Direction
- imagepipeline.bitmaps uses imagepipeline.memory, so a change to imagepipeline.memory can break imagepipeline.bitmaps, while a change to imagepipeline.bitmaps can't break imagepipeline.memory.
- Position
- Below the diagonal: imagepipeline.bitmaps uses a module listed above it, which is the healthy direction.
20→1 imagepipeline.producers uses cache.common✕
- Connections
- 13 pairs of types, where a type in imagepipeline.producers uses a type in cache.common.
- The types involved
com.facebook.imagepipeline.producers.BitmapMemoryCacheKeyMultiplexProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.BitmapMemoryCacheProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.CachedPostprocessorConsumer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.DiskCacheReadProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.EncodedCacheKeyMultiplexProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.EncodedMemoryCacheConsumer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.EncodedMemoryCacheProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.EncodedProbeProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.PartialDiskCacheConsumer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.PostprocessedBitmapMemoryCacheProducer→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.producers.ProbeConsumer→com.facebook.cache.common.CacheKey
- Direction
- imagepipeline.producers uses cache.common, so a change to cache.common can break imagepipeline.producers, while a change to imagepipeline.producers can't break cache.common.
- Position
- Below the diagonal: imagepipeline.producers uses a module listed above it, which is the healthy direction.
20→2 imagepipeline.producers uses common.internal✕
- Connections
- 6 pairs of types, where a type in imagepipeline.producers uses a type in common.internal.
- The types involved
com.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.producers.DiskCacheReadProducer→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.producers.EncodedProbeProducer→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.producers.PartialDiskCacheConsumer→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.producers.ProbeConsumer→com.facebook.common.internal.Supplier
- Direction
- imagepipeline.producers uses common.internal, so a change to common.internal can break imagepipeline.producers, while a change to imagepipeline.producers can't break common.internal.
- Position
- Below the diagonal: imagepipeline.producers uses a module listed above it, which is the healthy direction.
20→3 imagepipeline.producers uses common.references✕
- Connections
- 12 pairs of types, where a type in imagepipeline.producers uses a type in common.references.
- The types involved
com.facebook.imagepipeline.producers.1→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.BitmapMemoryCacheKeyMultiplexProducer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.BitmapMemoryCacheProducer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.BitmapPrepareConsumer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.BitmapPrepareProducer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.CachedPostprocessorConsumer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.CustomProducerSequenceFactory→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.LocalThumbnailBitmapSdk29Producer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.LocalVideoThumbnailProducer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.PostprocessedBitmapMemoryCacheProducer→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.producers.ProbeConsumer→com.facebook.common.references.CloseableReference
- Direction
- imagepipeline.producers uses common.references, so a change to common.references can break imagepipeline.producers, while a change to imagepipeline.producers can't break common.references.
- Position
- Below the diagonal: imagepipeline.producers uses a module listed above it, which is the healthy direction.
20→6 imagepipeline.producers uses imageformat✕
- Connections
- 2 pairs of types, where a type in imagepipeline.producers uses a type in imageformat.
- The types involved
com.facebook.imagepipeline.producers.JobScheduler→com.facebook.imageformat.ImageFormatcom.facebook.imagepipeline.producers.TransformingConsumer→com.facebook.imageformat.ImageFormat
- Direction
- imagepipeline.producers uses imageformat, so a change to imageformat can break imagepipeline.producers, while a change to imagepipeline.producers can't break imageformat.
- Position
- Below the diagonal: imagepipeline.producers uses a module listed above it, which is the healthy direction.
20→9 imagepipeline.producers uses common.memory✕
- Connections
- 20 pairs of types, where a type in imagepipeline.producers uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.producers.CustomProducerSequenceFactory→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.producers.DataFetchProducer→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.producers.EncodedMemoryCacheConsumer→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.producers.EncodedMemoryCacheProducer→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.producers.LocalExifThumbnailProducer→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.producers.LocalExifThumbnailProducer→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.producers.LocalFetchProducer→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.producers.NetworkFetchProducer→com.facebook.common.memory.ByteArrayPoolcom.facebook.imagepipeline.producers.NetworkFetchProducer→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.producers.NetworkFetchProducer→com.facebook.common.memory.PooledByteBufferOutputStreamcom.facebook.imagepipeline.producers.PartialDiskCacheConsumer→com.facebook.common.memory.ByteArrayPoolcom.facebook.imagepipeline.producers.PartialDiskCacheConsumer→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.producers.PartialDiskCacheConsumer→com.facebook.common.memory.PooledByteBufferOutputStreamcom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.common.memory.ByteArrayPoolcom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.common.memory.PooledByteBufferFactorycom.facebook.imagepipeline.producers.ProbeConsumer→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.producers.RemoveImageTransformMetaDataProducer→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.producers.ResizeAndRotateProducer→com.facebook.common.memory.PooledByteBufferFactory
- Direction
- imagepipeline.producers uses common.memory, so a change to common.memory can break imagepipeline.producers, while a change to imagepipeline.producers can't break common.memory.
- Position
- Below the diagonal: imagepipeline.producers uses a module listed above it, which is the healthy direction.
20→12 imagepipeline.producers uses imagepipeline.listener✕
- Connections
- 1 pair of types, where a type in imagepipeline.producers uses a type in imagepipeline.listener.
- The types involved
com.facebook.imagepipeline.producers.InternalRequestListener→com.facebook.imagepipeline.listener.RequestListener2
- Direction
- imagepipeline.producers uses imagepipeline.listener, so a change to imagepipeline.listener can break imagepipeline.producers, while a change to imagepipeline.producers can't break imagepipeline.listener.
- Position
- Below the diagonal: imagepipeline.producers uses a module listed above it, which is the healthy direction.
20→16 imagepipeline.producers uses imagepipeline.image✕
- Connections
- 38 pairs of types, where a type in imagepipeline.producers uses a type in imagepipeline.image. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
com.facebook.imagepipeline.producers.1→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.AddImageTransformMetaDataConsumer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.AddImageTransformMetaDataProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.BitmapMemoryCacheKeyMultiplexProducer→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.BitmapMemoryCacheProducer→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.BitmapMemoryCacheProducer→com.facebook.imagepipeline.image.HasImageMetadatacom.facebook.imagepipeline.producers.BitmapPrepareConsumer→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.BitmapPrepareProducer→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.BranchOnSeparateImagesProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.CachedPostprocessorConsumer→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.CustomProducerSequenceFactory→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.producers.DataFetchProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.DiskCacheReadProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.EncodedCacheKeyMultiplexProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.EncodedMemoryCacheConsumer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.EncodedMemoryCacheProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.EncodedProbeProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.HttpUrlConnectionNetworkFetchState→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.HttpUrlConnectionNetworkFetcher→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.JobRunnable→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.JobScheduler→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.LocalExifThumbnailProducer→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.producers.LocalFetchProducer→com.facebook.imagepipeline.image.EncodedImage
- Direction
- imagepipeline.producers uses imagepipeline.image, so a change to imagepipeline.image can break imagepipeline.producers, while a change to imagepipeline.producers can't break imagepipeline.image.
- Position
- Below the diagonal: imagepipeline.producers uses a module listed above it, which is the healthy direction.
20→24 imagepipeline.producers uses imagepipeline.core part of a loop✕
- Connections
- 18 pairs of types, where a type in imagepipeline.producers uses a type in imagepipeline.core.
- The types involved
com.facebook.imagepipeline.producers.BaseProducerContext→com.facebook.imagepipeline.core.ImagePipelineConfigInterfacecom.facebook.imagepipeline.producers.BitmapMemoryCacheKeyMultiplexProducer→com.facebook.imagepipeline.core.ImagePipelineConfigInterfacecom.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.producers.CustomBasicDecodedImageSequenceFactory→com.facebook.imagepipeline.core.ProducerFactorycom.facebook.imagepipeline.producers.CustomBasicDecodedImageSequenceFactory→com.facebook.imagepipeline.core.ProducerSequenceFactorycom.facebook.imagepipeline.producers.CustomProducerSequenceFactory→com.facebook.imagepipeline.core.ProducerFactorycom.facebook.imagepipeline.producers.CustomProducerSequenceFactory→com.facebook.imagepipeline.core.ProducerSequenceFactorycom.facebook.imagepipeline.producers.DecodeProducer→com.facebook.imagepipeline.core.DownsampleModecom.facebook.imagepipeline.producers.DiskCacheReadProducer→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.producers.DiskCacheWriteProducer→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.producers.EncodedCacheKeyMultiplexProducer→com.facebook.imagepipeline.core.ImagePipelineConfigInterfacecom.facebook.imagepipeline.producers.EncodedProbeProducer→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.producers.MultiplexProducer→com.facebook.imagepipeline.core.ImagePipelineConfigInterfacecom.facebook.imagepipeline.producers.PartialDiskCacheConsumer→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.producers.ProbeConsumer→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.producers.ProducerContext→com.facebook.imagepipeline.core.ImagePipelineConfigInterfacecom.facebook.imagepipeline.producers.SettableProducerContext→com.facebook.imagepipeline.core.ImagePipelineConfigInterface
- Direction
- imagepipeline.producers uses imagepipeline.core, so a change to imagepipeline.core can break imagepipeline.producers, while a change to imagepipeline.producers can't break imagepipeline.core.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
20→25 imagepipeline.producers uses imagepipeline.request part of a loop✕
- Connections
- 16 pairs of types, where a type in imagepipeline.producers uses a type in imagepipeline.request.
- The types involved
com.facebook.imagepipeline.producers.BaseProducerContext→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.BaseProducerContext→com.facebook.imagepipeline.request.RequestLevelcom.facebook.imagepipeline.producers.BitmapMemoryCacheKeyMultiplexProducer→com.facebook.imagepipeline.request.RequestLevelcom.facebook.imagepipeline.producers.CustomProducerSequenceFactory→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.DataFetchProducer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.DiskCacheReadProducer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.EncodedCacheKeyMultiplexProducer→com.facebook.imagepipeline.request.RequestLevelcom.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.LocalFetchProducer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.LocalThumbnailBitmapSdk29Producer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.LocalVideoThumbnailProducer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.PartialDiskCacheConsumer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.ResizeAndRotateProducer→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.SettableProducerContext→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.producers.SettableProducerContext→com.facebook.imagepipeline.request.RequestLevel
- Direction
- imagepipeline.producers uses imagepipeline.request, so a change to imagepipeline.request can break imagepipeline.producers, while a change to imagepipeline.producers can't break imagepipeline.request.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
20→28 imagepipeline.producers uses imagepipeline.decoder part of a loop✕
- Connections
- 1 pair of types, where a type in imagepipeline.producers uses a type in imagepipeline.decoder.
- The types involved
com.facebook.imagepipeline.producers.DecodeProducer→com.facebook.imagepipeline.decoder.ImageDecoder
- Direction
- imagepipeline.producers uses imagepipeline.decoder, so a change to imagepipeline.decoder can break imagepipeline.producers, while a change to imagepipeline.producers can't break imagepipeline.decoder.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
20→29 imagepipeline.producers uses imagepipeline.common part of a loop✕
- Connections
- 14 pairs of types, where a type in imagepipeline.producers uses a type in imagepipeline.common.
- The types involved
com.facebook.imagepipeline.producers.BaseProducerContext→com.facebook.imagepipeline.common.Prioritycom.facebook.imagepipeline.producers.FetchState→com.facebook.imagepipeline.common.BytesRangecom.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.producers.LocalExifThumbnailProducer→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.producers.Multiplexer→com.facebook.imagepipeline.common.Prioritycom.facebook.imagepipeline.producers.NetworkFetchProducer→com.facebook.imagepipeline.common.BytesRangecom.facebook.imagepipeline.producers.ProducerContext→com.facebook.imagepipeline.common.Prioritycom.facebook.imagepipeline.producers.ResizeAndRotateProducer→com.facebook.imagepipeline.common.RotationOptionscom.facebook.imagepipeline.producers.SettableProducerContext→com.facebook.imagepipeline.common.Prioritycom.facebook.imagepipeline.producers.ThumbnailBranchProducer→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.producers.ThumbnailConsumer→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.producers.ThumbnailProducer→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.producers.ThumbnailSizeChecker→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.producers.TransformingConsumer→com.facebook.imagepipeline.common.ResizeOptions
- Direction
- imagepipeline.producers uses imagepipeline.common, so a change to imagepipeline.common can break imagepipeline.producers, while a change to imagepipeline.producers can't break imagepipeline.common.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
20→31 imagepipeline.producers uses imagepipeline.cache part of a loop✕
- Connections
- 28 pairs of types, where a type in imagepipeline.producers uses a type in imagepipeline.cache. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
com.facebook.imagepipeline.producers.BitmapMemoryCacheGetProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.BitmapMemoryCacheGetProducer→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.producers.BitmapMemoryCacheKeyMultiplexProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.BitmapMemoryCacheProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.BitmapMemoryCacheProducer→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.imagepipeline.cache.BoundedLinkedHashSetcom.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.BitmapProbeProducer→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.producers.CachedPostprocessorConsumer→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.producers.DiskCacheDecision→com.facebook.imagepipeline.cache.BufferedDiskCachecom.facebook.imagepipeline.producers.DiskCacheReadProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.DiskCacheWriteProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.EncodedCacheKeyMultiplexProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.EncodedMemoryCacheConsumer→com.facebook.imagepipeline.cache.BoundedLinkedHashMapcom.facebook.imagepipeline.producers.EncodedMemoryCacheConsumer→com.facebook.imagepipeline.cache.UnifiedEncodedMemoryCachecom.facebook.imagepipeline.producers.EncodedMemoryCacheProducer→com.facebook.imagepipeline.cache.BoundedLinkedHashMapcom.facebook.imagepipeline.producers.EncodedMemoryCacheProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.EncodedMemoryCacheProducer→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.producers.EncodedMemoryCacheProducer→com.facebook.imagepipeline.cache.UnifiedEncodedMemoryCachecom.facebook.imagepipeline.producers.EncodedProbeProducer→com.facebook.imagepipeline.cache.BoundedLinkedHashSetcom.facebook.imagepipeline.producers.EncodedProbeProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.imagepipeline.cache.BufferedDiskCachecom.facebook.imagepipeline.producers.PartialDiskCacheProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.PostprocessedBitmapMemoryCacheProducer→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.producers.PostprocessedBitmapMemoryCacheProducer→com.facebook.imagepipeline.cache.MemoryCache
- Direction
- imagepipeline.producers uses imagepipeline.cache, so a change to imagepipeline.cache can break imagepipeline.producers, while a change to imagepipeline.producers can't break imagepipeline.cache.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
21→14 fresco.urimod uses drawee.drawable✕
- Connections
- 1 pair of types, where a type in fresco.urimod uses a type in drawee.drawable.
- The types involved
com.facebook.fresco.urimod.UriModifierInterface→com.facebook.drawee.drawable.Viewport
- Direction
- fresco.urimod uses drawee.drawable, so a change to drawee.drawable can break fresco.urimod, while a change to fresco.urimod can't break drawee.drawable.
- Position
- Below the diagonal: fresco.urimod uses a module listed above it, which is the healthy direction.
21→18 fresco.urimod uses fresco.vito.source✕
- Connections
- 2 pairs of types, where a type in fresco.urimod uses a type in fresco.vito.source.
- The types involved
com.facebook.fresco.urimod.NopUriModifier→com.facebook.fresco.vito.source.UriImageSourcecom.facebook.fresco.urimod.UriModifierInterface→com.facebook.fresco.vito.source.UriImageSource
- Direction
- fresco.urimod uses fresco.vito.source, so a change to fresco.vito.source can break fresco.urimod, while a change to fresco.urimod can't break fresco.vito.source.
- Position
- Below the diagonal: fresco.urimod uses a module listed above it, which is the healthy direction.
22→9 imagepipeline.core.ImagePipelineExperiments uses common.memory✕
- Connections
- 2 pairs of types, where a type in imagepipeline.core.ImagePipelineExperiments uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.common.memory.PooledByteBuffer
- Direction
- imagepipeline.core.ImagePipelineExperiments uses common.memory, so a change to common.memory can break imagepipeline.core.ImagePipelineExperiments, while a change to imagepipeline.core.ImagePipelineExperiments can't break common.memory.
- Position
- Below the diagonal: imagepipeline.core.ImagePipelineExperiments uses a module listed above it, which is the healthy direction.
22→20 imagepipeline.core.ImagePipelineExperiments uses imagepipeline.producers✕
- Connections
- 1 pair of types, where a type in imagepipeline.core.ImagePipelineExperiments uses a type in imagepipeline.producers.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineExperiments.Builder→com.facebook.imagepipeline.producers.CustomBasicDecodedImageSequenceFactory
- Direction
- imagepipeline.core.ImagePipelineExperiments uses imagepipeline.producers, so a change to imagepipeline.producers can break imagepipeline.core.ImagePipelineExperiments, while a change to imagepipeline.core.ImagePipelineExperiments can't break imagepipeline.producers.
- Position
- Below the diagonal: imagepipeline.core.ImagePipelineExperiments uses a module listed above it, which is the healthy direction.
22→23 imagepipeline.core.ImagePipelineExperiments uses imagepipeline.core.ImagePipelineConfig part of a loop✕
- Connections
- 2 pairs of types, where a type in imagepipeline.core.ImagePipelineExperiments uses a type in imagepipeline.core.ImagePipelineConfig.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineExperiments.Builder→com.facebook.imagepipeline.core.ImagePipelineConfig.Buildercom.facebook.imagepipeline.core.ImagePipelineExperiments.Companion→com.facebook.imagepipeline.core.ImagePipelineConfig.Builder
- Direction
- imagepipeline.core.ImagePipelineExperiments uses imagepipeline.core.ImagePipelineConfig, so a change to imagepipeline.core.ImagePipelineConfig can break imagepipeline.core.ImagePipelineExperiments, while a change to imagepipeline.core.ImagePipelineExperiments can't break imagepipeline.core.ImagePipelineConfig.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→24 imagepipeline.core.ImagePipelineExperiments uses imagepipeline.core part of a loop✕
- Connections
- 11 pairs of types, where a type in imagepipeline.core.ImagePipelineExperiments uses a type in imagepipeline.core.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineExperiments.Builder→com.facebook.imagepipeline.core.ImagePipelineExperimentscom.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.core.DownsampleModecom.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.core.ExecutorSuppliercom.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.core.ImagePipelineConfigInterfacecom.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.core.ProducerFactorycom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.core.DownsampleModecom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.core.ExecutorSuppliercom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.core.ImagePipelineConfigInterfacecom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.core.ProducerFactory
- Direction
- imagepipeline.core.ImagePipelineExperiments uses imagepipeline.core, so a change to imagepipeline.core can break imagepipeline.core.ImagePipelineExperiments, while a change to imagepipeline.core.ImagePipelineExperiments can't break imagepipeline.core.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→28 imagepipeline.core.ImagePipelineExperiments uses imagepipeline.decoder part of a loop✕
- Connections
- 2 pairs of types, where a type in imagepipeline.core.ImagePipelineExperiments uses a type in imagepipeline.decoder.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.decoder.ImageDecodercom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.decoder.ImageDecoder
- Direction
- imagepipeline.core.ImagePipelineExperiments uses imagepipeline.decoder, so a change to imagepipeline.decoder can break imagepipeline.core.ImagePipelineExperiments, while a change to imagepipeline.core.ImagePipelineExperiments can't break imagepipeline.decoder.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→31 imagepipeline.core.ImagePipelineExperiments uses imagepipeline.cache part of a loop✕
- Connections
- 4 pairs of types, where a type in imagepipeline.core.ImagePipelineExperiments uses a type in imagepipeline.cache.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.core.ImagePipelineExperiments.DefaultProducerFactoryMethod→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod→com.facebook.imagepipeline.cache.MemoryCache
- Direction
- imagepipeline.core.ImagePipelineExperiments uses imagepipeline.cache, so a change to imagepipeline.cache can break imagepipeline.core.ImagePipelineExperiments, while a change to imagepipeline.core.ImagePipelineExperiments can't break imagepipeline.cache.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→7 imagepipeline.core.ImagePipelineConfig uses imagepipeline.transformation✕
- Connections
- 1 pair of types, where a type in imagepipeline.core.ImagePipelineConfig uses a type in imagepipeline.transformation.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.transformation.BitmapTransformation
- Direction
- imagepipeline.core.ImagePipelineConfig uses imagepipeline.transformation, so a change to imagepipeline.transformation can break imagepipeline.core.ImagePipelineConfig, while a change to imagepipeline.core.ImagePipelineConfig can't break imagepipeline.transformation.
- Position
- Below the diagonal: imagepipeline.core.ImagePipelineConfig uses a module listed above it, which is the healthy direction.
23→9 imagepipeline.core.ImagePipelineConfig uses common.memory✕
- Connections
- 1 pair of types, where a type in imagepipeline.core.ImagePipelineConfig uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.common.memory.PooledByteBuffer
- Direction
- imagepipeline.core.ImagePipelineConfig uses common.memory, so a change to common.memory can break imagepipeline.core.ImagePipelineConfig, while a change to imagepipeline.core.ImagePipelineConfig can't break common.memory.
- Position
- Below the diagonal: imagepipeline.core.ImagePipelineConfig uses a module listed above it, which is the healthy direction.
23→17 imagepipeline.core.ImagePipelineConfig uses imagepipeline.memory✕
- Connections
- 1 pair of types, where a type in imagepipeline.core.ImagePipelineConfig uses a type in imagepipeline.memory.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.memory.PoolFactory
- Direction
- imagepipeline.core.ImagePipelineConfig uses imagepipeline.memory, so a change to imagepipeline.memory can break imagepipeline.core.ImagePipelineConfig, while a change to imagepipeline.core.ImagePipelineConfig can't break imagepipeline.memory.
- Position
- Below the diagonal: imagepipeline.core.ImagePipelineConfig uses a module listed above it, which is the healthy direction.
23→22 imagepipeline.core.ImagePipelineConfig uses imagepipeline.core.ImagePipelineExperiments✕
- Connections
- 1 pair of types, where a type in imagepipeline.core.ImagePipelineConfig uses a type in imagepipeline.core.ImagePipelineExperiments.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.core.ImagePipelineExperiments.Builder
- Direction
- imagepipeline.core.ImagePipelineConfig uses imagepipeline.core.ImagePipelineExperiments, so a change to imagepipeline.core.ImagePipelineExperiments can break imagepipeline.core.ImagePipelineConfig, while a change to imagepipeline.core.ImagePipelineConfig can't break imagepipeline.core.ImagePipelineExperiments.
- Position
- Below the diagonal: imagepipeline.core.ImagePipelineConfig uses a module listed above it, which is the healthy direction.
23→24 imagepipeline.core.ImagePipelineConfig uses imagepipeline.core part of a loop✕
- Connections
- 7 pairs of types, where a type in imagepipeline.core.ImagePipelineConfig uses a type in imagepipeline.core.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.core.DiskCachesStorecom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.core.DownsampleModecom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.core.ExecutorSuppliercom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.core.FileCacheFactorycom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.core.ImagePipelineConfigcom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.core.ProducerSequenceFactoryInterfacecom.facebook.imagepipeline.core.ImagePipelineConfig.Companion→com.facebook.imagepipeline.core.ImagePipelineExperiments
- Direction
- imagepipeline.core.ImagePipelineConfig uses imagepipeline.core, so a change to imagepipeline.core can break imagepipeline.core.ImagePipelineConfig, while a change to imagepipeline.core.ImagePipelineConfig can't break imagepipeline.core.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→28 imagepipeline.core.ImagePipelineConfig uses imagepipeline.decoder part of a loop✕
- Connections
- 2 pairs of types, where a type in imagepipeline.core.ImagePipelineConfig uses a type in imagepipeline.decoder.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.decoder.ImageDecodercom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.decoder.ImageDecoderConfig
- Direction
- imagepipeline.core.ImagePipelineConfig uses imagepipeline.decoder, so a change to imagepipeline.decoder can break imagepipeline.core.ImagePipelineConfig, while a change to imagepipeline.core.ImagePipelineConfig can't break imagepipeline.decoder.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→31 imagepipeline.core.ImagePipelineConfig uses imagepipeline.cache part of a loop✕
- Connections
- 5 pairs of types, where a type in imagepipeline.core.ImagePipelineConfig uses a type in imagepipeline.cache.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.cache.BitmapMemoryCacheFactorycom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.cache.ImageCacheStatsTrackercom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.core.ImagePipelineConfig.Builder→com.facebook.imagepipeline.cache.MemoryCacheParams
- Direction
- imagepipeline.core.ImagePipelineConfig uses imagepipeline.cache, so a change to imagepipeline.cache can break imagepipeline.core.ImagePipelineConfig, while a change to imagepipeline.core.ImagePipelineConfig can't break imagepipeline.cache.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
24→1 imagepipeline.core uses cache.common✕
- Connections
- 1 pair of types, where a type in imagepipeline.core uses a type in cache.common.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.cache.common.CacheKey
- Direction
- imagepipeline.core uses cache.common, so a change to cache.common can break imagepipeline.core, while a change to imagepipeline.core can't break cache.common.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→2 imagepipeline.core uses common.internal✕
- Connections
- 2 pairs of types, where a type in imagepipeline.core uses a type in common.internal.
- The types involved
com.facebook.imagepipeline.core.DiskCachesStoreFactory→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.common.internal.Supplier
- Direction
- imagepipeline.core uses common.internal, so a change to common.internal can break imagepipeline.core, while a change to imagepipeline.core can't break common.internal.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→3 imagepipeline.core uses common.references✕
- Connections
- 5 pairs of types, where a type in imagepipeline.core uses a type in common.references.
- The types involved
com.facebook.imagepipeline.core.1→com.facebook.common.references.LeakHandlercom.facebook.imagepipeline.core.1→com.facebook.common.references.SharedReferencecom.facebook.imagepipeline.core.CloseableReferenceFactory→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.core.CloseableReferenceFactory→com.facebook.common.references.LeakHandlercom.facebook.imagepipeline.core.CloseableReferenceFactory→com.facebook.common.references.ResourceReleaser
- Direction
- imagepipeline.core uses common.references, so a change to common.references can break imagepipeline.core, while a change to imagepipeline.core can't break common.references.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→6 imagepipeline.core uses imageformat✕
- Connections
- 1 pair of types, where a type in imagepipeline.core uses a type in imageformat.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imageformat.ImageFormat
- Direction
- imagepipeline.core uses imageformat, so a change to imageformat can break imagepipeline.core, while a change to imagepipeline.core can't break imageformat.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→7 imagepipeline.core uses imagepipeline.transformation✕
- Connections
- 2 pairs of types, where a type in imagepipeline.core uses a type in imagepipeline.transformation.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.transformation.BitmapTransformationcom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.transformation.BitmapTransformation
- Direction
- imagepipeline.core uses imagepipeline.transformation, so a change to imagepipeline.transformation can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.transformation.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→8 imagepipeline.core uses cache.disk✕
- Connections
- 4 pairs of types, where a type in imagepipeline.core uses a type in cache.disk.
- The types involved
com.facebook.imagepipeline.core.DiskCachesStore→com.facebook.cache.disk.FileCachecom.facebook.imagepipeline.core.DiskStorageCacheFactory→com.facebook.cache.disk.FileCachecom.facebook.imagepipeline.core.FileCacheFactory→com.facebook.cache.disk.FileCachecom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.cache.disk.FileCache
- Direction
- imagepipeline.core uses cache.disk, so a change to cache.disk can break imagepipeline.core, while a change to imagepipeline.core can't break cache.disk.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→9 imagepipeline.core uses common.memory✕
- Connections
- 7 pairs of types, where a type in imagepipeline.core uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.core.ImagePipeline→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.core.ProducerSequenceFactory→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.core.ProducerSequenceFactoryInterface→com.facebook.common.memory.PooledByteBuffer
- Direction
- imagepipeline.core uses common.memory, so a change to common.memory can break imagepipeline.core, while a change to imagepipeline.core can't break common.memory.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→16 imagepipeline.core uses imagepipeline.image✕
- Connections
- 1 pair of types, where a type in imagepipeline.core uses a type in imagepipeline.image.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imagepipeline.image.CloseableImage
- Direction
- imagepipeline.core uses imagepipeline.image, so a change to imagepipeline.image can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.image.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→17 imagepipeline.core uses imagepipeline.memory✕
- Connections
- 3 pairs of types, where a type in imagepipeline.core uses a type in imagepipeline.memory.
- The types involved
com.facebook.imagepipeline.core.DiskCachesStoreFactory→com.facebook.imagepipeline.memory.PoolFactorycom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.memory.PoolFactorycom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.memory.PoolFactory
- Direction
- imagepipeline.core uses imagepipeline.memory, so a change to imagepipeline.memory can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.memory.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→19 imagepipeline.core uses imagepipeline.bitmaps✕
- Connections
- 1 pair of types, where a type in imagepipeline.core uses a type in imagepipeline.bitmaps.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imagepipeline.bitmaps.PlatformBitmapFactory
- Direction
- imagepipeline.core uses imagepipeline.bitmaps, so a change to imagepipeline.bitmaps can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.bitmaps.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→20 imagepipeline.core uses imagepipeline.producers✕
- Connections
- 19 pairs of types, where a type in imagepipeline.core uses a type in imagepipeline.producers.
- The types involved
com.facebook.imagepipeline.core.ImagePipeline→com.facebook.imagepipeline.producers.Producercom.facebook.imagepipeline.core.ImagePipelineExperiments→com.facebook.imagepipeline.producers.CustomBasicDecodedImageSequenceFactorycom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imagepipeline.producers.ThreadHandoffProducerQueuecom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.BitmapMemoryCacheGetProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.DecodeProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.DelayProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.LocalAssetFetchProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.LocalContentUriFetchProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.LocalFileFetchProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.LocalResourceFetchProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.PostprocessorProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.Producercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.QualifiedResourceFetchProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.ThrottlingProducercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.producers.ThumbnailProducercom.facebook.imagepipeline.core.ProducerSequenceFactory→com.facebook.imagepipeline.producers.CustomBasicDecodedImageSequenceFactorycom.facebook.imagepipeline.core.ProducerSequenceFactory→com.facebook.imagepipeline.producers.Producercom.facebook.imagepipeline.core.ProducerSequenceFactory→com.facebook.imagepipeline.producers.ThumbnailProducercom.facebook.imagepipeline.core.ProducerSequenceFactoryInterface→com.facebook.imagepipeline.producers.Producer
- Direction
- imagepipeline.core uses imagepipeline.producers, so a change to imagepipeline.producers can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.producers.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→22 imagepipeline.core uses imagepipeline.core.ImagePipelineExperiments✕
- Connections
- 2 pairs of types, where a type in imagepipeline.core uses a type in imagepipeline.core.ImagePipelineExperiments.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineExperiments→com.facebook.imagepipeline.core.ImagePipelineExperiments.Buildercom.facebook.imagepipeline.core.ImagePipelineExperiments→com.facebook.imagepipeline.core.ImagePipelineExperiments.ProducerFactoryMethod
- Direction
- imagepipeline.core uses imagepipeline.core.ImagePipelineExperiments, so a change to imagepipeline.core.ImagePipelineExperiments can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.core.ImagePipelineExperiments.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→23 imagepipeline.core uses imagepipeline.core.ImagePipelineConfig✕
- Connections
- 1 pair of types, where a type in imagepipeline.core uses a type in imagepipeline.core.ImagePipelineConfig.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.core.ImagePipelineConfig.Builder
- Direction
- imagepipeline.core uses imagepipeline.core.ImagePipelineConfig, so a change to imagepipeline.core.ImagePipelineConfig can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.core.ImagePipelineConfig.
- Position
- Below the diagonal: imagepipeline.core uses a module listed above it, which is the healthy direction.
24→28 imagepipeline.core uses imagepipeline.decoder part of a loop✕
- Connections
- 6 pairs of types, where a type in imagepipeline.core uses a type in imagepipeline.decoder.
- The types involved
com.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.decoder.ImageDecodercom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.decoder.ImageDecoderConfigcom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.decoder.ImageDecodercom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.decoder.ImageDecoderConfigcom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imagepipeline.decoder.ImageDecodercom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.decoder.ImageDecoder
- Direction
- imagepipeline.core uses imagepipeline.decoder, so a change to imagepipeline.decoder can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.decoder.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
24→29 imagepipeline.core uses imagepipeline.common part of a loop✕
- Connections
- 1 pair of types, where a type in imagepipeline.core uses a type in imagepipeline.common.
- The types involved
com.facebook.imagepipeline.core.ImagePipeline→com.facebook.imagepipeline.common.Priority
- Direction
- imagepipeline.core uses imagepipeline.common, so a change to imagepipeline.common can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.common.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
24→31 imagepipeline.core uses imagepipeline.cache part of a loop✕
- Connections
- 21 pairs of types, where a type in imagepipeline.core uses a type in imagepipeline.cache.
- The types involved
com.facebook.imagepipeline.core.DiskCachesStore→com.facebook.imagepipeline.cache.BufferedDiskCachecom.facebook.imagepipeline.core.DiskCachesStoreFactory→com.facebook.imagepipeline.cache.ImageCacheStatsTrackercom.facebook.imagepipeline.core.ImagePipeline→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.core.ImagePipeline→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.cache.BitmapMemoryCacheFactorycom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.cache.ImageCacheStatsTrackercom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.core.ImagePipelineConfig→com.facebook.imagepipeline.cache.MemoryCacheParamscom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.cache.BitmapMemoryCacheFactorycom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.cache.ImageCacheStatsTrackercom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.imagepipeline.core.ImagePipelineConfigInterface→com.facebook.imagepipeline.cache.MemoryCacheParamscom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imagepipeline.cache.BitmapMemoryCacheFactorycom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imagepipeline.cache.CountingMemoryCachecom.facebook.imagepipeline.core.ImagePipelineFactory→com.facebook.imagepipeline.cache.InstrumentedMemoryCachecom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.cache.BoundedLinkedHashMapcom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.cache.BoundedLinkedHashSetcom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.cache.CacheKeyFactorycom.facebook.imagepipeline.core.ProducerFactory→com.facebook.imagepipeline.cache.MemoryCache
- Direction
- imagepipeline.core uses imagepipeline.cache, so a change to imagepipeline.cache can break imagepipeline.core, while a change to imagepipeline.core can't break imagepipeline.cache.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
25→1 imagepipeline.request uses cache.common✕
- Connections
- 2 pairs of types, where a type in imagepipeline.request uses a type in cache.common.
- The types involved
com.facebook.imagepipeline.request.BasePostprocessor→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.request.Postprocessor→com.facebook.cache.common.CacheKey
- Direction
- imagepipeline.request uses cache.common, so a change to cache.common can break imagepipeline.request, while a change to imagepipeline.request can't break cache.common.
- Position
- Below the diagonal: imagepipeline.request uses a module listed above it, which is the healthy direction.
25→2 imagepipeline.request uses common.internal✕
- Connections
- 2 pairs of types, where a type in imagepipeline.request uses a type in common.internal.
- The types involved
com.facebook.imagepipeline.request.1→com.facebook.common.internal.Fncom.facebook.imagepipeline.request.ImageRequest→com.facebook.common.internal.Fn
- Direction
- imagepipeline.request uses common.internal, so a change to common.internal can break imagepipeline.request, while a change to imagepipeline.request can't break common.internal.
- Position
- Below the diagonal: imagepipeline.request uses a module listed above it, which is the healthy direction.
25→3 imagepipeline.request uses common.references✕
- Connections
- 2 pairs of types, where a type in imagepipeline.request uses a type in common.references.
- The types involved
com.facebook.imagepipeline.request.BasePostprocessor→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.request.Postprocessor→com.facebook.common.references.CloseableReference
- Direction
- imagepipeline.request uses common.references, so a change to common.references can break imagepipeline.request, while a change to imagepipeline.request can't break common.references.
- Position
- Below the diagonal: imagepipeline.request uses a module listed above it, which is the healthy direction.
25→12 imagepipeline.request uses imagepipeline.listener✕
- Connections
- 2 pairs of types, where a type in imagepipeline.request uses a type in imagepipeline.listener.
- The types involved
com.facebook.imagepipeline.request.ImageRequest→com.facebook.imagepipeline.listener.RequestListenercom.facebook.imagepipeline.request.ImageRequestBuilder→com.facebook.imagepipeline.listener.RequestListener
- Direction
- imagepipeline.request uses imagepipeline.listener, so a change to imagepipeline.listener can break imagepipeline.request, while a change to imagepipeline.request can't break imagepipeline.listener.
- Position
- Below the diagonal: imagepipeline.request uses a module listed above it, which is the healthy direction.
25→19 imagepipeline.request uses imagepipeline.bitmaps✕
- Connections
- 2 pairs of types, where a type in imagepipeline.request uses a type in imagepipeline.bitmaps.
- The types involved
com.facebook.imagepipeline.request.BasePostprocessor→com.facebook.imagepipeline.bitmaps.PlatformBitmapFactorycom.facebook.imagepipeline.request.Postprocessor→com.facebook.imagepipeline.bitmaps.PlatformBitmapFactory
- Direction
- imagepipeline.request uses imagepipeline.bitmaps, so a change to imagepipeline.bitmaps can break imagepipeline.request, while a change to imagepipeline.request can't break imagepipeline.bitmaps.
- Position
- Below the diagonal: imagepipeline.request uses a module listed above it, which is the healthy direction.
25→24 imagepipeline.request uses imagepipeline.core✕
- Connections
- 2 pairs of types, where a type in imagepipeline.request uses a type in imagepipeline.core.
- The types involved
com.facebook.imagepipeline.request.ImageRequest→com.facebook.imagepipeline.core.DownsampleModecom.facebook.imagepipeline.request.ImageRequestBuilder→com.facebook.imagepipeline.core.DownsampleMode
- Direction
- imagepipeline.request uses imagepipeline.core, so a change to imagepipeline.core can break imagepipeline.request, while a change to imagepipeline.request can't break imagepipeline.core.
- Position
- Below the diagonal: imagepipeline.request uses a module listed above it, which is the healthy direction.
25→29 imagepipeline.request uses imagepipeline.common part of a loop✕
- Connections
- 10 pairs of types, where a type in imagepipeline.request uses a type in imagepipeline.common.
- The types involved
com.facebook.imagepipeline.request.ImageRequest→com.facebook.imagepipeline.common.BytesRangecom.facebook.imagepipeline.request.ImageRequest→com.facebook.imagepipeline.common.ImageDecodeOptionscom.facebook.imagepipeline.request.ImageRequest→com.facebook.imagepipeline.common.Prioritycom.facebook.imagepipeline.request.ImageRequest→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.request.ImageRequest→com.facebook.imagepipeline.common.RotationOptionscom.facebook.imagepipeline.request.ImageRequestBuilder→com.facebook.imagepipeline.common.BytesRangecom.facebook.imagepipeline.request.ImageRequestBuilder→com.facebook.imagepipeline.common.ImageDecodeOptionscom.facebook.imagepipeline.request.ImageRequestBuilder→com.facebook.imagepipeline.common.Prioritycom.facebook.imagepipeline.request.ImageRequestBuilder→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.request.ImageRequestBuilder→com.facebook.imagepipeline.common.RotationOptions
- Direction
- imagepipeline.request uses imagepipeline.common, so a change to imagepipeline.common can break imagepipeline.request, while a change to imagepipeline.request can't break imagepipeline.common.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
26→2 drawee.view uses common.internal✕
- Connections
- 1 pair of types, where a type in drawee.view uses a type in common.internal.
- The types involved
com.facebook.drawee.view.SimpleDraweeView→com.facebook.common.internal.Supplier
- Direction
- drawee.view uses common.internal, so a change to common.internal can break drawee.view, while a change to drawee.view can't break common.internal.
- Position
- Below the diagonal: drawee.view uses a module listed above it, which is the healthy direction.
26→4 drawee.view uses drawee.components✕
- Connections
- 1 pair of types, where a type in drawee.view uses a type in drawee.components.
- The types involved
com.facebook.drawee.view.DraweeHolder→com.facebook.drawee.components.DraweeEventTracker
- Direction
- drawee.view uses drawee.components, so a change to drawee.components can break drawee.view, while a change to drawee.view can't break drawee.components.
- Position
- Below the diagonal: drawee.view uses a module listed above it, which is the healthy direction.
26→13 drawee.view uses drawee.controller✕
- Connections
- 1 pair of types, where a type in drawee.view uses a type in drawee.controller.
- The types involved
com.facebook.drawee.view.SimpleDraweeView→com.facebook.drawee.controller.AbstractDraweeControllerBuilder
- Direction
- drawee.view uses drawee.controller, so a change to drawee.controller can break drawee.view, while a change to drawee.view can't break drawee.controller.
- Position
- Below the diagonal: drawee.view uses a module listed above it, which is the healthy direction.
26→14 drawee.view uses drawee.drawable✕
- Connections
- 2 pairs of types, where a type in drawee.view uses a type in drawee.drawable.
- The types involved
com.facebook.drawee.view.DraweeHolder→com.facebook.drawee.drawable.VisibilityCallbackcom.facebook.drawee.view.DraweeTransition→com.facebook.drawee.drawable.ScaleType
- Direction
- drawee.view uses drawee.drawable, so a change to drawee.drawable can break drawee.view, while a change to drawee.view can't break drawee.drawable.
- Position
- Below the diagonal: drawee.view uses a module listed above it, which is the healthy direction.
26→25 drawee.view uses imagepipeline.request✕
- Connections
- 1 pair of types, where a type in drawee.view uses a type in imagepipeline.request.
- The types involved
com.facebook.drawee.view.SimpleDraweeView→com.facebook.imagepipeline.request.ImageRequest
- Direction
- drawee.view uses imagepipeline.request, so a change to imagepipeline.request can break drawee.view, while a change to drawee.view can't break imagepipeline.request.
- Position
- Below the diagonal: drawee.view uses a module listed above it, which is the healthy direction.
27→1 flipper.plugins.fresco uses cache.common✕
- Connections
- 3 pairs of types, where a type in flipper.plugins.fresco uses a type in cache.common.
- The types involved
com.facebook.flipper.plugins.fresco.1→com.facebook.cache.common.CacheKeycom.facebook.flipper.plugins.fresco.4→com.facebook.cache.common.CacheKeycom.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.cache.common.CacheKey
- Direction
- flipper.plugins.fresco uses cache.common, so a change to cache.common can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break cache.common.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→2 flipper.plugins.fresco uses common.internal✕
- Connections
- 2 pairs of types, where a type in flipper.plugins.fresco uses a type in common.internal.
- The types involved
com.facebook.flipper.plugins.fresco.1→com.facebook.common.internal.Predicatecom.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.common.internal.Predicate
- Direction
- flipper.plugins.fresco uses common.internal, so a change to common.internal can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break common.internal.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→3 flipper.plugins.fresco uses common.references✕
- Connections
- 1 pair of types, where a type in flipper.plugins.fresco uses a type in common.references.
- The types involved
com.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.common.references.SharedReference
- Direction
- flipper.plugins.fresco uses common.references, so a change to common.references can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break common.references.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→8 flipper.plugins.fresco uses cache.disk✕
- Connections
- 1 pair of types, where a type in flipper.plugins.fresco uses a type in cache.disk.
- The types involved
com.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.cache.disk.DiskDumpInfoEntry
- Direction
- flipper.plugins.fresco uses cache.disk, so a change to cache.disk can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break cache.disk.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→9 flipper.plugins.fresco uses common.memory✕
- Connections
- 1 pair of types, where a type in flipper.plugins.fresco uses a type in common.memory.
- The types involved
com.facebook.flipper.plugins.fresco.4→com.facebook.common.memory.PooledByteBuffer
- Direction
- flipper.plugins.fresco uses common.memory, so a change to common.memory can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break common.memory.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→10 flipper.plugins.fresco uses fresco.ui.common✕
- Connections
- 4 pairs of types, where a type in flipper.plugins.fresco uses a type in fresco.ui.common.
- The types involved
com.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.fresco.ui.common.ImageLoadStatuscom.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.fresco.ui.common.ImagePerfDatacom.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.fresco.ui.common.VisibilityState
- Direction
- flipper.plugins.fresco uses fresco.ui.common, so a change to fresco.ui.common can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break fresco.ui.common.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→12 flipper.plugins.fresco uses imagepipeline.listener✕
- Connections
- 1 pair of types, where a type in flipper.plugins.fresco uses a type in imagepipeline.listener.
- The types involved
com.facebook.flipper.plugins.fresco.FrescoFlipperRequestListener→com.facebook.imagepipeline.listener.BaseRequestListener
- Direction
- flipper.plugins.fresco uses imagepipeline.listener, so a change to imagepipeline.listener can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break imagepipeline.listener.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→16 flipper.plugins.fresco uses imagepipeline.image✕
- Connections
- 1 pair of types, where a type in flipper.plugins.fresco uses a type in imagepipeline.image.
- The types involved
com.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.imagepipeline.image.CloseableImage
- Direction
- flipper.plugins.fresco uses imagepipeline.image, so a change to imagepipeline.image can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break imagepipeline.image.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→19 flipper.plugins.fresco uses imagepipeline.bitmaps✕
- Connections
- 1 pair of types, where a type in flipper.plugins.fresco uses a type in imagepipeline.bitmaps.
- The types involved
com.facebook.flipper.plugins.fresco.FrescoFlipperPlugin→com.facebook.imagepipeline.bitmaps.PlatformBitmapFactory
- Direction
- flipper.plugins.fresco uses imagepipeline.bitmaps, so a change to imagepipeline.bitmaps can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break imagepipeline.bitmaps.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
27→25 flipper.plugins.fresco uses imagepipeline.request✕
- Connections
- 1 pair of types, where a type in flipper.plugins.fresco uses a type in imagepipeline.request.
- The types involved
com.facebook.flipper.plugins.fresco.FrescoFlipperRequestListener→com.facebook.imagepipeline.request.ImageRequest
- Direction
- flipper.plugins.fresco uses imagepipeline.request, so a change to imagepipeline.request can break flipper.plugins.fresco, while a change to flipper.plugins.fresco can't break imagepipeline.request.
- Position
- Below the diagonal: flipper.plugins.fresco uses a module listed above it, which is the healthy direction.
28→2 imagepipeline.decoder uses common.internal✕
- Connections
- 1 pair of types, where a type in imagepipeline.decoder uses a type in common.internal.
- The types involved
com.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.common.internal.Supplier
- Direction
- imagepipeline.decoder uses common.internal, so a change to common.internal can break imagepipeline.decoder, while a change to imagepipeline.decoder can't break common.internal.
- Position
- Below the diagonal: imagepipeline.decoder uses a module listed above it, which is the healthy direction.
28→6 imagepipeline.decoder uses imageformat✕
- Connections
- 2 pairs of types, where a type in imagepipeline.decoder uses a type in imageformat.
- The types involved
com.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.imageformat.ImageFormatcom.facebook.imagepipeline.decoder.ImageDecoderConfig→com.facebook.imageformat.ImageFormat
- Direction
- imagepipeline.decoder uses imageformat, so a change to imageformat can break imagepipeline.decoder, while a change to imagepipeline.decoder can't break imageformat.
- Position
- Below the diagonal: imagepipeline.decoder uses a module listed above it, which is the healthy direction.
28→7 imagepipeline.decoder uses imagepipeline.transformation✕
- Connections
- 1 pair of types, where a type in imagepipeline.decoder uses a type in imagepipeline.transformation.
- The types involved
com.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.imagepipeline.transformation.BitmapTransformation
- Direction
- imagepipeline.decoder uses imagepipeline.transformation, so a change to imagepipeline.transformation can break imagepipeline.decoder, while a change to imagepipeline.decoder can't break imagepipeline.transformation.
- Position
- Below the diagonal: imagepipeline.decoder uses a module listed above it, which is the healthy direction.
28→9 imagepipeline.decoder uses common.memory✕
- Connections
- 1 pair of types, where a type in imagepipeline.decoder uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.decoder.ProgressiveJpegParser→com.facebook.common.memory.ByteArrayPool
- Direction
- imagepipeline.decoder uses common.memory, so a change to common.memory can break imagepipeline.decoder, while a change to imagepipeline.decoder can't break common.memory.
- Position
- Below the diagonal: imagepipeline.decoder uses a module listed above it, which is the healthy direction.
28→16 imagepipeline.decoder uses imagepipeline.image✕
- Connections
- 10 pairs of types, where a type in imagepipeline.decoder uses a type in imagepipeline.image.
- The types involved
com.facebook.imagepipeline.decoder.1→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.decoder.1→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.decoder.1→com.facebook.imagepipeline.image.QualityInfocom.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.imagepipeline.image.CloseableStaticBitmapcom.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.imagepipeline.image.QualityInfocom.facebook.imagepipeline.decoder.ProgressiveJpegConfig→com.facebook.imagepipeline.image.QualityInfocom.facebook.imagepipeline.decoder.ProgressiveJpegParser→com.facebook.imagepipeline.image.EncodedImagecom.facebook.imagepipeline.decoder.SimpleProgressiveJpegConfig→com.facebook.imagepipeline.image.QualityInfo
- Direction
- imagepipeline.decoder uses imagepipeline.image, so a change to imagepipeline.image can break imagepipeline.decoder, while a change to imagepipeline.decoder can't break imagepipeline.image.
- Position
- Below the diagonal: imagepipeline.decoder uses a module listed above it, which is the healthy direction.
28→25 imagepipeline.decoder uses imagepipeline.request✕
- Connections
- 4 pairs of types, where a type in imagepipeline.decoder uses a type in imagepipeline.request.
- The types involved
com.facebook.imagepipeline.decoder.DefaultDynamicValueConfig→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.decoder.DynamicValueConfig→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.decoder.ProgressiveJpegConfig→com.facebook.imagepipeline.request.ImageRequestcom.facebook.imagepipeline.decoder.SimpleProgressiveJpegConfig→com.facebook.imagepipeline.request.ImageRequest
- Direction
- imagepipeline.decoder uses imagepipeline.request, so a change to imagepipeline.request can break imagepipeline.decoder, while a change to imagepipeline.decoder can't break imagepipeline.request.
- Position
- Below the diagonal: imagepipeline.decoder uses a module listed above it, which is the healthy direction.
28→29 imagepipeline.decoder uses imagepipeline.common part of a loop✕
- Connections
- 2 pairs of types, where a type in imagepipeline.decoder uses a type in imagepipeline.common.
- The types involved
com.facebook.imagepipeline.decoder.1→com.facebook.imagepipeline.common.ImageDecodeOptionscom.facebook.imagepipeline.decoder.DefaultImageDecoder→com.facebook.imagepipeline.common.ImageDecodeOptions
- Direction
- imagepipeline.decoder uses imagepipeline.common, so a change to imagepipeline.common can break imagepipeline.decoder, while a change to imagepipeline.decoder can't break imagepipeline.common.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
29→2 imagepipeline.common uses common.internal✕
- Connections
- 1 pair of types, where a type in imagepipeline.common uses a type in common.internal.
- The types involved
com.facebook.imagepipeline.common.ImageDecodeOptions→com.facebook.common.internal.ToStringHelper
- Direction
- imagepipeline.common uses common.internal, so a change to common.internal can break imagepipeline.common, while a change to imagepipeline.common can't break common.internal.
- Position
- Below the diagonal: imagepipeline.common uses a module listed above it, which is the healthy direction.
29→7 imagepipeline.common uses imagepipeline.transformation✕
- Connections
- 2 pairs of types, where a type in imagepipeline.common uses a type in imagepipeline.transformation.
- The types involved
com.facebook.imagepipeline.common.ImageDecodeOptions→com.facebook.imagepipeline.transformation.BitmapTransformationcom.facebook.imagepipeline.common.ImageDecodeOptionsBuilder→com.facebook.imagepipeline.transformation.BitmapTransformation
- Direction
- imagepipeline.common uses imagepipeline.transformation, so a change to imagepipeline.transformation can break imagepipeline.common, while a change to imagepipeline.common can't break imagepipeline.transformation.
- Position
- Below the diagonal: imagepipeline.common uses a module listed above it, which is the healthy direction.
29→28 imagepipeline.common uses imagepipeline.decoder✕
- Connections
- 2 pairs of types, where a type in imagepipeline.common uses a type in imagepipeline.decoder.
- The types involved
com.facebook.imagepipeline.common.ImageDecodeOptions→com.facebook.imagepipeline.decoder.ImageDecodercom.facebook.imagepipeline.common.ImageDecodeOptionsBuilder→com.facebook.imagepipeline.decoder.ImageDecoder
- Direction
- imagepipeline.common uses imagepipeline.decoder, so a change to imagepipeline.decoder can break imagepipeline.common, while a change to imagepipeline.common can't break imagepipeline.decoder.
- Position
- Below the diagonal: imagepipeline.common uses a module listed above it, which is the healthy direction.
30→7 fresco.vito.options uses imagepipeline.transformation✕
- Connections
- 1 pair of types, where a type in fresco.vito.options uses a type in imagepipeline.transformation.
- The types involved
com.facebook.fresco.vito.options.DecodedImageOptions→com.facebook.imagepipeline.transformation.BitmapTransformation
- Direction
- fresco.vito.options uses imagepipeline.transformation, so a change to imagepipeline.transformation can break fresco.vito.options, while a change to fresco.vito.options can't break imagepipeline.transformation.
- Position
- Below the diagonal: fresco.vito.options uses a module listed above it, which is the healthy direction.
30→24 fresco.vito.options uses imagepipeline.core✕
- Connections
- 1 pair of types, where a type in fresco.vito.options uses a type in imagepipeline.core.
- The types involved
com.facebook.fresco.vito.options.DecodedImageOptions→com.facebook.imagepipeline.core.DownsampleMode
- Direction
- fresco.vito.options uses imagepipeline.core, so a change to imagepipeline.core can break fresco.vito.options, while a change to fresco.vito.options can't break imagepipeline.core.
- Position
- Below the diagonal: fresco.vito.options uses a module listed above it, which is the healthy direction.
30→29 fresco.vito.options uses imagepipeline.common✕
- Connections
- 3 pairs of types, where a type in fresco.vito.options uses a type in imagepipeline.common.
- The types involved
com.facebook.fresco.vito.options.DecodedImageOptions→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.fresco.vito.options.DecodedImageOptions→com.facebook.imagepipeline.common.RotationOptionscom.facebook.fresco.vito.options.EncodedImageOptions→com.facebook.imagepipeline.common.Priority
- Direction
- fresco.vito.options uses imagepipeline.common, so a change to imagepipeline.common can break fresco.vito.options, while a change to fresco.vito.options can't break imagepipeline.common.
- Position
- Below the diagonal: fresco.vito.options uses a module listed above it, which is the healthy direction.
31→1 imagepipeline.cache uses cache.common✕
- Connections
- 9 pairs of types, where a type in imagepipeline.cache uses a type in cache.common.
- The types involved
com.facebook.imagepipeline.cache.BitmapMemoryCacheKey→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.cache.DefaultCacheKeyFactory→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.cache.EncodedCountingMemoryCacheFactory→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.cache.EncodedMemoryCacheFactory→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.cache.InstrumentedMemoryCacheBitmapMemoryCacheFactory→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.cache.LruCountingMemoryCache→com.facebook.cache.common.HasDebugDatacom.facebook.imagepipeline.cache.MemoryCache→com.facebook.cache.common.HasDebugDatacom.facebook.imagepipeline.cache.NoOpImageCacheStatsTracker→com.facebook.cache.common.CacheKeycom.facebook.imagepipeline.cache.StagingArea→com.facebook.cache.common.CacheKey
- Direction
- imagepipeline.cache uses cache.common, so a change to cache.common can break imagepipeline.cache, while a change to imagepipeline.cache can't break cache.common.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
31→2 imagepipeline.cache uses common.internal✕
- Connections
- 6 pairs of types, where a type in imagepipeline.cache uses a type in common.internal.
- The types involved
com.facebook.imagepipeline.cache.AbstractAdaptiveCountingMemoryCache→com.facebook.common.internal.Predicatecom.facebook.imagepipeline.cache.AbstractAdaptiveCountingMemoryCache→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.cache.CountingLruMap→com.facebook.common.internal.Predicatecom.facebook.imagepipeline.cache.DefaultBitmapMemoryCacheParamsSupplier→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.cache.DefaultEncodedMemoryCacheParamsSupplier→com.facebook.common.internal.Suppliercom.facebook.imagepipeline.cache.EncodedCountingMemoryCacheFactory→com.facebook.common.internal.Supplier
- Direction
- imagepipeline.cache uses common.internal, so a change to common.internal can break imagepipeline.cache, while a change to imagepipeline.cache can't break common.internal.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
31→3 imagepipeline.cache uses common.references✕
- Connections
- 4 pairs of types, where a type in imagepipeline.cache uses a type in common.references.
- The types involved
com.facebook.imagepipeline.cache.2→com.facebook.common.references.ResourceReleasercom.facebook.imagepipeline.cache.AbstractAdaptiveCountingMemoryCache→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.cache.CountingMemoryCache→com.facebook.common.references.CloseableReferencecom.facebook.imagepipeline.cache.Entry→com.facebook.common.references.CloseableReference
- Direction
- imagepipeline.cache uses common.references, so a change to common.references can break imagepipeline.cache, while a change to imagepipeline.cache can't break common.references.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
31→8 imagepipeline.cache uses cache.disk✕
- Connections
- 1 pair of types, where a type in imagepipeline.cache uses a type in cache.disk.
- The types involved
com.facebook.imagepipeline.cache.BufferedDiskCache→com.facebook.cache.disk.FileCache
- Direction
- imagepipeline.cache uses cache.disk, so a change to cache.disk can break imagepipeline.cache, while a change to imagepipeline.cache can't break cache.disk.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
31→9 imagepipeline.cache uses common.memory✕
- Connections
- 7 pairs of types, where a type in imagepipeline.cache uses a type in common.memory.
- The types involved
com.facebook.imagepipeline.cache.1→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.cache.AbstractAdaptiveCountingMemoryCache→com.facebook.common.memory.MemoryTrimTypecom.facebook.imagepipeline.cache.CountingMemoryCache→com.facebook.common.memory.MemoryTrimmablecom.facebook.imagepipeline.cache.EncodedCountingMemoryCacheFactory→com.facebook.common.memory.MemoryTrimmableRegistrycom.facebook.imagepipeline.cache.EncodedCountingMemoryCacheFactory→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.cache.EncodedMemoryCacheFactory→com.facebook.common.memory.PooledByteBuffercom.facebook.imagepipeline.cache.MemoryCache→com.facebook.common.memory.MemoryTrimmable
- Direction
- imagepipeline.cache uses common.memory, so a change to common.memory can break imagepipeline.cache, while a change to imagepipeline.cache can't break common.memory.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
31→16 imagepipeline.cache uses imagepipeline.image✕
- Connections
- 2 pairs of types, where a type in imagepipeline.cache uses a type in imagepipeline.image.
- The types involved
com.facebook.imagepipeline.cache.InstrumentedMemoryCacheBitmapMemoryCacheFactory→com.facebook.imagepipeline.image.CloseableImagecom.facebook.imagepipeline.cache.StagingArea→com.facebook.imagepipeline.image.EncodedImage
- Direction
- imagepipeline.cache uses imagepipeline.image, so a change to imagepipeline.image can break imagepipeline.cache, while a change to imagepipeline.cache can't break imagepipeline.image.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
31→25 imagepipeline.cache uses imagepipeline.request✕
- Connections
- 1 pair of types, where a type in imagepipeline.cache uses a type in imagepipeline.request.
- The types involved
com.facebook.imagepipeline.cache.DefaultCacheKeyFactory→com.facebook.imagepipeline.request.ImageRequest
- Direction
- imagepipeline.cache uses imagepipeline.request, so a change to imagepipeline.request can break imagepipeline.cache, while a change to imagepipeline.cache can't break imagepipeline.request.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
31→29 imagepipeline.cache uses imagepipeline.common✕
- Connections
- 3 pairs of types, where a type in imagepipeline.cache uses a type in imagepipeline.common.
- The types involved
com.facebook.imagepipeline.cache.BitmapMemoryCacheKey→com.facebook.imagepipeline.common.ResizeOptionscom.facebook.imagepipeline.cache.BitmapMemoryCacheKey→com.facebook.imagepipeline.common.RotationOptionscom.facebook.imagepipeline.cache.CacheKeyConfig→com.facebook.imagepipeline.common.ResizeOptions
- Direction
- imagepipeline.cache uses imagepipeline.common, so a change to imagepipeline.common can break imagepipeline.cache, while a change to imagepipeline.cache can't break imagepipeline.common.
- Position
- Below the diagonal: imagepipeline.cache uses a module listed above it, which is the healthy direction.
32→1 drawee.backends.pipeline uses cache.common✕
- Connections
- 3 pairs of types, where a type in drawee.backends.pipeline uses a type in cache.common.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.cache.common.CacheKeycom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.cache.common.CacheKeycom.facebook.drawee.backends.pipeline.PipelineDraweeControllerFactory→com.facebook.cache.common.CacheKey
- Direction
- drawee.backends.pipeline uses cache.common, so a change to cache.common can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break cache.common.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→2 drawee.backends.pipeline uses common.internal✕
- Connections
- 9 pairs of types, where a type in drawee.backends.pipeline uses a type in common.internal.
- The types involved
com.facebook.drawee.backends.pipeline.Builder→com.facebook.common.internal.Suppliercom.facebook.drawee.backends.pipeline.DraweeConfig→com.facebook.common.internal.ImmutableListcom.facebook.drawee.backends.pipeline.DraweeConfig→com.facebook.common.internal.Suppliercom.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.common.internal.ImmutableListcom.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.common.internal.Suppliercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.common.internal.ImmutableListcom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilderSupplier→com.facebook.common.internal.Suppliercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerFactory→com.facebook.common.internal.ImmutableListcom.facebook.drawee.backends.pipeline.PipelineDraweeControllerFactory→com.facebook.common.internal.Supplier
- Direction
- drawee.backends.pipeline uses common.internal, so a change to common.internal can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break common.internal.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→3 drawee.backends.pipeline uses common.references✕
- Connections
- 2 pairs of types, where a type in drawee.backends.pipeline uses a type in common.references.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.common.references.CloseableReferencecom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.common.references.CloseableReference
- Direction
- drawee.backends.pipeline uses common.references, so a change to common.references can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break common.references.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→4 drawee.backends.pipeline uses drawee.components✕
- Connections
- 2 pairs of types, where a type in drawee.backends.pipeline uses a type in drawee.components.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.drawee.components.DeferredReleasercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerFactory→com.facebook.drawee.components.DeferredReleaser
- Direction
- drawee.backends.pipeline uses drawee.components, so a change to drawee.components can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break drawee.components.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→10 drawee.backends.pipeline uses fresco.ui.common✕
- Connections
- 7 pairs of types, where a type in drawee.backends.pipeline uses a type in fresco.ui.common.
- The types involved
com.facebook.drawee.backends.pipeline.Builder→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.drawee.backends.pipeline.DraweeConfig→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.fresco.ui.common.ControllerListener2com.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilderSupplier→com.facebook.fresco.ui.common.ControllerListener2com.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilderSupplier→com.facebook.fresco.ui.common.ImagePerfDataListener
- Direction
- drawee.backends.pipeline uses fresco.ui.common, so a change to fresco.ui.common can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break fresco.ui.common.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→12 drawee.backends.pipeline uses imagepipeline.listener✕
- Connections
- 2 pairs of types, where a type in drawee.backends.pipeline uses a type in imagepipeline.listener.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.imagepipeline.listener.RequestListenercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.imagepipeline.listener.RequestListener
- Direction
- drawee.backends.pipeline uses imagepipeline.listener, so a change to imagepipeline.listener can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break imagepipeline.listener.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→13 drawee.backends.pipeline uses drawee.controller✕
- Connections
- 6 pairs of types, where a type in drawee.backends.pipeline uses a type in drawee.controller.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.drawee.controller.AbstractDraweeControllercom.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.drawee.controller.AbstractDraweeControllerBuildercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.drawee.controller.AbstractDraweeControllerBuildercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.drawee.controller.CacheLevelcom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.drawee.controller.ControllerListenercom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilderSupplier→com.facebook.drawee.controller.ControllerListener
- Direction
- drawee.backends.pipeline uses drawee.controller, so a change to drawee.controller can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break drawee.controller.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→14 drawee.backends.pipeline uses drawee.drawable✕
- Connections
- 1 pair of types, where a type in drawee.backends.pipeline uses a type in drawee.drawable.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.drawee.drawable.ScaleTypeDrawable
- Direction
- drawee.backends.pipeline uses drawee.drawable, so a change to drawee.drawable can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break drawee.drawable.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→16 drawee.backends.pipeline uses imagepipeline.image✕
- Connections
- 6 pairs of types, where a type in drawee.backends.pipeline uses a type in imagepipeline.image.
- The types involved
com.facebook.drawee.backends.pipeline.DefaultDrawableFactory→com.facebook.imagepipeline.image.CloseableImagecom.facebook.drawee.backends.pipeline.DefaultDrawableFactory→com.facebook.imagepipeline.image.CloseableStaticBitmapcom.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.imagepipeline.image.CloseableImagecom.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.imagepipeline.image.ImageInfocom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.imagepipeline.image.CloseableImagecom.facebook.drawee.backends.pipeline.PipelineDraweeControllerFactory→com.facebook.imagepipeline.image.CloseableImage
- Direction
- drawee.backends.pipeline uses imagepipeline.image, so a change to imagepipeline.image can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break imagepipeline.image.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→24 drawee.backends.pipeline uses imagepipeline.core✕
- Connections
- 6 pairs of types, where a type in drawee.backends.pipeline uses a type in imagepipeline.core.
- The types involved
com.facebook.drawee.backends.pipeline.Fresco→com.facebook.imagepipeline.core.ImagePipelinecom.facebook.drawee.backends.pipeline.Fresco→com.facebook.imagepipeline.core.ImagePipelineConfigcom.facebook.drawee.backends.pipeline.Fresco→com.facebook.imagepipeline.core.ImagePipelineFactorycom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.imagepipeline.core.ImagePipelinecom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilderSupplier→com.facebook.imagepipeline.core.ImagePipelinecom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilderSupplier→com.facebook.imagepipeline.core.ImagePipelineFactory
- Direction
- drawee.backends.pipeline uses imagepipeline.core, so a change to imagepipeline.core can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break imagepipeline.core.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→25 drawee.backends.pipeline uses imagepipeline.request✕
- Connections
- 3 pairs of types, where a type in drawee.backends.pipeline uses a type in imagepipeline.request.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.imagepipeline.request.ImageRequestcom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.imagepipeline.request.ImageRequestcom.facebook.drawee.backends.pipeline.PipelineDraweeControllerBuilder→com.facebook.imagepipeline.request.RequestLevel
- Direction
- drawee.backends.pipeline uses imagepipeline.request, so a change to imagepipeline.request can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break imagepipeline.request.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
32→31 drawee.backends.pipeline uses imagepipeline.cache✕
- Connections
- 2 pairs of types, where a type in drawee.backends.pipeline uses a type in imagepipeline.cache.
- The types involved
com.facebook.drawee.backends.pipeline.PipelineDraweeController→com.facebook.imagepipeline.cache.MemoryCachecom.facebook.drawee.backends.pipeline.PipelineDraweeControllerFactory→com.facebook.imagepipeline.cache.MemoryCache
- Direction
- drawee.backends.pipeline uses imagepipeline.cache, so a change to imagepipeline.cache can break drawee.backends.pipeline, while a change to drawee.backends.pipeline can't break imagepipeline.cache.
- Position
- Below the diagonal: drawee.backends.pipeline uses a module listed above it, which is the healthy direction.
33→13 drawee.span uses drawee.controller✕
- Connections
- 1 pair of types, where a type in drawee.span uses a type in drawee.controller.
- The types involved
com.facebook.drawee.span.VitoDrawableChangedListener→com.facebook.drawee.controller.BaseControllerListener
- Direction
- drawee.span uses drawee.controller, so a change to drawee.controller can break drawee.span, while a change to drawee.span can't break drawee.controller.
- Position
- Below the diagonal: drawee.span uses a module listed above it, which is the healthy direction.
33→16 drawee.span uses imagepipeline.image✕
- Connections
- 1 pair of types, where a type in drawee.span uses a type in imagepipeline.image.
- The types involved
com.facebook.drawee.span.VitoDrawableChangedListener→com.facebook.imagepipeline.image.ImageInfo
- Direction
- drawee.span uses imagepipeline.image, so a change to imagepipeline.image can break drawee.span, while a change to drawee.span can't break imagepipeline.image.
- Position
- Below the diagonal: drawee.span uses a module listed above it, which is the healthy direction.
33→18 drawee.span uses fresco.vito.source✕
- Connections
- 1 pair of types, where a type in drawee.span uses a type in fresco.vito.source.
- The types involved
com.facebook.drawee.span.DraweeSpanStringBuilder→com.facebook.fresco.vito.source.ImageSource
- Direction
- drawee.span uses fresco.vito.source, so a change to fresco.vito.source can break drawee.span, while a change to drawee.span can't break fresco.vito.source.
- Position
- Below the diagonal: drawee.span uses a module listed above it, which is the healthy direction.
33→26 drawee.span uses drawee.view✕
- Connections
- 1 pair of types, where a type in drawee.span uses a type in drawee.view.
- The types involved
com.facebook.drawee.span.DraweeSpan→com.facebook.drawee.view.DraweeHolder
- Direction
- drawee.span uses drawee.view, so a change to drawee.view can break drawee.span, while a change to drawee.span can't break drawee.view.
- Position
- Below the diagonal: drawee.span uses a module listed above it, which is the healthy direction.
33→30 drawee.span uses fresco.vito.options✕
- Connections
- 1 pair of types, where a type in drawee.span uses a type in fresco.vito.options.
- The types involved
com.facebook.drawee.span.DraweeSpanStringBuilder→com.facebook.fresco.vito.options.ImageOptions
- Direction
- drawee.span uses fresco.vito.options, so a change to fresco.vito.options can break drawee.span, while a change to drawee.span can't break fresco.vito.options.
- Position
- Below the diagonal: drawee.span uses a module listed above it, which is the healthy direction.
34→5 fresco.vito.core uses fresco.ui.common.ControllerListener2✕
- Connections
- 2 pairs of types, where a type in fresco.vito.core uses a type in fresco.ui.common.ControllerListener2.
- The types involved
com.facebook.fresco.vito.core.BaseVitoImageRequestListener→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.VitoImageRequestListener→com.facebook.fresco.ui.common.ControllerListener2.Extras
- Direction
- fresco.vito.core uses fresco.ui.common.ControllerListener2, so a change to fresco.ui.common.ControllerListener2 can break fresco.vito.core, while a change to fresco.vito.core can't break fresco.ui.common.ControllerListener2.
- Position
- Below the diagonal: fresco.vito.core uses a module listed above it, which is the healthy direction.
34→10 fresco.vito.core uses fresco.ui.common✕
- Connections
- 10 pairs of types, where a type in fresco.vito.core uses a type in fresco.ui.common.
- The types involved
com.facebook.fresco.vito.core.CombinedImageListener→com.facebook.fresco.ui.common.ControllerListener2com.facebook.fresco.vito.core.CombinedImageListener→com.facebook.fresco.ui.common.ImagePerfNotifiercom.facebook.fresco.vito.core.ComposedImagePerfLoggingListener→com.facebook.fresco.ui.common.ControllerListener2com.facebook.fresco.vito.core.ComposedImagePerfLoggingListener→com.facebook.fresco.ui.common.VisibilityAwarecom.facebook.fresco.vito.core.FrescoController2→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.fresco.vito.core.FrescoController2→com.facebook.fresco.ui.common.OnFadeListenercom.facebook.fresco.vito.core.FrescoDrawableInterface→com.facebook.fresco.ui.common.VisibilityAwarecom.facebook.fresco.vito.core.ImagePerfLoggingListener→com.facebook.fresco.ui.common.ControllerListener2com.facebook.fresco.vito.core.ImagePerfLoggingListener→com.facebook.fresco.ui.common.PrefetchDatacom.facebook.fresco.vito.core.ImagePerfLoggingListener→com.facebook.fresco.ui.common.VisibilityAware
- Direction
- fresco.vito.core uses fresco.ui.common, so a change to fresco.ui.common can break fresco.vito.core, while a change to fresco.vito.core can't break fresco.ui.common.
- Position
- Below the diagonal: fresco.vito.core uses a module listed above it, which is the healthy direction.
34→14 fresco.vito.core uses drawee.drawable✕
- Connections
- 1 pair of types, where a type in fresco.vito.core uses a type in drawee.drawable.
- The types involved
com.facebook.fresco.vito.core.FrescoDrawableInterface→com.facebook.drawee.drawable.VisibilityCallback
- Direction
- fresco.vito.core uses drawee.drawable, so a change to drawee.drawable can break fresco.vito.core, while a change to fresco.vito.core can't break drawee.drawable.
- Position
- Below the diagonal: fresco.vito.core uses a module listed above it, which is the healthy direction.
34→15 fresco.vito.core uses fresco.vito.listener✕
- Connections
- 3 pairs of types, where a type in fresco.vito.core uses a type in fresco.vito.listener.
- The types involved
com.facebook.fresco.vito.core.CombinedImageListener→com.facebook.fresco.vito.listener.ImageListenercom.facebook.fresco.vito.core.FrescoController2→com.facebook.fresco.vito.listener.ImageListenercom.facebook.fresco.vito.core.FrescoDrawableInterface→com.facebook.fresco.vito.listener.ImageListener
- Direction
- fresco.vito.core uses fresco.vito.listener, so a change to fresco.vito.listener can break fresco.vito.core, while a change to fresco.vito.core can't break fresco.vito.listener.
- Position
- Below the diagonal: fresco.vito.core uses a module listed above it, which is the healthy direction.
34→18 fresco.vito.core uses fresco.vito.source✕
- Connections
- 3 pairs of types, where a type in fresco.vito.core uses a type in fresco.vito.source.
- The types involved
com.facebook.fresco.vito.core.ImagePipelineUtils→com.facebook.fresco.vito.source.SingleImageSourcecom.facebook.fresco.vito.core.VitoImagePipeline→com.facebook.fresco.vito.source.ImageSourcecom.facebook.fresco.vito.core.VitoImageRequest→com.facebook.fresco.vito.source.ImageSource
- Direction
- fresco.vito.core uses fresco.vito.source, so a change to fresco.vito.source can break fresco.vito.core, while a change to fresco.vito.core can't break fresco.vito.source.
- Position
- Below the diagonal: fresco.vito.core uses a module listed above it, which is the healthy direction.
34→21 fresco.vito.core uses fresco.urimod✕
- Connections
- 3 pairs of types, where a type in fresco.vito.core uses a type in fresco.urimod.
- The types involved
com.facebook.fresco.vito.core.VitoImagePipeline→com.facebook.fresco.urimod.Dimensionscom.facebook.fresco.vito.core.VitoImagePipeline→com.facebook.fresco.urimod.FetchStrategycom.facebook.fresco.vito.core.VitoImageRequest→com.facebook.fresco.urimod.Dimensions
- Direction
- fresco.vito.core uses fresco.urimod, so a change to fresco.urimod can break fresco.vito.core, while a change to fresco.vito.core can't break fresco.urimod.
- Position
- Below the diagonal: fresco.vito.core uses a module listed above it, which is the healthy direction.
34→30 fresco.vito.core uses fresco.vito.options✕
- Connections
- 7 pairs of types, where a type in fresco.vito.core uses a type in fresco.vito.options.
- The types involved
com.facebook.fresco.vito.core.FrescoVitoPrefetcher→com.facebook.fresco.vito.options.DecodedImageOptionscom.facebook.fresco.vito.core.FrescoVitoPrefetcher→com.facebook.fresco.vito.options.EncodedImageOptionscom.facebook.fresco.vito.core.FrescoVitoPrefetcher→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.ImagePipelineUtils→com.facebook.fresco.vito.options.DecodedImageOptionscom.facebook.fresco.vito.core.ImagePipelineUtils→com.facebook.fresco.vito.options.EncodedImageOptionscom.facebook.fresco.vito.core.VitoImagePipeline→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.VitoImageRequest→com.facebook.fresco.vito.options.ImageOptions
- Direction
- fresco.vito.core uses fresco.vito.options, so a change to fresco.vito.options can break fresco.vito.core, while a change to fresco.vito.core can't break fresco.vito.options.
- Position
- Below the diagonal: fresco.vito.core uses a module listed above it, which is the healthy direction.
35→30 fresco.animation.bitmap uses fresco.vito.options✕
- Connections
- 2 pairs of types, where a type in fresco.animation.bitmap uses a type in fresco.vito.options.
- The types involved
com.facebook.fresco.animation.bitmap.BitmapAnimationBackend→com.facebook.fresco.vito.options.AnimatedOptionscom.facebook.fresco.animation.bitmap.BitmapAnimationBackend→com.facebook.fresco.vito.options.RoundingOptions
- Direction
- fresco.animation.bitmap uses fresco.vito.options, so a change to fresco.vito.options can break fresco.animation.bitmap, while a change to fresco.animation.bitmap can't break fresco.vito.options.
- Position
- Below the diagonal: fresco.animation.bitmap uses a module listed above it, which is the healthy direction.
35→34 fresco.animation.bitmap uses fresco.vito.core✕
- Connections
- 2 pairs of types, where a type in fresco.animation.bitmap uses a type in fresco.vito.core.
- The types involved
com.facebook.fresco.animation.bitmap.BitmapAnimationBackend→com.facebook.fresco.vito.core.AnimatedImagePerfLoggingListenercom.facebook.fresco.animation.bitmap.BitmapAnimationBackend→com.facebook.fresco.vito.core.FrescoDrawableInterface
- Direction
- fresco.animation.bitmap uses fresco.vito.core, so a change to fresco.vito.core can break fresco.animation.bitmap, while a change to fresco.animation.bitmap can't break fresco.vito.core.
- Position
- Below the diagonal: fresco.animation.bitmap uses a module listed above it, which is the healthy direction.
36→5 fresco.vito.core.impl.debug uses fresco.ui.common.ControllerListener2✕
- Connections
- 9 pairs of types, where a type in fresco.vito.core.impl.debug uses a type in fresco.ui.common.ControllerListener2.
- The types involved
com.facebook.fresco.vito.core.impl.debug.BaseDebugOverlayFactory2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.DebugDataProviderKt→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.DebugOverlayFactory2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.DefaultDebugOverlayFactory2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.FrescoDrawable2DebugDataProvidersKt→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.LightweightDebugOverlayFactory2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.NoOpDebugOverlayFactory2→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.StringAndColorDebugDataProvider→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.debug.StringDebugDataProvider→com.facebook.fresco.ui.common.ControllerListener2.Extras
- Direction
- fresco.vito.core.impl.debug uses fresco.ui.common.ControllerListener2, so a change to fresco.ui.common.ControllerListener2 can break fresco.vito.core.impl.debug, while a change to fresco.vito.core.impl.debug can't break fresco.ui.common.ControllerListener2.
- Position
- Below the diagonal: fresco.vito.core.impl.debug uses a module listed above it, which is the healthy direction.
36→34 fresco.vito.core.impl.debug uses fresco.vito.core✕
- Connections
- 5 pairs of types, where a type in fresco.vito.core.impl.debug uses a type in fresco.vito.core.
- The types involved
com.facebook.fresco.vito.core.impl.debug.BaseDebugOverlayFactory2→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.core.impl.debug.DefaultDebugOverlayFactory2→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.core.impl.debug.DefaultDebugOverlayFactory2→com.facebook.fresco.vito.core.VitoImageRequestcom.facebook.fresco.vito.core.impl.debug.StringAndColorDebugDataProvider→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.core.impl.debug.StringDebugDataProvider→com.facebook.fresco.vito.core.FrescoDrawableInterface
- Direction
- fresco.vito.core.impl.debug uses fresco.vito.core, so a change to fresco.vito.core can break fresco.vito.core.impl.debug, while a change to fresco.vito.core.impl.debug can't break fresco.vito.core.
- Position
- Below the diagonal: fresco.vito.core.impl.debug uses a module listed above it, which is the healthy direction.
36→39 fresco.vito.core.impl.debug uses fresco.vito.core.impl part of a loop✕
- Connections
- 4 pairs of types, where a type in fresco.vito.core.impl.debug uses a type in fresco.vito.core.impl.
- The types involved
com.facebook.fresco.vito.core.impl.debug.BaseDebugOverlayFactory2→com.facebook.fresco.vito.core.impl.FrescoDrawable2com.facebook.fresco.vito.core.impl.debug.DebugOverlayFactory2→com.facebook.fresco.vito.core.impl.FrescoDrawable2com.facebook.fresco.vito.core.impl.debug.LightweightDebugOverlayFactory2→com.facebook.fresco.vito.core.impl.FrescoDrawable2com.facebook.fresco.vito.core.impl.debug.NoOpDebugOverlayFactory2→com.facebook.fresco.vito.core.impl.FrescoDrawable2
- Direction
- fresco.vito.core.impl.debug uses fresco.vito.core.impl, so a change to fresco.vito.core.impl can break fresco.vito.core.impl.debug, while a change to fresco.vito.core.impl.debug can't break fresco.vito.core.impl.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
37→10 fresco.vito.litho uses fresco.ui.common✕
- Connections
- 2 pairs of types, where a type in fresco.vito.litho uses a type in fresco.ui.common.
- The types involved
com.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.fresco.ui.common.OnFadeListenercom.facebook.fresco.vito.litho.FrescoVitoTapToRetryImageSpec→com.facebook.fresco.ui.common.OnFadeListener
- Direction
- fresco.vito.litho uses fresco.ui.common, so a change to fresco.ui.common can break fresco.vito.litho, while a change to fresco.vito.litho can't break fresco.ui.common.
- Position
- Below the diagonal: fresco.vito.litho uses a module listed above it, which is the healthy direction.
37→14 fresco.vito.litho uses drawee.drawable✕
- Connections
- 1 pair of types, where a type in fresco.vito.litho uses a type in drawee.drawable.
- The types involved
com.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.drawee.drawable.Viewport
- Direction
- fresco.vito.litho uses drawee.drawable, so a change to drawee.drawable can break fresco.vito.litho, while a change to fresco.vito.litho can't break drawee.drawable.
- Position
- Below the diagonal: fresco.vito.litho uses a module listed above it, which is the healthy direction.
37→15 fresco.vito.litho uses fresco.vito.listener✕
- Connections
- 2 pairs of types, where a type in fresco.vito.litho uses a type in fresco.vito.listener.
- The types involved
com.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.fresco.vito.listener.ImageListenercom.facebook.fresco.vito.litho.FrescoVitoTapToRetryImageSpec→com.facebook.fresco.vito.listener.ImageListener
- Direction
- fresco.vito.litho uses fresco.vito.listener, so a change to fresco.vito.listener can break fresco.vito.litho, while a change to fresco.vito.litho can't break fresco.vito.listener.
- Position
- Below the diagonal: fresco.vito.litho uses a module listed above it, which is the healthy direction.
37→18 fresco.vito.litho uses fresco.vito.source✕
- Connections
- 2 pairs of types, where a type in fresco.vito.litho uses a type in fresco.vito.source.
- The types involved
com.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.fresco.vito.source.ImageSourcecom.facebook.fresco.vito.litho.FrescoVitoTapToRetryImageSpec→com.facebook.fresco.vito.source.ImageSource
- Direction
- fresco.vito.litho uses fresco.vito.source, so a change to fresco.vito.source can break fresco.vito.litho, while a change to fresco.vito.litho can't break fresco.vito.source.
- Position
- Below the diagonal: fresco.vito.litho uses a module listed above it, which is the healthy direction.
37→21 fresco.vito.litho uses fresco.urimod✕
- Connections
- 1 pair of types, where a type in fresco.vito.litho uses a type in fresco.urimod.
- The types involved
com.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.fresco.urimod.FetchStrategy
- Direction
- fresco.vito.litho uses fresco.urimod, so a change to fresco.urimod can break fresco.vito.litho, while a change to fresco.vito.litho can't break fresco.urimod.
- Position
- Below the diagonal: fresco.vito.litho uses a module listed above it, which is the healthy direction.
37→30 fresco.vito.litho uses fresco.vito.options✕
- Connections
- 2 pairs of types, where a type in fresco.vito.litho uses a type in fresco.vito.options.
- The types involved
com.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.litho.FrescoVitoTapToRetryImageSpec→com.facebook.fresco.vito.options.ImageOptions
- Direction
- fresco.vito.litho uses fresco.vito.options, so a change to fresco.vito.options can break fresco.vito.litho, while a change to fresco.vito.litho can't break fresco.vito.options.
- Position
- Below the diagonal: fresco.vito.litho uses a module listed above it, which is the healthy direction.
37→34 fresco.vito.litho uses fresco.vito.core✕
- Connections
- 2 pairs of types, where a type in fresco.vito.litho uses a type in fresco.vito.core.
- The types involved
com.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.litho.FrescoVitoImage2Spec→com.facebook.fresco.vito.core.VitoImageRequest
- Direction
- fresco.vito.litho uses fresco.vito.core, so a change to fresco.vito.core can break fresco.vito.litho, while a change to fresco.vito.litho can't break fresco.vito.core.
- Position
- Below the diagonal: fresco.vito.litho uses a module listed above it, which is the healthy direction.
38→24 fresco.animation.factory uses imagepipeline.core✕
- Connections
- 1 pair of types, where a type in fresco.animation.factory uses a type in imagepipeline.core.
- The types involved
com.facebook.fresco.animation.factory.AnimatedFactoryV2Impl→com.facebook.imagepipeline.core.ExecutorSupplier
- Direction
- fresco.animation.factory uses imagepipeline.core, so a change to imagepipeline.core can break fresco.animation.factory, while a change to fresco.animation.factory can't break imagepipeline.core.
- Position
- Below the diagonal: fresco.animation.factory uses a module listed above it, which is the healthy direction.
38→30 fresco.animation.factory uses fresco.vito.options✕
- Connections
- 2 pairs of types, where a type in fresco.animation.factory uses a type in fresco.vito.options.
- The types involved
com.facebook.fresco.animation.factory.DefaultBitmapAnimationDrawableFactory→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.animation.factory.DefaultBitmapAnimationDrawableFactory→com.facebook.fresco.vito.options.ImageOptionsDrawableFactory
- Direction
- fresco.animation.factory uses fresco.vito.options, so a change to fresco.vito.options can break fresco.animation.factory, while a change to fresco.animation.factory can't break fresco.vito.options.
- Position
- Below the diagonal: fresco.animation.factory uses a module listed above it, which is the healthy direction.
38→34 fresco.animation.factory uses fresco.vito.core✕
- Connections
- 2 pairs of types, where a type in fresco.animation.factory uses a type in fresco.vito.core.
- The types involved
com.facebook.fresco.animation.factory.AnimatedFactoryV2Impl→com.facebook.fresco.vito.core.AnimatedImagePerfLoggingListenercom.facebook.fresco.animation.factory.DefaultBitmapAnimationDrawableFactory→com.facebook.fresco.vito.core.AnimatedImagePerfLoggingListener
- Direction
- fresco.animation.factory uses fresco.vito.core, so a change to fresco.vito.core can break fresco.animation.factory, while a change to fresco.animation.factory can't break fresco.vito.core.
- Position
- Below the diagonal: fresco.animation.factory uses a module listed above it, which is the healthy direction.
38→35 fresco.animation.factory uses fresco.animation.bitmap✕
- Connections
- 2 pairs of types, where a type in fresco.animation.factory uses a type in fresco.animation.bitmap.
- The types involved
com.facebook.fresco.animation.factory.DefaultBitmapAnimationDrawableFactory→com.facebook.fresco.animation.bitmap.BitmapFrameCachecom.facebook.fresco.animation.factory.DefaultBitmapAnimationDrawableFactory→com.facebook.fresco.animation.bitmap.BitmapFrameRenderer
- Direction
- fresco.animation.factory uses fresco.animation.bitmap, so a change to fresco.animation.bitmap can break fresco.animation.factory, while a change to fresco.animation.factory can't break fresco.animation.bitmap.
- Position
- Below the diagonal: fresco.animation.factory uses a module listed above it, which is the healthy direction.
39→4 fresco.vito.core.impl uses drawee.components✕
- Connections
- 1 pair of types, where a type in fresco.vito.core.impl uses a type in drawee.components.
- The types involved
com.facebook.fresco.vito.core.impl.ImageReleaseScheduler→com.facebook.drawee.components.DeferredReleaser
- Direction
- fresco.vito.core.impl uses drawee.components, so a change to drawee.components can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break drawee.components.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→5 fresco.vito.core.impl uses fresco.ui.common.ControllerListener2✕
- Connections
- 6 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.ui.common.ControllerListener2.
- The types involved
com.facebook.fresco.vito.core.impl.BitmapPreparingImageFetchSubscriber→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.DebugDataProviderKt→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.ExtrasUtilsKt→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.ui.common.ControllerListener2.Extrascom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.fresco.ui.common.ControllerListener2.Extras
- Direction
- fresco.vito.core.impl uses fresco.ui.common.ControllerListener2, so a change to fresco.ui.common.ControllerListener2 can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.ui.common.ControllerListener2.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→10 fresco.vito.core.impl uses fresco.ui.common✕
- Connections
- 7 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.ui.common.
- The types involved
com.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.ui.common.ControllerListener2com.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.ui.common.ImagePerfNotifiercom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.ui.common.OnFadeListenercom.facebook.fresco.vito.core.impl.KFrescoController→com.facebook.fresco.ui.common.ImagePerfDataListenercom.facebook.fresco.vito.core.impl.KFrescoController→com.facebook.fresco.ui.common.OnFadeListenercom.facebook.fresco.vito.core.impl.KFrescoVitoDrawable→com.facebook.fresco.ui.common.OnFadeListener
- Direction
- fresco.vito.core.impl uses fresco.ui.common, so a change to fresco.ui.common can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.ui.common.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→14 fresco.vito.core.impl uses drawee.drawable✕
- Connections
- 9 pairs of types, where a type in fresco.vito.core.impl uses a type in drawee.drawable.
- The types involved
com.facebook.fresco.vito.core.impl.FrescoDrawable2→com.facebook.drawee.drawable.FadeDrawablecom.facebook.fresco.vito.core.impl.FrescoDrawable2→com.facebook.drawee.drawable.ScaleTypeDrawablecom.facebook.fresco.vito.core.impl.FrescoDrawable2→com.facebook.drawee.drawable.TransformAwareDrawablecom.facebook.fresco.vito.core.impl.FrescoDrawable2→com.facebook.drawee.drawable.TransformCallbackcom.facebook.fresco.vito.core.impl.FrescoDrawable2→com.facebook.drawee.drawable.VisibilityCallbackcom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.drawee.drawable.ScaleTypeDrawablecom.facebook.fresco.vito.core.impl.Hierarcher→com.facebook.drawee.drawable.ScaleTypeDrawablecom.facebook.fresco.vito.core.impl.HierarcherImpl→com.facebook.drawee.drawable.ScaleTypeDrawablecom.facebook.fresco.vito.core.impl.KFrescoVitoDrawable→com.facebook.drawee.drawable.VisibilityCallback
- Direction
- fresco.vito.core.impl uses drawee.drawable, so a change to drawee.drawable can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break drawee.drawable.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→15 fresco.vito.core.impl uses fresco.vito.listener✕
- Connections
- 5 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.vito.listener.
- The types involved
com.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.vito.listener.ImageListenercom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.listener.ImageListenercom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.fresco.vito.listener.ImageListenercom.facebook.fresco.vito.core.impl.KFrescoController→com.facebook.fresco.vito.listener.ImageListenercom.facebook.fresco.vito.core.impl.KFrescoVitoDrawable→com.facebook.fresco.vito.listener.ImageListener
- Direction
- fresco.vito.core.impl uses fresco.vito.listener, so a change to fresco.vito.listener can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.vito.listener.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→18 fresco.vito.core.impl uses fresco.vito.source✕
- Connections
- 2 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.vito.source.
- The types involved
com.facebook.fresco.vito.core.impl.ImageSourceToImagePipelineAdapter→com.facebook.fresco.vito.source.ImageSourcecom.facebook.fresco.vito.core.impl.VitoImagePipelineImpl→com.facebook.fresco.vito.source.ImageSource
- Direction
- fresco.vito.core.impl uses fresco.vito.source, so a change to fresco.vito.source can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.vito.source.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→21 fresco.vito.core.impl uses fresco.urimod✕
- Connections
- 3 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.urimod.
- The types involved
com.facebook.fresco.vito.core.impl.ImageSourceToImagePipelineAdapter→com.facebook.fresco.urimod.Dimensionscom.facebook.fresco.vito.core.impl.VitoImagePipelineImpl→com.facebook.fresco.urimod.Dimensionscom.facebook.fresco.vito.core.impl.VitoImagePipelineImpl→com.facebook.fresco.urimod.FetchStrategy
- Direction
- fresco.vito.core.impl uses fresco.urimod, so a change to fresco.urimod can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.urimod.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→24 fresco.vito.core.impl uses imagepipeline.core✕
- Connections
- 3 pairs of types, where a type in fresco.vito.core.impl uses a type in imagepipeline.core.
- The types involved
com.facebook.fresco.vito.core.impl.FrescoVitoPrefetcherImpl→com.facebook.imagepipeline.core.ImagePipelinecom.facebook.fresco.vito.core.impl.ImageSourceToImagePipelineAdapter→com.facebook.imagepipeline.core.ImagePipelinecom.facebook.fresco.vito.core.impl.VitoImagePipelineImpl→com.facebook.imagepipeline.core.ImagePipeline
- Direction
- fresco.vito.core.impl uses imagepipeline.core, so a change to imagepipeline.core can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break imagepipeline.core.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→30 fresco.vito.core.impl uses fresco.vito.options✕
- Connections
- 23 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.vito.options.
- The types involved
com.facebook.fresco.vito.core.impl.ActualImageHandlerKt→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.BackgroundLayerHandlerKt→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.BitmapPreparingImageFetchSubscriber→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.DefaultImageDecodeOptionsProviderImpl→com.facebook.fresco.vito.options.DecodedImageOptionscom.facebook.fresco.vito.core.impl.FrescoVitoPrefetcherImpl→com.facebook.fresco.vito.options.DecodedImageOptionscom.facebook.fresco.vito.core.impl.FrescoVitoPrefetcherImpl→com.facebook.fresco.vito.options.EncodedImageOptionscom.facebook.fresco.vito.core.impl.FrescoVitoPrefetcherImpl→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.Hierarcher→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.HierarcherImpl→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.HierarcherImpl→com.facebook.fresco.vito.options.ImageOptionsDrawableFactorycom.facebook.fresco.vito.core.impl.ImageFetchSubscriber→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.ImageLayerDataModel→com.facebook.fresco.vito.options.BorderOptionscom.facebook.fresco.vito.core.impl.ImageLayerDataModel→com.facebook.fresco.vito.options.RoundingOptionscom.facebook.fresco.vito.core.impl.ImagePipelineUtilsImpl→com.facebook.fresco.vito.options.DecodedImageOptionscom.facebook.fresco.vito.core.impl.ImagePipelineUtilsImpl→com.facebook.fresco.vito.options.EncodedImageOptionscom.facebook.fresco.vito.core.impl.ImageSourceToImagePipelineAdapter→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.KFrescoController→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.KFrescoController→com.facebook.fresco.vito.options.ImageOptionsDrawableFactorycom.facebook.fresco.vito.core.impl.NoOpFrescoVitoPrefetcher→com.facebook.fresco.vito.options.DecodedImageOptionscom.facebook.fresco.vito.core.impl.NoOpFrescoVitoPrefetcher→com.facebook.fresco.vito.options.EncodedImageOptionscom.facebook.fresco.vito.core.impl.NoOpFrescoVitoPrefetcher→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.ProgressLayerHandlerKt→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.core.impl.VitoImagePipelineImpl→com.facebook.fresco.vito.options.ImageOptions
- Direction
- fresco.vito.core.impl uses fresco.vito.options, so a change to fresco.vito.options can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.vito.options.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→34 fresco.vito.core.impl uses fresco.vito.core✕
- Connections
- 51 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.vito.core. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
com.facebook.fresco.vito.core.impl.BaseVitoImagePerfListener→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.core.impl.BaseVitoImagePerfListener→com.facebook.fresco.vito.core.VitoImagePerfListenercom.facebook.fresco.vito.core.impl.BitmapPreparingImageFetchSubscriber→com.facebook.fresco.vito.core.VitoImageRequestcom.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.vito.core.CombinedImageListenercom.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.vito.core.ImagePerfLoggingListenercom.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.vito.core.VitoImageRequestcom.facebook.fresco.vito.core.impl.CombinedImageListenerImpl→com.facebook.fresco.vito.core.VitoImageRequestListenercom.facebook.fresco.vito.core.impl.DebugDataProviderKt→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.core.impl.DrawableDataSubscriber→com.facebook.fresco.vito.core.VitoImageRequestcom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.FrescoController2com.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.FrescoVitoConfigcom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.ImagePerfLoggingListenercom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.VitoImagePerfListenercom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.VitoImagePipelinecom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.VitoImageRequestcom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.VitoImageRequestListenercom.facebook.fresco.vito.core.impl.FrescoDrawable2→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.fresco.vito.core.CombinedImageListenercom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.fresco.vito.core.ImagePerfLoggingListenercom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.fresco.vito.core.VitoImagePerfListenercom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.fresco.vito.core.VitoImageRequestcom.facebook.fresco.vito.core.impl.FrescoDrawable2Impl→com.facebook.fresco.vito.core.VitoImageRequestListenercom.facebook.fresco.vito.core.impl.FrescoVitoPrefetcherImpl→com.facebook.fresco.vito.core.FrescoVitoPrefetchercom.facebook.fresco.vito.core.impl.FrescoVitoPrefetcherImpl→com.facebook.fresco.vito.core.ImagePipelineUtils
- Direction
- fresco.vito.core.impl uses fresco.vito.core, so a change to fresco.vito.core can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.vito.core.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
39→36 fresco.vito.core.impl uses fresco.vito.core.impl.debug✕
- Connections
- 7 pairs of types, where a type in fresco.vito.core.impl uses a type in fresco.vito.core.impl.debug.
- The types involved
com.facebook.fresco.vito.core.impl.DebugDataProviderKt→com.facebook.fresco.vito.core.impl.debug.ImageFitRatioConfigcom.facebook.fresco.vito.core.impl.DebugDataProviderKt→com.facebook.fresco.vito.core.impl.debug.StringAndColorDebugDataProvidercom.facebook.fresco.vito.core.impl.DebugDataProviderKt→com.facebook.fresco.vito.core.impl.debug.StringDebugDataProvidercom.facebook.fresco.vito.core.impl.DebugOverlayHandler→com.facebook.fresco.vito.core.impl.debug.DebugDataProvidercom.facebook.fresco.vito.core.impl.DebugOverlayHandler→com.facebook.fresco.vito.core.impl.debug.DebugOverlayDrawablecom.facebook.fresco.vito.core.impl.DebugOverlayHandler→com.facebook.fresco.vito.core.impl.debug.LightweightDebugOverlayDrawablecom.facebook.fresco.vito.core.impl.FrescoController2Impl→com.facebook.fresco.vito.core.impl.debug.DebugOverlayFactory2
- Direction
- fresco.vito.core.impl uses fresco.vito.core.impl.debug, so a change to fresco.vito.core.impl.debug can break fresco.vito.core.impl, while a change to fresco.vito.core.impl can't break fresco.vito.core.impl.debug.
- Position
- Below the diagonal: fresco.vito.core.impl uses a module listed above it, which is the healthy direction.
40→18 fresco.vito.tools.liveeditor uses fresco.vito.source✕
- Connections
- 2 pairs of types, where a type in fresco.vito.tools.liveeditor uses a type in fresco.vito.source.
- The types involved
com.facebook.fresco.vito.tools.liveeditor.ImageLiveEditor→com.facebook.fresco.vito.source.ImageSourcecom.facebook.fresco.vito.tools.liveeditor.ImageSourceSampleValues→com.facebook.fresco.vito.source.ImageSource
- Direction
- fresco.vito.tools.liveeditor uses fresco.vito.source, so a change to fresco.vito.source can break fresco.vito.tools.liveeditor, while a change to fresco.vito.tools.liveeditor can't break fresco.vito.source.
- Position
- Below the diagonal: fresco.vito.tools.liveeditor uses a module listed above it, which is the healthy direction.
40→30 fresco.vito.tools.liveeditor uses fresco.vito.options✕
- Connections
- 5 pairs of types, where a type in fresco.vito.tools.liveeditor uses a type in fresco.vito.options.
- The types involved
com.facebook.fresco.vito.tools.liveeditor.ImageLiveEditor→com.facebook.fresco.vito.options.ImageOptionscom.facebook.fresco.vito.tools.liveeditor.ImageOptionsSampleValues→com.facebook.fresco.vito.options.BitmapConfigcom.facebook.fresco.vito.tools.liveeditor.ImageOptionsSampleValues→com.facebook.fresco.vito.options.BorderOptionscom.facebook.fresco.vito.tools.liveeditor.ImageOptionsSampleValues→com.facebook.fresco.vito.options.RoundingOptionscom.facebook.fresco.vito.tools.liveeditor.LiveEditorUiUtils→com.facebook.fresco.vito.options.ImageOptions
- Direction
- fresco.vito.tools.liveeditor uses fresco.vito.options, so a change to fresco.vito.options can break fresco.vito.tools.liveeditor, while a change to fresco.vito.tools.liveeditor can't break fresco.vito.options.
- Position
- Below the diagonal: fresco.vito.tools.liveeditor uses a module listed above it, which is the healthy direction.
40→34 fresco.vito.tools.liveeditor uses fresco.vito.core✕
- Connections
- 9 pairs of types, where a type in fresco.vito.tools.liveeditor uses a type in fresco.vito.core.
- The types involved
com.facebook.fresco.vito.tools.liveeditor.ImageLiveEditor→com.facebook.fresco.vito.core.FrescoController2com.facebook.fresco.vito.tools.liveeditor.ImageLiveEditor→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.tools.liveeditor.ImageLiveEditor→com.facebook.fresco.vito.core.VitoImagePipelinecom.facebook.fresco.vito.tools.liveeditor.ImageLiveEditor→com.facebook.fresco.vito.core.VitoImageRequestcom.facebook.fresco.vito.tools.liveeditor.ImageSelector→com.facebook.fresco.vito.core.FrescoController2com.facebook.fresco.vito.tools.liveeditor.ImageSelector→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.tools.liveeditor.ImageSelector→com.facebook.fresco.vito.core.VitoImagePipelinecom.facebook.fresco.vito.tools.liveeditor.ImageTracker→com.facebook.fresco.vito.core.FrescoDrawableInterfacecom.facebook.fresco.vito.tools.liveeditor.LiveEditorOnScreenButtonController→com.facebook.fresco.vito.core.FrescoDrawableInterface
- Direction
- fresco.vito.tools.liveeditor uses fresco.vito.core, so a change to fresco.vito.core can break fresco.vito.tools.liveeditor, while a change to fresco.vito.tools.liveeditor can't break fresco.vito.core.
- Position
- Below the diagonal: fresco.vito.tools.liveeditor uses a module listed above it, which is the healthy direction.
40→36 fresco.vito.tools.liveeditor uses fresco.vito.core.impl.debug✕
- Connections
- 2 pairs of types, where a type in fresco.vito.tools.liveeditor uses a type in fresco.vito.core.impl.debug.
- The types involved
com.facebook.fresco.vito.tools.liveeditor.LiveEditorOnScreenButtonController→com.facebook.fresco.vito.core.impl.debug.StringDebugDataProvidercom.facebook.fresco.vito.tools.liveeditor.LiveEditorUiUtils→com.facebook.fresco.vito.core.impl.debug.StringDebugDataProvider
- Direction
- fresco.vito.tools.liveeditor uses fresco.vito.core.impl.debug, so a change to fresco.vito.core.impl.debug can break fresco.vito.tools.liveeditor, while a change to fresco.vito.tools.liveeditor can't break fresco.vito.core.impl.debug.
- Position
- Below the diagonal: fresco.vito.tools.liveeditor uses a module listed above it, which is the healthy direction.
40→39 fresco.vito.tools.liveeditor uses fresco.vito.core.impl✕
- Connections
- 1 pair of types, where a type in fresco.vito.tools.liveeditor uses a type in fresco.vito.core.impl.
- The types involved
com.facebook.fresco.vito.tools.liveeditor.ImageTracker→com.facebook.fresco.vito.core.impl.BaseVitoImagePerfListener
- Direction
- fresco.vito.tools.liveeditor uses fresco.vito.core.impl, so a change to fresco.vito.core.impl can break fresco.vito.tools.liveeditor, while a change to fresco.vito.tools.liveeditor can't break fresco.vito.core.impl.
- Position
- Below the diagonal: fresco.vito.tools.liveeditor uses a module listed above it, which is the healthy direction.
At a glance — Code Health
At a glance — Architecture
At a glance — Maturity
At a glance — Readiness
At a glance — Security
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A07:2025 — Authentication Failures | 24 | High / Critical |
| A05:2025 — Injection | 14 | High / Critical |
| A03:2025 — Software Supply Chain Failures | 7 | Medium |
Roadmap
Begin by documenting significant design decisions in a centralized ADR folder and resolving the 22 high-severity secrets found in the repository history. Next, integrate a SAST step into the CI pipeline to automatically block security regressions, and address the 122 orphaned files to improve codebase freshness. Finally, optimize allocation hygiene on hot paths by adopting idioms that reduce unnecessary object creation.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Record your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them. | +3.9 pts | Medium | Architecture documentation |
| Resolve the 22 High secret finding(s) in Secrets (history) — start with REDACTED (22). | +3.2 pts | Medium | Secrets (history) |
| Resolve the 2 Orphaned knowledge finding(s) in Knowledge Freshness — start with GenericDraweeHierarchy.java, GenericDraweeHierarchyBuilder.java. | +1.3 pts | Low | Knowledge Freshness |
| Add a SAST step to CI running what this repository's stack ships: spotbugs with find-sec-bugs — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing. | +2.5 pts | Medium | Security & performance tooling |
| Resolve the 3 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED, REDACTED, REDACTED. | +1.1 pts | Low | Supply-chain Provenance & Signing |
| Raise allocation-aware density on the hot paths — currently 158 use(s) across 91,143 production line(s) (~1.7/1k). More of the idioms below on the allocation-heavy paths climbs this toward 10. | +1.8 pts | Medium | Allocation hygiene |
| Reconcile the README with reality: docs/_docs/animations.md links to `index.html`, but `docs/_docs/index.html` does not exist; docs/_docs/animations.md links to `image-requests.html`, but `docs/_docs/image-requests.html` does not exist; docs/_docs/building-from-source.md links to `index.html#_`, but `docs/_docs/index.html` does not exist; docs/_docs/caching.md links to `modifying-image.html`, but `docs/_docs/modifying-image.html` does not exist; docs/_docs/caching.md links to `customizing-image-formats.html`, but `docs/_docs/customizing-image-formats.html` does not exist. | +1.8 pts | Medium | Documentation accuracy |
| Resolve the 1 REDACTED finding(s) in Secrets (history) — start with REDACTED. | +0.7 pts | Low | Secrets (history) |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 2.5 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 2.7 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 3.7 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 4.4 | Mixed | Secrets (history): High secret: REDACTED |
| REDACTED | 4.4 | Mixed | Secrets (history): High secret: REDACTED |
| REDACTED | 4.5 | Mixed | Secrets (history): High secret: REDACTED |
| vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt | 5.6 | Mixed | Cyclomatic Complexity: FrescoController2Impl.fetch (cyclomatic 26) |
| vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt | 6.0 | Mixed | Explicit Debt: TodoComment |
| vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt | 6.0 | Mixed | Explicit Debt: FixmeComment |
| tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java | 6.0 | Mixed | Explicit Debt: TodoComment |
| imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt | 6.0 | Mixed | Explicit Debt: TodoComment |
| vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/DebugDataProvider.kt | 6.3 | Mixed | Cognitive Complexity: DebugDataProviderKt.createWastedMemoryProvider (cognitive 18) |
| samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/imageformat/pjpeg/ImageFormatProgressiveJpegFragment.java | 6.7 | Mixed | Explicit Debt: TodoComment |
| vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/ImageLayerDataModel.kt | 6.9 | Mixed | Explicit Debt: TodoComment |
| REDACTED | 6.9 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| urimod/src/main/java/com/facebook/fresco/urimod/NopUriModifier.kt | 7.0 | Mixed | Change Coupling: Boundary-crossing change coupling: NopUriModifier.kt ↔ VitoImagePipelineImpl.kt |
| imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalThumbnailBitmapSdk29Producer.java | 7.1 | Mixed | Cognitive Complexity: 1.getResult (cognitive 27) |
| samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/Instrumentation.java | 7.1 | Mixed | Code Duplication: Duplicated block (24 lines × 2) |
| samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableDraweeView.java | 7.1 | Mixed | Code Duplication: Duplicated block (18 lines × 2) |
| imagepipeline/src/main/java/com/facebook/imagepipeline/platform/DefaultRawBitmapDecoder.kt | 7.2 | Mixed | Cyclomatic Complexity: DefaultRawBitmapDecoder.decode (cyclomatic 33) |
How the grades work
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 56 of 60 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 4 documentation/naming judgement(s) are LLM-assisted and labelled advisory. Overall confidence is 0.9 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 60 dimensions across the health lenses
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 420 of 457 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | Local LLM | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D8 Code Coverage — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Coverage NOT MEASURED: test source is present (.java, .kt) but the built-in coverage collector has no runner for this repository's ecosystem — so this suite was never executed by it. Not scored — this is a gap in the analyzer's language coverage, not a defect in the repo. To have real coverage read, produce a coverage report in a standard format (JaCoCo XML — the Gradle `jacocoTestReport` task) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures. You can widen what we reach: optional: produce a coverage report in a standard format (JaCoCo XML — the Gradle `jacocoTestReport` task) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures — then the real number is read on the next scan.
- D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test source is present (.java, .kt) and this repository declares a JVM test suite (repository root, Gradle), but it was not re-run: no test result was produced. Not scored — this is a gap in the analyzer's language coverage, not a finding about this repository.
- D14 License Compliance — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. This repository declares a Gradle build (build.gradle/build.gradle.kts), but the licence verdict published here was taken over its gem dependencies. Nothing was read about its Gradle dependencies' licensing in either direction, and a clean score on this card must not be read as covering them.
- D27 Navigability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check's reader does not cover the language this repository's product is written in, so it had nothing of the product to read. That is a gap in this analyzer's language reach — not a finding about this repository.
- D32 Data Compliance (PII/GDPR) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `animated-base/src/main/java/com/facebook/imagepipeline/animated/factory/AnimatedImageDecoderBase.kt`, `animated-drawable/src/main/java/com/facebook/fresco/animation/drawable/AnimatedDrawable2.kt`, `animated-gif-lite/src/main/java/com/facebook/animated/giflite/drawable/GifAnimationBackend.kt`, `drawee/src/main/java/com/facebook/drawee/components/DeferredReleaser.kt`, `drawee/src/main/java/com/facebook/drawee/drawable/ArrayDrawable.kt`, … (+29 more) produced a parse error, so every rule in this engine's `gdpr.yml` was absent there. That absence is NOT a clean result: these rules detect personal data crossing a boundary into a log sink, a URL or browser storage, and a file that was never parsed cannot report any of the three. The rest of the tree analysed normally and its rows above stand; only these files are unaccounted for. You can widen what we reach: fix the syntax error (or exclude the file deliberately) and re-scan to cover it.
- AXB1 Runtime evidence locked — no reproducible boot — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Subject: a native UI project (animated-base/src/main/AndroidManifest.xml). The Runtime Evidence tier boots an app only via docker-compose, an Aspire AppHost, a Dockerfile, an npm dev script, a web service's own toolchain entry point (cargo, go, dotnet, Python, Spring Boot), or an Android app's own Gradle wrapper (run on an emulator); an Apple or Flutter app needs a host it lacks. None applied, so no live runtime a11y/egress/header evidence was collected. You can widen what we reach: add a docker-compose.yml (or an Aspire AppHost) that brings the app up with its dependencies. Watchdog then boots it in an isolated sandbox and gathers real runtime evidence — you change nothing in your pipeline (no CI step, no SDK).
- C2 Access Controls — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These authorization controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks authorization controls.
- GD1 Unfinished & placeholder code — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, F#, JavaScript/TypeScript, Dart, Ruby and Scala source only, and this repository's Java, Kotlin, Python, c, cpp is most of its product and is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- IC1 Incompleteness & stubs — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, JavaScript/TypeScript, Java, Dart, Ruby and Scala source only, and this repository's Kotlin, Python, c, cpp is most of its product and is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- M4 Documentation accuracy — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 14 further occurrence(s) are not listed individually; the score already reflects all 54.
- P5 DR & Backup — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. No backup/snapshot/replication config, RTO/RPO or restore-procedure documentation was found — and no production persistence was detected either (no data-access packages, no data-store services, no database resources), so there is nothing in this repository whose loss a DR control would recover. If this system's data lives in a platform or ops repo we can't see, that's where the DR evidence belongs.
- S1 Web-Security Posture — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These web-security controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks web-security controls.
- X2 Cancellation propagation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Go, PHP, Dart, Kotlin, Ruby, Scala, Java, Python and Rust source only, and no C# was loaded, and no named async function in this repository's JavaScript/TypeScript, nor any Go, PHP or Dart function or Kotlin suspend function, makes a request that can be cancelled (fetch, axios, ky, ofetch; net/http, net.Dial; amphp; Dio; Ktor, OkHttp), so there is nothing to judge, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
- D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D4 Code Duplication: Duplication is token-similarity — an in-process token-stream comparison over sliding windows, with type-aware normalization — so it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
- D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
- D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
- D13 REDACTED Scanning: REDACTED detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D16 Bus Factor: Bus-factor is a time-decayed model of commit attribution (who has recently, repeatedly worked a file), not comprehension — pairing, review and reading-without-committing spread knowledge it can't see; bot commits and shared accounts still distort it.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D19 Documentation Quality: Documentation quality is judged by an LLM over a bounded sample of docs — it reads what is written, not whether the docs match the running system, and it is advisory, not a measurement. Its critique rows are drawn from a closed category vocabulary and each row means the same thing in every run, so two scans can be compared row by row; the SET that fires is still a sample, and does not repeat exactly. Measured on one frozen input, six scans at one engine SHA: 2-5 critique rows per scan, 8 distinct rows across the six, 3 of those 8 seen in only one scan. So a D19 row is evidence about the documentation, but a COUNT of D19 rows is not a quantity — never read a change in it as an improvement or a regression.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- D22 Internal API Consistency: API-surface coherence is an LLM judgement over a sample of the public surface — consistency of intent across the whole API is approximated, not exhaustively verified.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a Dockerfile (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P4 Deployment & Rollback: Approval/branch-protection rules live in repository settings the scan cannot see — only their in-repo evidence (config files, workflows) is checked, so a control enforced purely in the host's settings reads as "not evidenced".
- P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
The LLM boundary
Dimensions
D1 · Cyclomatic Complexity
13 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was GenericDraweeHierarchyInflater.updateBuilder at 48. A further 1 method(s) were over the threshold but excluded as flat dispatchers (a long switch/match over independent cases: many branches, almost no nesting), the largest being ImageOriginUtils.mapProducerNameToImageOrigin at 18 — they are counted neither in the figure above nor in this dimension's score. 1 file carries no cyclomatic complexity row at all for this reason — every one of its over-threshold methods was excluded, so the exclusion is disclosed nowhere in the file itself: drawee-backends/drawee-pipeline/src/main/java/com/facebook/drawee/backends/pipeline/info/ImageOriginUtils.java (ImageOriginUtils.mapProducerNameToImageOrigin at 18). They are named here because the per-file figures other dimensions report are taken BEFORE this exclusion, so such a file can show a high maximum complexity elsewhere in this report and nothing here, with nothing to reconcile the two.
What to do
- Bring the 13 bodies over 15 down to 15 or less in Cyclomatic Complexity — start with GenericDraweeHierarchyInflater.updateBuilder (cyclomatic 48), VitoViewInflater.inflateImageOptionsBuilder (cyclomatic 37), DefaultRawBitmapDecoder.decode (cyclomatic 33). — This score is capped by its worst body, so a finding fixed alone moves it by almost nothing — the next one down takes its place. Refactoring these 13 together lifts Cyclomatic Complexity from 7.7 to about 10.0/10, projected with the scoring formula itself and assuming each lands exactly at 15.
- Enforce Cyclomatic Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D2 · Cognitive Complexity
33 method(s) exceeded the cognitive complexity threshold of 15; the worst was GenericDraweeHierarchyInflater.updateBuilder at 56.
What to do
- Bring the 33 bodies over 15 down to 15 or less in Cognitive Complexity — start with GenericDraweeHierarchyInflater.updateBuilder (cognitive 56), VitoViewInflater.inflateImageOptionsBuilder (cognitive 51), DefaultRawBitmapDecoder.decode (cognitive 45). — This score is capped by its worst body, so a finding fixed alone moves it by almost nothing — the next one down takes its place. Refactoring these 33 together lifts Cognitive Complexity from 6.6 to about 10.0/10, projected with the scoring formula itself and assuming each lands exactly at 15.
- Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D3 · God Classes
46 god class(es) detected.
What to do
- Resolve the 26 TooManyMethods finding(s) in God Classes — start with FLog.kt, ImagePipeline.kt, AbstractDraweeController.java. — One of this dimension's main actionable groups (26 warning-level).
- Resolve the 9 ClassTooLong finding(s) in God Classes — start with ImagePipeline.kt, AbstractDraweeController.java, DiskStorageCache.kt. — One of this dimension's main actionable groups (9 warning-level).
- Resolve the 7 MethodTooLong finding(s) in God Classes — start with FrescoFlipperPlugin.java, FrescoController2Impl.kt, KFrescoController.kt. — One of this dimension's main actionable groups (7 warning-level).
- Enforce God Classes in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D4 · Code Duplication
58 duplicated block group(s) detected. 23 of the 58 are in trees this repository does not ship — vendored, example/demo, fixture and benchmark code — and are ranked below the shipped groups rather than excluded from them: the duplication there is real and is still counted in this dimension's score. The dimensions that publish a production-file census leave those trees out of theirs, so this count is deliberately drawn over the wider population.
What to do
- Resolve the 8 Duplicated block (7 lines × 2) finding(s) in Code Duplication — start with CustomScaleTypes.java (2), HashCodeUtil.kt, AshmemMemoryChunk.kt. — One of this dimension's main actionable groups (8 warning-level).
- Resolve the 5 Duplicated block (5 lines × 2) finding(s) in Code Duplication — start with ImmutableMap.java, VolleyNetworkFetcher.java, ScalingUtils.java. — One of this dimension's main actionable groups (5 warning-level).
- Resolve the 3 Duplicated block (15 lines × 2) finding(s) in Code Duplication — start with BufferedDiskCache.kt, BitmapProbeProducer.java, DefaultCloseableImage.java. — One of this dimension's main actionable groups (3 warning-level).
- Enforce Code Duplication in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D5 · Coupling
53 production modules (Gradle+Maven), 0 dependency cycle(s), 5 unstable depended-on module(s). Read from the build's own module declarations; edges a convention plugin adds from buildSrc or build-logic are not visible there; 9 module(s) off the main sequence, with abstractness counted on 50 of the 53 (the rest declare no modelled class or interface, export only macros, declare types in source no model reads, or have no source directory of their own).
What to do
- Resolve the 8 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (8 warning-level).
- Resolve the 5 Unstable project finding(s) in Coupling. — One of this dimension's main actionable groups (5 warning-level).
- Enforce Coupling in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D6 · Cohesion (LCOM4)
4 of 149 classes have LCOM4 above 3.
What to do
- Resolve the 4 Low cohesion finding(s) in Cohesion (LCOM4) — start with PoolConfig.kt, FrescoDrawable2.kt, HierarcherImpl.kt. — One of this dimension's main actionable groups (4 warning-level).
- Enforce Cohesion (LCOM4) in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D9 · Test Distribution
617 test methods: 617 unit, 0 integration, 0 BDD, 0 e2e.
D12 · Dependency Hygiene
0 outdated direct gem(s), 1 pinning defect(s). 1 declaration(s) graded against rubygems.org, none of them against a committed Gemfile.lock — this repository commits none, which a published gem correctly does not, so currency is read off the declared requirements: a declaration that does not cap below the current release resolves to it on `bundle install`. 1 declaration(s) carry a requirement that EXCLUDES the current release; that is a deliberate constraint (a supported-version ceiling or a held-back CI pin) and is counted, not charged. Whether any of these gems is DEPRECATED or YANKED is not graded — rubygems.org publishes no deprecation marker, and a yank removes a version rather than flagging it. Whether any is UNMAINTAINED is not graded either: no registry publishes a maintenance status, and release age does not stand in for one. Whether any is UNUSED is a source question, not a registry one. Known CVEs in this dependency graph are D30's question, read from the manifest there.
What to do
- Resolve the 1 No Gemfile.lock committed by an application finding(s) in Dependency Hygiene. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Dependency Hygiene in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D13 · REDACTED Scanning
REDACTED scan ran and found no leaked secrets.
D14 · License Compliance
0 of 1 shipped gem(s) use a banned license. Licences were resolved from rubygems.org over the 1 runtime gem(s) this repository declares. It commits no Gemfile.lock to close that set over, so the verdict covers the declarations rather than the whole resolved graph. Development-group and `add_development_dependency` gems are excluded: they are not distributed with this repository. ★ COVERAGE OF THIS VERDICT: it grades this repository's gem dependencies and nothing else. The repository also declares a Gradle build (build.gradle/build.gradle.kts), and the licences of those dependencies were NOT read by this pass — a gap in this engine's coverage, not a statement about them. So this result says the graded closure carries no banned licence; it does NOT say this repository's licensing is clear.
D15 · Churn × Complexity Hotspots
Top hotspots: vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt (10×27=270); imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt (8×19=152); vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt (5×26=130)
What to do
- Resolve the 4 Hotspot finding(s) in Churn × Complexity Hotspots — start with KFrescoController.kt, DecodeProducer.kt, FrescoController2Impl.kt. — One of this dimension's main actionable groups (4 warning-level).
D16 · Bus Factor
24 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is fbcore/src/main/java/com/facebook/common/logging/FLog.kt. Counted over 321 of the 860 production source files in this repository: 530 are under the ~2,400-byte size floor this dimension measures over, and the remaining 9 have no attributable history left to measure.
D17 · Explicit Debt
30 deducted task-comment markers across 97605 LoC (0.0/KLoC) → score 9.9. Task comments only: this repository's language is read without a compiler, so D17's suppression, dead-code and commented-out-code arms did not run and this score counts fewer marker kinds than a .NET repository's would.
What to do
- Resolve the 27 TodoComment finding(s) in Explicit Debt — start with BufferedDiskCache.kt (8), KFrescoController.kt (3), ImageLayerDataModel.kt (3). — One of this dimension's main actionable groups (27 warning-level).
- Resolve the 3 FixmeComment finding(s) in Explicit Debt — start with VitoImagePipelineImpl.kt (2), ExtrasUtils.kt. — One of this dimension's main actionable groups (3 warning-level).
- Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D19 · Documentation Quality
This repository's documentation is comprehensive and well-structured: the READMEs for each Fresco module (from concepts to gotchas) cover what a given class does with code examples, plus architecture/Docs markdown files that are extremely detailed. The documents are all present and complete within their outlines; there is no missing section in any of them. This repository's documentation is strong for its subject matter: a focused listening-to-events guide that explains the two instrumentation interfaces (RequestListener and BaseControllerListener) with code examples and adds an onFinalImageSet usage note. The accompanying architecture/Docs directory is huge (892 markdown files), so much of the project's broader design, build, and contribution guidance resides there rather than the READMEs. (14 of 25 sampled documents could not be assessed: 1 of 3 evaluation groups failed.)
D21 · Naming Consistency
0 naming inconsistencies across 0 sampled symbols.
D22 · Internal API Consistency
5 API inconsistencies across a 400-member sample of 1034 exposed types.
What to do
- Resolve the 1 Redundant overloads for Uri vs ImageSource finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Dual entry points for image loading finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Implementation class exposes same dual entry point inconsistency finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
D26 · Project Cohesion
3 of 50 build units (Bundler, Gradle, Maven) flagged as possibly oversized/incoherent.
What to do
- Resolve the 1 Projects may be oversized for their cohesion finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).
D28 · Secrets (history)
23 finding(s): 0 critical, 23 high, 0 medium, 0 low. Remediation for historically-committed secrets is credential rotation — they remain in history regardless of later deletion.
What to do
- Resolve the 22 High secret finding(s) in Secrets (history) — start with REDACTED (22). — One of this dimension's main actionable groups (22 issue-level).
- Resolve the 1 REDACTED finding(s) in Secrets (history) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 1 Rotate the exposed credentials finding(s) in Secrets (history). — One of this dimension's main actionable groups (1 recommendation-level).
D29 · Static Analysis (SAST)
14 finding(s): 0 critical, 11 high, 3 medium, 0 low. 9 unpinned-GitHub-Actions row(s) are reported here but scored by D36 (supply-chain provenance), which measures that posture as `pinned_actions` — one pinning decision is charged once, not once per lens. semgrep hit a parse error in 29 file(s) — `docs/_includes/blog_pagination.html` (line 2, line 28), `docs/_includes/powered_by.html` (line 1, line 22), `docs/javadoc/reference/classes.html` (line 1260, line 3345, lines 4419–4420), `docs/javadoc/reference/com/facebook/common/internal/Objects.ToStringHelper.html` (line 497), `docs/javadoc/reference/com/facebook/common/internal/Objects.html` (line 547), … (+24 more) — so no absence of findings in the named regions is evidence of anything; rows reported elsewhere in those files are real. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them. Separately, one or more rules could not re-parse an embedded snippet in 1 file(s) (e.g. a workflow `run:` block read as shell). Those files WERE scanned and their other rows are unaffected; only those rules' view of those snippets is missing.
What to do
- Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (2). — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (2). — One of this dimension's main actionable groups (2 warning-level).
- No action in Static Analysis (SAST) — all 9 REDACTED finding(s) are reported here at file:line but scored by D36 (supply-chain provenance), so none is charged to this dimension. — One of this dimension's main actionable groups (9 issue-level, 0 of them charged here).
D34 · Knowledge Freshness
124 of 330 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchy.java. Counted over 330 of the 860 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
What to do
- Resolve the 122 Orphaned file finding(s) in Knowledge Freshness — start with PartialDiskCacheProducer.java, AnimatedDrawableBackendImpl.java, FLog.kt. — One of this dimension's main actionable groups (122 recommendation-level).
- Resolve the 2 Orphaned knowledge finding(s) in Knowledge Freshness — start with GenericDraweeHierarchy.java, GenericDraweeHierarchyBuilder.java. — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 1 Further orphaned files (smaller) finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).
D35 · Change Coupling
Strongest change-coupling: DebugDataProvider.kt↔DebugOverlayHandler.kt 80%; NopUriModifier.kt↔VitoImagePipelineImpl.kt 77%; ResizeAndRotateProducer.java↔NativeJpegTranscoder.java 69%
What to do
- Resolve the 4 Boundary-crossing change coupling finding(s) in Change Coupling — start with NopUriModifier.kt (2), ResizeAndRotateProducer.java, AnimationLoaderFactory.kt. — One of this dimension's main actionable groups (4 issue-level).
- Resolve the 2 Change coupling finding(s) in Change Coupling — start with DebugDataProvider.kt, CombinedImageListenerImpl.kt. — One of this dimension's main actionable groups (2 warning-level).
D36 · Supply-chain Provenance & Signing
1/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).
What to do
- Resolve the 3 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED, REDACTED, REDACTED. — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
D44 · Platform End-of-Life
0 end-of-life runtime(s) and 0 end-of-life framework(s), read from 57 platform declaration(s) and 6 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
Frontend & cross-cutting dimensions
AX10 · Code composition
What to do
- The domain core is a small share of production code, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
AX3 · Project dependency cycles
AX4 · Dependency direction
AX6 · Interface segregation
- `LoggingDelegate` declares 16 abstract methods under just 10 distinct name(s): `d`, `d`, `e`, `e`, `getMinimumLoggingLevel`, `i`, `i`, `isLoggable`, `log`, `setMinimumLoggingLevel`, `v`, `v`, `w`, `w`, `wtf`, `wtf`. Counted over its ABSTRACT methods, once per signature; `default`, `static` and `private` methods and constants are not counted, because no implementer is forced to write them. That is an OVERLOAD SET, not 16 separate responsibilities: a caller binds to 10 operation(s) and uses the overload it selected, so the Interface-Segregation harm does NOT apply on the caller's side and splitting this into role-interfaces would scatter one operation without relieving anything. The burden that does remain is the IMPLEMENTER's — all 16 signatures must be written and kept in step. Reduce it by collapsing overloads (optional or default parameters, or an options object) rather than by segregating the interface. — fbcore/src/main/java/com/facebook/common/logging/LoggingDelegate.java:14
- `ZoomableController` declares 16 abstract methods: `computeHorizontalScrollExtent`, `computeHorizontalScrollOffset`, `computeHorizontalScrollRange`, `computeVerticalScrollExtent`, `computeVerticalScrollOffset`, `computeVerticalScrollRange`, `getScaleFactor`, `getTransform`, `isEnabled`, `isIdentity`, `onTouchEvent`, `setEnabled`, `setImageBounds`, `setListener`, `setViewBounds`, `wasTransformCorrected`. Counted over its ABSTRACT methods, once per signature; `default`, `static` and `private` methods and constants are not counted, because no implementer is forced to write them. A wide interface forces every implementer and caller to depend on methods they don't use (the Interface-Segregation 'I' in SOLID). Split it into focused role-interfaces. — samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableController.java:18
- `AnimatedDrawableBackend` declares 20 abstract methods: `dropCaches`, `forNewBounds`, `getAnimatedImageResult`, `getDurationMs`, `getDurationMsForFrame`, `getFrameCount`, `getFrameForPreview`, `getFrameForTimestampMs`, `getFrameInfo`, `getHeight`, `getLoopCount`, `getMemoryUsage`, `getPreDecodedFrame`, `getRenderedHeight`, `getRenderedWidth`, `getTimestampMsForFrame`, `getWidth`, `hasPreDecodedFrame`, `renderDeltas`, `renderFrame`. Counted over its ABSTRACT methods, once per signature; `default`, `static` and `private` methods and constants are not counted, because no implementer is forced to write them. A wide interface forces every implementer and caller to depend on methods they don't use (the Interface-Segregation 'I' in SOLID). Split it into focused role-interfaces. — animated-base/src/main/java/com/facebook/imagepipeline/animated/base/AnimatedDrawableBackend.java:22
What to do
- Split fat interfaces into focused role-interfaces so clients depend only on what they use.
- Where the width is an overload set rather than separate responsibilities, collapse the overloads instead — segregating those relieves no caller.
M1 · Documentation (README)
What to do
- Add a build/run (quick start) section to the root README — the first thing a newcomer needs.
- Explain in the README how to run the tests. Add a section called Testing to the README in the repository's top folder, saying how to run the test suite.
- Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
- Add a README to the 58 of 60 project(s) that lack one — worth up to 1.9 pts.
M2 · Architecture documentation
- No Architecture Decision Records found — no conventional ADR directory, no numbered `NNNN-title` documents in any markup this check reads, and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.
- No C4/Structurizr/PlantUML/Mermaid/Graphviz/D2 diagram, no drawn diagram named for the architecture, no file named `architecture` or `design` in any markup this check reads, and nothing in the README, docs or contributor guides that announces the shape — no `## Architecture` heading, no "architecture overview"/"high-level design" phrasing, no "the architecture is …" introduction, no guided code tour. A shape laid out in prose that never names itself as the architecture is not visible to this check, and neither is one kept outside the repository, so this row reports the absence of a re-findable shape document — not evidence that nobody wrote the shape down.
What to do
- Record your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them.
- Add a C4 context/container diagram (Structurizr, PlantUML or Mermaid) or an architecture.md overview.
M3 · Folder & project structure
M4 · Documentation accuracy
- docs/_docs/animations.md links to `index.html`, but `docs/_docs/index.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/animations.md:12
- docs/_docs/animations.md links to `image-requests.html`, but `docs/_docs/image-requests.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/animations.md:16
- docs/_docs/building-from-source.md links to `index.html#_`, but `docs/_docs/index.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/building-from-source.md:8
- docs/_docs/caching.md links to `modifying-image.html`, but `docs/_docs/modifying-image.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/caching.md:12
- docs/_docs/caching.md links to `customizing-image-formats.html`, but `docs/_docs/customizing-image-formats.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/caching.md:20
- docs/_docs/caching.md links to `configure-image-pipeline.html#configuring-the-disk-cache`, but `docs/_docs/configure-image-pipeline.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/caching.md:36
- docs/_docs/caching.md links to `image-requests.html`, but `docs/_docs/image-requests.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/caching.md:102
- docs/_docs/closeable-references.md links to `using-simpledraweeview.html`, but `docs/_docs/using-simpledraweeview.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/closeable-references.md:10
- docs/_docs/concepts.md links to `index.html`, but `docs/_docs/index.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/concepts.md:16
- docs/_docs/concepts.md links to `using-simpledraweeview.html`, but `docs/_docs/using-simpledraweeview.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/concepts.md:18
- docs/_docs/concepts.md links to `using-controllerbuilder.html`, but `docs/_docs/using-controllerbuilder.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/concepts.md:34
- docs/_docs/concepts.md links to `listening-to-events.html`, but `docs/_docs/listening-to-events.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/concepts.md:38
- docs/_docs/configure-image-pipeline.md links to `using-other-network-layers.html`, but `docs/_docs/using-other-network-layers.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/configure-image-pipeline.md:65
- docs/_docs/datasources-datasubscribers.md links to `closeable-references.html`, but `docs/_docs/closeable-references.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/datasources-datasubscribers.md:95
- docs/_docs/datasources-datasubscribers.md links to `../javadoc/reference/com/facebook/imagepipeline/datasource/BaseBitmapDataSubscriber`, but `docs/javadoc/reference/com/facebook/imagepipeline/datasource/BaseBitmapDataSubscriber` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/datasources-datasubscribers.md:149
- docs/_docs/drawee-branches.md links to `scaletypes.html`, but `docs/_docs/scaletypes.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/drawee-branches.md:20
- docs/_docs/drawee-branches.md links to `using-controllerbuilder.html`, but `docs/_docs/using-controllerbuilder.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/drawee-branches.md:28
- docs/_docs/drawee-branches.md links to `progress-bars.html`, but `docs/_docs/progress-bars.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/drawee-branches.md:81
- docs/_docs/faq.md links to `using-image-pipeline.html`, but `docs/_docs/using-image-pipeline.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/faq.md:52
- docs/_docs/faq.md links to `datasources-datasubscribers.html`, but `docs/_docs/datasources-datasubscribers.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/faq.md:52
- docs/_docs/faq.md links to `post-processor.html`, but `docs/_docs/post-processor.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/faq.md:56
- docs/_docs/faq.md links to `proguard.html`, but `docs/_docs/proguard.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/faq.md:60
- docs/_docs/gotchas.md links to `writing-custom-views.html`, but `docs/_docs/writing-custom-views.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/gotchas.md:22
- docs/_docs/image-requests.md links to `requesting-multiple-images.html`, but `docs/_docs/requesting-multiple-images.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/image-requests.md:8
- docs/_docs/image-requests.md links to `supported-uris.html`, but `docs/_docs/supported-uris.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/image-requests.md:32
- docs/_docs/image-requests.md links to `rotation.html`, but `docs/_docs/rotation.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/image-requests.md:33
- docs/_docs/image-requests.md links to `progressive-jpegs.html`, but `docs/_docs/progressive-jpegs.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/image-requests.md:34
- docs/_docs/image-requests.md links to `modifying-image.html`, but `docs/_docs/modifying-image.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/image-requests.md:35
- docs/_docs/image-requests.md links to `resizing.html`, but `docs/_docs/resizing.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/image-requests.md:36
- docs/_docs/image-requests.md links to `intro-image-pipeline.html`, but `docs/_docs/intro-image-pipeline.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/image-requests.md:40
- docs/_docs/intro-image-pipeline.md links to `caching.html`, but `docs/_docs/caching.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/intro-image-pipeline.md:22
- docs/_docs/intro-image-pipeline.md links to `supported-uris.html`, but `docs/_docs/supported-uris.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/intro-image-pipeline.md:25
- docs/_docs/placeholder-failure-retry.md links to `progress-bars.html`, but `docs/_docs/progress-bars.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/placeholder-failure-retry.md:8
- docs/_docs/placeholder-failure-retry.md links to `scaletypes.html`, but `docs/_docs/scaletypes.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/placeholder-failure-retry.md:8
- docs/_docs/post-processor.md links to `/static/images/docs/02-post-processor-blur.png`, but `static/images/docs/02-post-processor-blur.png` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/post-processor.md:114
- docs/_docs/post-processor.md links to `/static/images/docs/02-post-processor-scaling-blur.png`, but `static/images/docs/02-post-processor-scaling-blur.png` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/post-processor.md:158
- docs/_docs/requesting-multiple-images.md links to `using-controllerbuilder.html`, but `docs/_docs/using-controllerbuilder.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/requesting-multiple-images.md:8
- docs/_docs/resizing.md links to `scaletypes.html`, but `docs/_docs/scaletypes.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/resizing.md:12
- docs/_docs/resizing.md links to `configure-image-pipeline.html`, but `docs/_docs/configure-image-pipeline.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/resizing.md:41
- docs/_docs/sample-apps.md links to `building-from-source.html`, but `docs/_docs/building-from-source.html` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/_docs/sample-apps.md:12
What to do
- Reconcile the README with reality: docs/_docs/animations.md links to `index.html`, but `docs/_docs/index.html` does not exist; docs/_docs/animations.md links to `image-requests.html`, but `docs/_docs/image-requests.html` does not exist; docs/_docs/building-from-source.md links to `index.html#_`, but `docs/_docs/index.html` does not exist; docs/_docs/caching.md links to `modifying-image.html`, but `docs/_docs/modifying-image.html` does not exist; docs/_docs/caching.md links to `customizing-image-formats.html`, but `docs/_docs/customizing-image-formats.html` does not exist.
P1 · CI/CD gates
P10 · Library API & versioning
- 1127/1275 types (88%) declared in the published library are public. For a library, every public type is a stability contract — keep implementation types off the surface and expose only the intended API.
What to do
- Keep implementation types off the public surface (Java: package-private (no modifier), or leave its package out of `module-info` exports; Kotlin: `internal`) so internals can change without breaking consumers.
P2 · Observability
- Only 1/2 runnable modules use logging (modules with no entry point or server are excluded — they are libraries a runnable module hosts). Silent: `.`.
What to do
- Extend structured logging to the remaining runnable modules so everything you run is diagnosable in production.
P3 · Security & performance tooling
- No static application security testing detected. For this repository's stack, add spotbugs with find-sec-bugs (or `semgrep --config=auto`, which runs on any language) as a CI step. What was searched, so you can tell an absence from a miss: the 2907 CI workflow file(s) in this repository, and the scanner and linter configuration checked in beside them. A scan that runs outside CI, one configured in your forge's web UI rather than in a committed file, or a tool whose name is none of those this check carries, is not seen — if that is your case the row is wrong, and saying so is more useful than adding a second scanner.
What to do
- Add a SAST step to CI running what this repository's stack ships: spotbugs with find-sec-bugs — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing.
- Enable Dependabot/Renovate or a dependency-review gate.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
P4 · Deployment & Rollback
- The release is automated and no gate that pauses it for a human is DECLARED IN THIS REPOSITORY'S PIPELINE FILES. What was read: every file under `.github/workflows/`, `.forgejo/workflows/`, `.gitea/workflows/`, `.azuredevops/` and `.azure-pipelines/`, plus `.gitlab-ci*` and `azure-pipelines*` — with comment text stripped, so documenting a gate is not declaring one. What would have counted: GitLab's `when: manual`, CircleCI's `type: approval`, an Azure `ManualValidation@` task or an `approvals:` block, a Jenkins `input` step, a `uses:` step naming an approval action, an `environment:` paired with `reviewers` / `required_reviewers` / `protection` / `wait-timer` / `deployment_branch_policy`, a draft-release step, a `workflow_dispatch` promotion, or a release-event gate. ★ What this cannot see, because none of it is a file: a GitHub environment whose required reviewers are configured in repo SETTINGS, a branch protection rule, or an organisation deployment policy — all of them real, enforced gates that live outside the repository. If yours is one of those, this row is wrong and nothing in the tree could have told us. Otherwise: whatever the release trigger points at is published to users unreviewed, so a mistagged or unverified commit ships and the only remedy is a follow-up release.
What to do
- Nothing pauses a release for a human: publish as a draft release (or gate the release job on a protected tag/manual dispatch) so a bad build can be stopped before users can download it.
P6 · Release Hygiene
- No CHANGELOG/HISTORY/RELEASES file — what shipped when isn't easy to reconstruct for support or audit. (Versioning/tagging makes releases traceable, but a changelog records the what.)
What to do
- Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release.
PF2 · Allocation hygiene
What to do
- Raise allocation-aware density on the hot paths — currently 158 use(s) across 91,143 production line(s) (~1.7/1k). More of the idioms below on the allocation-heavy paths climbs this toward 10.
- Java: on hot paths, work through buffer views (ByteBuffer/LongBuffer slices, MemorySegment) instead of copies, avoid boxing with primitive collections (fastutil, Eclipse Collections, HPPC, Trove), presize collections and StringBuilders, and pool expensive buffers (Netty's pooled allocator, commons-pool).
- Kotlin: on hot paths, use primitive arrays (IntArray, LongArray …) and @JvmInline value classes instead of boxed values, primitive collections (androidx.collection, fastutil) instead of boxed ones, and presize collections and StringBuilders.
X1 · Async correctness
X12 · Unreachable branch
X13 · Undrained process stream
X14 · Bypassable address classification
X15 · Unvalidated length from an untrusted reader
X16 · Unfloored truncation loop
X17 · Uncapped recursion over a caller-supplied document
X18 · Disposal-pattern correctness
X19 · Unrestored process-global state
X20 · Mistyped argument guard
X21 · Side-effecting pattern guard
X22 · Contradicted release guard
X23 · Unguarded diagnostic materialisation
X24 · Document value interpolated into markup unescaped
X25 · Inert configuration knob
X26 · Unsynchronised callback handoff
X27 · Collection changed while being enumerated
X28 · Index access outside its own emptiness guard
X29 · Per-element action decided by a fixed element
X3 · Exception handling
- `catch (exception: Exception)` takes every exception and records none of it — the body neither logs it, rethrows it, nor even names it, so the failure is discarded as completely as by an empty catch and only the substituted value survives. Log it through whatever this codebase already uses to report problems, narrow the catch to the exception this call can actually raise, or say in a comment on the catch why the failure genuinely cannot matter. (×2) — imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:176, imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:216
- An empty catch block silently discards the error — failures vanish with no log and no rethrow. Log it, handle it, or don't catch it. — static-webp/src/main/java/com/facebook/webpsupport/WebpBitmapFactoryImpl.kt:368
- `catch (t: Throwable)` takes every exception and records none of it — the body neither logs it, rethrows it, nor even names it, so the failure is discarded as completely as by an empty catch and only the substituted value survives. Log it through whatever this codebase already uses to report problems, narrow the catch to the exception this call can actually raise, or say in a comment on the catch why the failure genuinely cannot matter. — vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt:197
- `catch (_: Exception)` takes every exception and records none of it — the body neither logs it, rethrows it, nor even names it, so the failure is discarded as completely as by an empty catch and only the substituted value survives. Log it through whatever this codebase already uses to report problems, narrow the catch to the exception this call can actually raise, or say in a comment on the catch why the failure genuinely cannot matter. — vito/tools/liveeditor/src/main/java/com/facebook/fresco/vito/tools/liveeditor/LiveEditorOnScreenButtonController.kt:265
What to do
- Swallowed exception (caught, then discarded)
X30 · Support guard that admits what it rejects
X5 · Nullable reference types
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 85% | Strong | Solid. |
| Architecture | 96% | Exemplary | Strongest area. |
| Maturity | 45% | Weak — gated by M2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Readiness | 47% | Weak — gated by P3 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 46% | Weak — gated by D28, D36 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Performance | 69% | Adequate | Acceptable, with room to improve. |
Unscored — 1 check(s) recorded observations but carry no score
- X10 Duplicated predicate — 14 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 1 control(s) we could not find positive evidence for
- P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
Not included — 57 check(s) not relevant to this codebase
- AC1 Text alternatives — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
- AC2 Forms & labels — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
- AC3 Page structure — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
- AC4 Keyboard semantics — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
- AC5 ARIA correctness — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
- AC6 Visual & motion safety — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
- AC7 A11y enforcement — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
- AX1 Captive dependencies — Not applicable: this repository's Java imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's; this repository's Kotlin imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's; this repository's Python imports no dependency-injection container and defines no container of its own — nothing that both registers and resolves bindings, and nothing that names two lifetimes — so nothing holds one lifetime's instance while handing out another's.
- AX2 Stateful singletons — No container singleton was found, so there is no shared instance for concurrent requests to race on. No class in this Java code is a Spring, JSR-330 or CDI singleton bean. No class in this Kotlin code is a Spring, JSR-330 or CDI singleton bean. No function in this Python code is served by a threaded web framework (a Flask, Bottle or FastAPI route, a Django or Pyramid view), so no module is shared between request threads. TypeScript/JavaScript runs each process's requests on one event loop, so no two requests write a shared object at the same instant (interleaving across an await is a different defect).
- AX5 Architecture & structure — not assessed — architecture style/structure is computed from a project graph (projects, types, module namespaces) that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AX8 Test isolation — no test/production split to check
- AX9 CQS / query purity — no CQRS query handlers detected — query purity is not applicable to this codebase
- AXB1 Runtime evidence locked — no reproducible boot — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- C1 Data Protection — No personal data detected in a persisted data model — no PII-named field (email, firstName, dateOfBirth, phoneNumber, …) or stored credential on a Room, JPA or MongoDB entity, an Exposed or Ktorm table, or in a SQL CREATE TABLE or ALTER TABLE — and no database or data-store client (Room, Exposed, SQLDelight, Realm, JPA, JDBC, MongoDB, Firebase, …) imported either, so this repository keeps no data at rest for these controls to protect.
- C2 Access Controls — Not assessed: these authorization controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks authorization controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C3 Audit Trail — No personal data detected in a persisted data model — no PII-named column (email, first_name, date_of_birth, phone_number, …) or stored credential on a Room, JPA or MongoDB entity, an Exposed or Ktorm table, or a SQL CREATE TABLE or ALTER TABLE — and no database or data-store client (Room, Exposed, SQLDelight, Realm, JPA, JDBC, MongoDB, Firebase, …) imported either, so this repository keeps no sensitive data whose changes an audit trail would record. If it does (through a store configured outside this repository, for instance), the trail belongs to wherever that data is stored.
- C4 Data Retention — No personal data detected in a persisted data model — no PII-named field (email, firstName, dateOfBirth, phoneNumber, …) or stored credential on a Room, JPA or MongoDB entity, an Exposed or Ktorm table, or in a SQL CREATE TABLE or ALTER TABLE — and no database or data-store client (Room, Exposed, SQLDelight, Realm, JPA, JDBC, MongoDB, Firebase, …) imported either, so this repository keeps no personal data whose lifetime a retention limit would bound.
- C5 Data-Subject Rights — No personal data detected in a persisted data model — no PII-named field (email, firstName, dateOfBirth, phoneNumber, …) or stored credential on a Room, JPA or MongoDB entity, an Exposed or Ktorm table, or in a SQL CREATE TABLE or ALTER TABLE — and no database or data-store client (Room, Exposed, SQLDelight, Realm, JPA, JDBC, MongoDB, Firebase, …) imported either, so this repository keeps no personal data for a data subject to erase, export or consent over.
- D10 Test Quality — ~43341 lines of test source are present (.java, .kt) but no test cases reached the test census for this repository — no test root we could resolve declared them, or the files we read declare no cases in a test framework we recognise — so skipped/assertion-free tests couldn't be counted. Not scored — this is a gap in the analyzer, not a finding about this repository.
- D11 Test Reliability — Test reliability not included — the .kt suite was found but not re-run
- D18 Solution Shape — D18 scores the shape of a .NET solution; this repository has no .NET solution or project files, so the dimension does not apply.
- D20 ADR Quality — N/A — ADRs are expected on deployable products with a user-facing host, not consumed libraries; no ADR log is required here.
- D23 Boundary Type-Coupling — No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D24 Comment Value — No inline comments to assess — comment value is not applicable here.
- D25 ADR Conformance — no ADRs to check
- D27 Navigability — D27 reads resolved call sites in the languages it reads only — this repository's production source is .c, .cpp, .java, .py, which was left unread. Not scored: this is a gap in the analyzer, not a verdict about this repository.
- D30 Dependency Vulnerabilities — osv: the scanner produced no output at all, so no dependency was actually scanned
- D31 IaC & Container Security — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan.
- D32 Data Compliance (PII/GDPR) — 34 file(s) were not parsed by semgrep — the PII/GDPR ruleset never ran over them
- D37 Vulnerability-disclosure Policy — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed.
- D39 IL Efficiency — D39 measures the IL emitted by a .NET build; this repository has no .NET solution or project files, so the dimension does not apply.
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D43 Malicious Dependencies — osv: the scanner produced no output at all, so no dependency was actually scanned
- D7 Architectural Integrity — no checkable ADRs, and no project-reference graph for the cycle pass to read — so this dimension makes no claim about dependency cycles in either direction (where this repository's language has an import-cycle lens, cycles are reported there). Architectural integrity not assessed
- D8 Code Coverage — Coverage not included — suite not readable by the collector
- DM1 Domain Modelling — applicable but not scored (2 of 3 signals for this style — below the bar we score at): 93 value object(s); 1 domain event(s); its domain events are published by services or handlers — no domain entity raises one
- ED1 Event-Driven — not scored — this repository shows none of the 3 signals this lens looks for
- ED5 Idempotency — no mutating command handlers or message consumers detected — idempotency check not applicable
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this lens looks for
- GD1 Unfinished & placeholder code — no source files were read — this check reads C#, F#, JavaScript/TypeScript, Dart, Ruby and Scala, and none was read for this repository's product. That is a limit of the analyzer, not a finding about your code.
- IC1 Incompleteness & stubs — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- P12 CI test-gate honesty — Reported, not scored — and nothing was matched here. The coverage check applies to any stack, and the automatic-re-run check to any GitHub-Actions workflow, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
- P7 Outbound HTTP resilience — not applicable — no HTTP server, API framework or worker entry point was found in the JVM, JavaScript/TypeScript, Python source, so there is no service whose uptime a failing dependency could take down
- P8 Schema migrations — no ORM, schema-migration tool or schema auto-create was found in this repository's dependency manifests or source, so there is no database schema for this check to judge
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (JaCoCo XML — the Gradle `jacocoTestReport` task) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — Not applicable: no benchmark suite was found. This check searched for `@Benchmark` in a Java, Kotlin or Scala file importing JMH or kotlinx-benchmark, Jetpack Benchmark's `measureRepeated` in a file importing androidx.benchmark, or JMH/kotlinx-benchmark/androidx.benchmark in a pom.xml, Gradle or sbt build, and for a `*benchmark*` script that this repository's CI runs. Benchmarks are credited as a bonus, so their absence is neither scored nor deducted.
- PF3 Async & latency hygiene — Not applicable: this repository declares no async functions, so there is no asynchronous code for a blocking call to stall.
- S1 Web-Security Posture — Not assessed: these web-security controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks web-security controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- X2 Cancellation propagation — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X32 Type resolved by simple name across every loaded assembly — This check is about how a .NET program searches the assemblies loaded into its process for a type, and this repository contains no .NET source, so there is nothing here for it to assess. Not a gap in the analyzer and not a finding about your code.
- X4 Structured logging — This check asks whether log calls keep a message's values apart from its text, which needs a logger that can carry them as fields. This repository's Kotlin was read, and it logs through none that an assembled message defeats: Android's `Log` and Timber, java.util.logging and log4j-api-kotlin take one finished message (as log4net does in C#), or it makes no call through a named logger at all. Calls made through SLF4J, log4j 2 or kotlin-logging (`LoggerFactory.getLogger`, `KotlinLogging.logger {}`) would be judged.
- X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X7 Silent fallback defaults — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 40 finding(s)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Boundary-crossing change coupling: NopUriModifier.kt ↔ VitoImagePipelineImpl.kt urimod/src/main/java/com/facebook/fresco/urimod/NopUriModifier.kt:1
- Boundary-crossing change coupling: ResizeAndRotateProducer.java ↔ NativeJpegTranscoder.java imagepipeline/src/main/java/com/facebook/imagepipeline/producers/ResizeAndRotateProducer.java:1
- Boundary-crossing change coupling: NopUriModifier.kt ↔ VitoImagePipeline.kt urimod/src/main/java/com/facebook/fresco/urimod/NopUriModifier.kt:1
- Boundary-crossing change coupling: AnimationLoaderFactory.kt ↔ AnimatedFactoryProvider.kt animated-drawable/src/main/java/com/facebook/fresco/animation/bitmap/preparation/ondemandanimation/AnimationLoaderFactory.kt:1
- REDACTED
- REDACTED
- Orphaned knowledge drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchy.java:1
- Orphaned knowledge drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchyBuilder.java:1
- REDACTED
Serious — 221 finding(s)
- TodoComment animated-base/src/main/java/com/facebook/fresco/animation/bitmap/cache/FrescoFrameCache.kt:134
- TodoComment animated-drawable/src/main/java/com/facebook/fresco/animation/drawable/AnimationFrameScheduler.kt:109
- TodoComment drawee/src/test/java/com/facebook/drawee/drawable/ScaleTypeDrawableTest.java:306
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/StagingArea.java:144
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/StagingArea.java:171
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:91
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:238
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:276
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:306
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:335
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:408
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:381
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:382
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/producers/PartialDiskCacheProducer.java:317
- TodoComment imagepipeline/src/main/java/com/facebook/imagepipeline/producers/PartialDiskCacheProducer.java:339
- TodoComment samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/imageformat/pjpeg/ImageFormatProgressiveJpegFragment.java:49
- TodoComment samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/vito/ImageSourceConfigurator.kt:65
- TodoComment tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java:531
- TodoComment tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java:628
- TodoComment vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:87
- TodoComment vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:179
- TodoComment vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:412
- TodoComment vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/ImageLayerDataModel.kt:77
- TodoComment vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/ImageLayerDataModel.kt:144
- TodoComment vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/ImageLayerDataModel.kt:188
- TooManyMethods: FLog fbcore/src/main/java/com/facebook/common/logging/FLog.kt:13
- TooManyMethods: ImagePipeline imagepipeline/src/main/java/com/facebook/imagepipeline/core/ImagePipeline.kt:54
- TooManyMethods: AbstractDraweeController drawee/src/main/java/com/facebook/drawee/controller/AbstractDraweeController.java:58
- TooManyMethods: ImageRequestBuilder imagepipeline/src/main/java/com/facebook/imagepipeline/request/ImageRequestBuilder.java:35
- TooManyMethods: Builder imagepipeline/src/main/java/com/facebook/imagepipeline/core/ImagePipelineExperiments.kt:105
- TooManyMethods: DefaultFrescoVitoConfig vito/core/src/main/java/com/facebook/fresco/vito/core/DefaultFrescoVitoConfig.kt:16
- TooManyMethods: GenericDraweeHierarchy drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchy.java:87
- TooManyMethods: GenericDraweeHierarchyBuilder drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchyBuilder.java:33
- TooManyMethods: EncodedImage imagepipeline-base/src/main/java/com/facebook/imagepipeline/image/EncodedImage.java:55
- TooManyMethods: Builder imagepipeline/src/main/java/com/facebook/imagepipeline/core/ImagePipelineConfig.kt:217
- TooManyMethods: AbstractAdaptiveCountingMemoryCache imagepipeline-base/src/main/java/com/facebook/imagepipeline/cache/AbstractAdaptiveCountingMemoryCache.java:42
- TooManyMethods: ImageRequest imagepipeline/src/main/java/com/facebook/imagepipeline/request/ImageRequest.java:52
- TooManyMethods: AbstractDraweeControllerBuilder drawee/src/main/java/com/facebook/drawee/controller/AbstractDraweeControllerBuilder.java:34
- TooManyMethods: GifImage animated-gif/src/main/java/com/facebook/animated/gif/GifImage.java:31
- TooManyMethods: ImagePipelineFactory imagepipeline/src/main/java/com/facebook/imagepipeline/core/ImagePipelineFactory.java:68
- TooManyMethods: Companion static-webp/src/main/java/com/facebook/webpsupport/WebpBitmapFactoryImpl.kt:61
- TooManyMethods: DraweeView drawee/src/main/java/com/facebook/drawee/view/DraweeView.java:47
- TooManyMethods: Builder vito/options/src/main/java/com/facebook/fresco/vito/options/ImageOptions.kt:274
- TooManyMethods: LruCountingMemoryCache imagepipeline-base/src/main/java/com/facebook/imagepipeline/cache/LruCountingMemoryCache.kt:41
- TooManyMethods: ProducerFactory imagepipeline/src/main/java/com/facebook/imagepipeline/core/ProducerFactory.kt:71
- TooManyMethods: WebPImage animated-webp/src/main/java/com/facebook/animated/webp/WebPImage.java:33
- TooManyMethods: ImageDecodeOptionsBuilder imagepipeline-base/src/main/java/com/facebook/imagepipeline/common/ImageDecodeOptionsBuilder.java:20
- TooManyMethods: BitmapAnimationBackend animated-drawable/src/main/java/com/facebook/fresco/animation/bitmap/BitmapAnimationBackend.kt:51
- TooManyMethods: PipelineDraweeController drawee-backends/drawee-pipeline/src/main/java/com/facebook/drawee/backends/pipeline/PipelineDraweeController.java:65
- TooManyMethods: ForwardingDrawable drawee/src/main/java/com/facebook/drawee/drawable/ForwardingDrawable.java:30
- ClassTooLong: ImagePipeline imagepipeline/src/main/java/com/facebook/imagepipeline/core/ImagePipeline.kt:54
- ClassTooLong: AbstractDraweeController drawee/src/main/java/com/facebook/drawee/controller/AbstractDraweeController.java:58
- ClassTooLong: DiskStorageCache imagepipeline-base/src/main/java/com/facebook/cache/disk/DiskStorageCache.kt:36
- ClassTooLong: AbstractAdaptiveCountingMemoryCache imagepipeline-base/src/main/java/com/facebook/imagepipeline/cache/AbstractAdaptiveCountingMemoryCache.java:42
- ClassTooLong: FrescoFlipperPlugin tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java:69
- ClassTooLong: DecodeProducer imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt:50
- ClassTooLong: FrescoController2Impl vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:56
- ClassTooLong: ScalingUtils ui-core/src/main/java/com/facebook/drawee/drawable/ScalingUtils.java:19
- ClassTooLong: ProducerSequenceFactory imagepipeline/src/main/java/com/facebook/imagepipeline/core/ProducerSequenceFactory.kt:34
- Duplicated block (7 lines × 2) fbcore/src/main/java/com/facebook/common/util/HashCodeUtil.kt:50
- Duplicated block (7 lines × 2) memory-types/ashmem/src/main/java/com/facebook/imagepipeline/memory/AshmemMemoryChunk.kt:104
- Duplicated block (7 lines × 2) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/common/CustomScaleTypes.java:32
- Duplicated block (7 lines × 2) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/common/CustomScaleTypes.java:53
- Duplicated block (7 lines × 2) imagepipeline-base/src/main/java/com/facebook/imagepipeline/image/EncodedImage.java:571
- Duplicated block (7 lines × 2) samples/animation2/src/main/java/com/facebook/samples/animation2/AnimationApplication.java:23
- Duplicated block (7 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/holders/BaseViewHolder.java:52
- Duplicated block (7 lines × 2) samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableDraweeView.java:375
- Off the main sequence: :ui-core
- Off the main sequence: :memory-types:ashmem
- Off the main sequence: :vito:renderer
- Off the main sequence: :vito:options
- Off the main sequence: :imagepipeline-native
- Off the main sequence: :memory-types:nativememory
- Off the main sequence: :memory-types:simple
- Off the main sequence: :vito:source
- MethodTooLong: FrescoFlipperPlugin.onConnect tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java:144
- MethodTooLong: FrescoController2Impl.fetch vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:83
- MethodTooLong: KFrescoController.fetch vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:132
- MethodTooLong: DefaultRawBitmapDecoder.decode imagepipeline/src/main/java/com/facebook/imagepipeline/platform/DefaultRawBitmapDecoder.kt:202
- MethodTooLong: LiveEditorOnScreenButtonController.createOnScreenButtons vito/tools/liveeditor/src/main/java/com/facebook/fresco/vito/tools/liveeditor/LiveEditorOnScreenButtonController.kt:660
- MethodTooLong: ProgressiveDecoder.doDecode imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt:190
- MethodTooLong: GenericDraweeHierarchyInflater.updateBuilder drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchyInflater.java:102
- Duplicated block (5 lines × 2) fbcore/src/main/java/com/facebook/common/internal/ImmutableMap.java:63
- Duplicated block (5 lines × 2) imagepipeline-backends/imagepipeline-volley/src/main/java/com/facebook/imagepipeline/backends/volley/VolleyNetworkFetcher.java:127
- Duplicated block (5 lines × 2) ui-core/src/main/java/com/facebook/drawee/drawable/ScalingUtils.java:283
- Duplicated block (5 lines × 2) samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableDraweeView.java:369
- Duplicated block (5 lines × 2) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/vito/VitoRoundedCornersFragment.java:89
- Unstable project :animated-drawable
- Unstable project :tools:flipper
- Unstable project :vito:core-impl
- Unstable project :vito:nativecode
- Unstable project :vito:textspan
- Hotspot: vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:132
- Hotspot: imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt:190
- Hotspot: vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:83
- Hotspot: imagepipeline/src/main/java/com/facebook/imagepipeline/core/ProducerSequenceFactory.kt imagepipeline/src/main/java/com/facebook/imagepipeline/core/ProducerSequenceFactory.kt:235
- FileTooLong: core/ImagePipeline.kt imagepipeline/src/main/java/com/facebook/imagepipeline/core/ImagePipeline.kt
- FileTooLong: liveeditor/LiveEditorOnScreenButtonController.kt vito/tools/liveeditor/src/main/java/com/facebook/fresco/vito/tools/liveeditor/LiveEditorOnScreenButtonController.kt
- FileTooLong: controller/AbstractDraweeController.java drawee/src/main/java/com/facebook/drawee/controller/AbstractDraweeController.java
- FileTooLong: fresco/FrescoFlipperPlugin.java tools/flipper-fresco-plugin/src/main/java/com/facebook/flipper/plugins/fresco/FrescoFlipperPlugin.java
- Low cohesion: Builder (LCOM4 12) imagepipeline/src/main/java/com/facebook/imagepipeline/memory/PoolConfig.kt:61
- Low cohesion: FrescoDrawable2 (LCOM4 7) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoDrawable2.kt:26
- Low cohesion: HierarcherImpl (LCOM4 6) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/HierarcherImpl.kt:24
- Low cohesion: FrescoController2Impl (LCOM4 4) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:56
- Swallowed exception (caught, then discarded) imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:176
- Swallowed exception (caught, then discarded) imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:216
- Swallowed exception (caught, then discarded) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt:197
- Swallowed exception (caught, then discarded) vito/tools/liveeditor/src/main/java/com/facebook/fresco/vito/tools/liveeditor/LiveEditorOnScreenButtonController.kt:265
- FixmeComment vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/ExtrasUtils.kt:31
- FixmeComment vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt:100
- FixmeComment vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt:104
- REDACTED
- REDACTED
- REDACTED
- Duplicated block (15 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/cache/BufferedDiskCache.kt:81
- Duplicated block (15 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/BitmapProbeProducer.java:71
- Duplicated block (15 lines × 2) imagepipeline-base/src/main/java/com/facebook/imagepipeline/image/DefaultCloseableImage.java:20
- Duplicated block (11 lines × 2) vito/options/src/main/java/com/facebook/fresco/vito/options/ImageOptions.kt:126
- Duplicated block (11 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/SettableProducerContext.java:25
- Duplicated block (11 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/Instrumentation.java:58
- Duplicated block (10 lines × 2) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/BitmapPreparingImageFetchSubscriber.kt:275
- Duplicated block (10 lines × 2) fbcore/src/main/java/com/facebook/datasource/FirstAvailableDataSourceSupplier.java:53
- Duplicated block (10 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/Instrumentation.java:88
- Duplicated block (16 lines × 2) fbcore/src/main/java/com/facebook/common/references/DefaultCloseableReference.java:45
- Duplicated block (16 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/decoder/DefaultImageDecoder.java:210
- Duplicated block (16 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalThumbnailBitmapSdk29Producer.java:140
- Duplicated block (13 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DiskCacheReadProducer.java:227
- Duplicated block (13 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/EncodedMemoryCacheProducer.java:205
- Duplicated block (13 lines × 2) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/vito/renderer/RendererColorFilterExampleFragment.kt:32
- Duplicated block (9 lines × 2) drawee/src/main/java/com/facebook/drawee/drawable/RoundedColorDrawable.java:134
- Duplicated block (9 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DiskCacheReadProducer.java:242
- Duplicated block (9 lines × 2) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/imagepipeline/ImagePipelineBitmapFactoryFragment.java:202
- Duplicated block (8 lines × 2) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/imageformat/keyframes/ImageFormatKeyframesFragment.java:48
- Duplicated block (8 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/Instrumentation.java:70
- Duplicated block (8 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/Instrumentation.java:79
- REDACTED
- REDACTED
- Change coupling: DebugDataProvider.kt ↔ DebugOverlayHandler.kt vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/DebugDataProvider.kt:1
- Change coupling: CombinedImageListenerImpl.kt ↔ KFrescoController.kt vito/core-common-impl/src/main/java/com/facebook/fresco/vito/core/impl/CombinedImageListenerImpl.kt:1
- Duplicated block (14 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/listener/RequestLoggingListener.kt:68
- Duplicated block (14 lines × 2) samples/scrollperf/src/main/java/com/facebook/samples/scrollperf/fragments/SettingsFragment.java:429
- Duplicated block (18 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalThumbnailBitmapSdk29Producer.java:70
- Duplicated block (18 lines × 2) samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableDraweeView.java:299
- GenericDraweeHierarchyInflater.updateBuilder (cyclomatic 48) drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchyInflater.java:102
- VitoViewInflater.inflateImageOptionsBuilder (cyclomatic 37) vito/drawee-support/src/main/java/com/facebook/fresco/vito/draweesupport/VitoViewInflater.kt:26
- DefaultRawBitmapDecoder.decode (cyclomatic 33) imagepipeline/src/main/java/com/facebook/imagepipeline/platform/DefaultRawBitmapDecoder.kt:202
- KFrescoController.fetch (cyclomatic 27) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:132
- FrescoController2Impl.fetch (cyclomatic 26) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:83
- BitmapPreparingImageFetchSubscriber.onNewResult (cyclomatic 26) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/BitmapPreparingImageFetchSubscriber.kt:40
- VitoImagePipelineImpl.determineFetchStrategy (cyclomatic 23) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt:226
- ProgressiveJpegParser.doParseMoreData (cyclomatic 21) imagepipeline/src/main/java/com/facebook/imagepipeline/decoder/ProgressiveJpegParser.java:140
- LiveEditorOnScreenButtonController.createOnScreenButtons (cyclomatic 20) vito/tools/liveeditor/src/main/java/com/facebook/fresco/vito/tools/liveeditor/LiveEditorOnScreenButtonController.kt:660
- ProgressiveDecoder.doDecode (cyclomatic 19) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt:190
- ImageDecodeOptions.equals (cyclomatic 19) imagepipeline-base/src/main/java/com/facebook/imagepipeline/common/ImageDecodeOptions.java:122
- FrescoController2Impl.setActualImage (cyclomatic 16) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:359
- ProducerSequenceFactory.getDefaultBasicDecodedImageSequence (cyclomatic 16) imagepipeline/src/main/java/com/facebook/imagepipeline/core/ProducerSequenceFactory.kt:235
- No Gemfile.lock committed by an application
- GenericDraweeHierarchyInflater.updateBuilder (cognitive 56) drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchyInflater.java:102
- VitoViewInflater.inflateImageOptionsBuilder (cognitive 51) vito/drawee-support/src/main/java/com/facebook/fresco/vito/draweesupport/VitoViewInflater.kt:26
- DefaultRawBitmapDecoder.decode (cognitive 45) imagepipeline/src/main/java/com/facebook/imagepipeline/platform/DefaultRawBitmapDecoder.kt:202
- BitmapPreparingImageFetchSubscriber.onNewResult (cognitive 39) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/BitmapPreparingImageFetchSubscriber.kt:40
- FrescoController2Impl.fetch (cognitive 35) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:83
- ProgressiveJpegParser.doParseMoreData (cognitive 34) imagepipeline/src/main/java/com/facebook/imagepipeline/decoder/ProgressiveJpegParser.java:140
- VitoImagePipelineImpl.determineFetchStrategy (cognitive 33) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt:226
- KFrescoController.fetch (cognitive 30) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:132
- 1.getResult (cognitive 27) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalThumbnailBitmapSdk29Producer.java:88
- ProgressiveDecoder.doDecode (cognitive 23) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DecodeProducer.kt:190
- RoundedDrawable.updateTransform (cognitive 23) drawee/src/main/java/com/facebook/drawee/drawable/RoundedDrawable.kt:208
- FrescoController2Impl.setActualImage (cognitive 22) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/FrescoController2Impl.kt:359
- LightweightDebugOverlayFactory2.buildDebugTextFromConfig (cognitive 22) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/debug/LightweightDebugOverlayFactory2.kt:135
- ProducerSequenceFactory.getDefaultBasicDecodedImageSequence (cognitive 20) imagepipeline/src/main/java/com/facebook/imagepipeline/core/ProducerSequenceFactory.kt:235
- DefaultRawBitmapDecoder.decodeByteArray (cognitive 20) imagepipeline/src/main/java/com/facebook/imagepipeline/platform/DefaultRawBitmapDecoder.kt:63
- RoundedDrawable.updatePath (cognitive 20) drawee/src/main/java/com/facebook/drawee/drawable/RoundedDrawable.kt:269
- AnimatedDrawable2.draw (cognitive 20) animated-drawable/src/main/java/com/facebook/fresco/animation/drawable/AnimatedDrawable2.kt:162
- RoundedCornersDrawable.draw (cognitive 20) drawee/src/main/java/com/facebook/drawee/drawable/RoundedCornersDrawable.java:272
- Fresco.initialize (cognitive 19) drawee-backends/drawee-pipeline/src/main/java/com/facebook/drawee/backends/pipeline/Fresco.java:61
- LiveEditorOnScreenButtonController.createOnScreenButtons (cognitive 18) vito/tools/liveeditor/src/main/java/com/facebook/fresco/vito/tools/liveeditor/LiveEditorOnScreenButtonController.kt:660
- DebugDataProviderKt.createWastedMemoryProvider (cognitive 18) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/DebugDataProvider.kt:170
- ImageDecodeOptions.equals (cognitive 18) imagepipeline-base/src/main/java/com/facebook/imagepipeline/common/ImageDecodeOptions.java:122
- SimpleDraweeView.init (cognitive 18) drawee/src/main/java/com/facebook/drawee/view/SimpleDraweeView.java:85
- VitoImagePipelineImpl.createImageRequest (cognitive 17) vito/core-java-impl/src/main/java/com/facebook/fresco/vito/core/impl/VitoImagePipelineImpl.kt:53
- ImageFormatCheckerUtils.indexOfPattern (cognitive 17) imagepipeline-base/src/main/java/com/facebook/imageformat/ImageFormatCheckerUtils.kt:68
- BitmapMemoryCacheProducer.produceResults (cognitive 17) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/BitmapMemoryCacheProducer.java:47
- 1.onNewResultImpl (cognitive 17) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/BitmapMemoryCacheProducer.java:136
- VitoDrawableChangedListener.onFinalImageSet (cognitive 17) drawee-span/src/main/java/com/facebook/drawee/span/DraweeSpanStringBuilder.java:297
- ShapeCalculator.getShape (cognitive 16) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/ShapeCalculator.kt:22
- HttpUrlConnectionNetworkFetcher.downloadFrom (cognitive 16) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/HttpUrlConnectionNetworkFetcher.java:161
- AbstractDraweeController.onFailureInternal (cognitive 16) drawee/src/main/java/com/facebook/drawee/controller/AbstractDraweeController.java:655
- DefaultDrawableFactory.createDrawable (cognitive 16) drawee-backends/drawee-pipeline/src/main/java/com/facebook/drawee/backends/pipeline/DefaultDrawableFactory.java:52
- AnimatedImageCompositor.prepareCanvasWithClosestCachedFrame (cognitive 16) animated-base/src/main/java/com/facebook/imagepipeline/animated/impl/AnimatedImageCompositor.java:164
- Redundant overloads for Uri vs ImageSource: The API exposes separate overloads for `Uri` and `ImageSource` that perform the same logical operation (loading an image). Since `ImageSource` is the internal abstraction and `Uri` is a common input, forcing users to choose between `show(uri, ...)` and `show(ImageSource.fromUri(...), ...)` creates confusion. The `Uri` overloads are essentially wrappers around `ImageSource` creation.
- Dual entry points for image loading: `VitoView` exposes both `show(ImageSource)` and `show(VitoImageRequest)`. While `VitoImageRequest` is a higher-level abstraction, exposing both on the same view class creates ambiguity about which should be used for standard use cases. It suggests a split in the API design between 'simple' and 'advanced' loading without clear separation of concerns.
- Implementation class exposes same dual entry point inconsistency: `VitoViewImpl2` (likely an internal implementation detail exposed in the public surface) repeats the `ImageSource` vs `VitoImageRequest` overload pattern found in `VitoView`, compounding the confusion.
- Inconsistent naming and parameter structure for fetching: `ImageLiveEditor` has two `fetch` methods with different signatures. One takes explicit `ImageSource` and `ImageOptions`, the other takes a pre-built `VitoImageRequest`. This mirrors the `VitoView` inconsistency but is even more confusing because `fetch` implies a lower-level operation than `show`, yet it accepts the high-level `VitoImageRequest`.
- Same dual entry point inconsistency in `VitoSpanLoader`: The text span loader also exposes both `ImageSource` and `VitoImageRequest` variants for `show`, creating a parallel inconsistency across different view components (`VitoView`, `VitoSpanLoader`).
- REDACTED
- REDACTED
- Duplicated block (13–21 lines × 3) memory-types/ashmem/src/main/java/com/facebook/imagepipeline/memory/AshmemMemoryChunk.kt:138
- Duplicated block (17 lines × 2) vito/tools/liveeditor/src/main/java/com/facebook/fresco/vito/tools/liveeditor/LiveEditorUiUtils.kt:237
- Duplicated block (14 lines × 3) vito/options/src/main/java/com/facebook/fresco/vito/options/ImageOptions.kt:111
- Duplicated block (7–8 lines × 3) vito/options/src/main/java/com/facebook/fresco/vito/options/ImageOptions.kt:130
- Duplicated block (6 lines × 2) vito/core-common-impl/src/main/java/com/facebook/fresco/vito/core/impl/debug/DebugOverlayDrawable.kt:142
- Duplicated block (4–5 lines × 3) vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/DebugDataProvider.kt:153
- Duplicated block (20 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalThumbnailBitmapSdk29Producer.java:161
- Duplicated block (15–17 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/core/ImagePipelineFactory.java:576
- Duplicated block (13–14 lines × 2) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalThumbnailBitmapSdk29Producer.java:104
- Duplicated block (13 lines × 3) imagepipeline/src/main/java/com/facebook/imagepipeline/producers/BitmapMemoryCacheProducer.java:115
- Duplicated block (10–11 lines × 2) animated-base/src/main/java/com/facebook/imagepipeline/animated/impl/AnimatedDrawableBackendImpl.java:317
- Duplicated block (20–21 lines × 2) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/vito/renderer/RendererColorFilterExampleFragment.kt:43
- Duplicated block (27–29 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/InstrumentedDraweeView.java:57
- Duplicated block (24 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/Instrumentation.java:101
- Duplicated block (18–21 lines × 2) samples/animation2/src/main/java/com/facebook/samples/animation2/bitmap/BitmapAnimationFragment.java:58
- Duplicated block (13–18 lines × 2) samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableDraweeView.java:319
- Duplicated block (9 lines × 3) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/imagepipeline/ImagePipelineDownsampleFragment.java:104
- Duplicated block (7 lines × 3) samples/showcase/src/main/java/com/facebook/fresco/samples/showcase/imageformat/pjpeg/ImageFormatProgressiveJpegFragment.java:203
- Duplicated block (63 lines × 2) samples/comparison/src/main/java/com/facebook/samples/comparison/instrumentation/PerfListener.java:18
- Duplicated block (12 lines × 2) samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableDraweeView.java:394
- Swallowed exception (empty catch) static-webp/src/main/java/com/facebook/webpsupport/WebpBitmapFactoryImpl.kt:368
Minor — 195 finding(s)
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/producers/PartialDiskCacheProducer.java:1
- Orphaned file animated-base/src/main/java/com/facebook/imagepipeline/animated/impl/AnimatedDrawableBackendImpl.java:1
- Orphaned file fbcore/src/main/java/com/facebook/common/logging/FLog.kt:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/producers/ResizeAndRotateProducer.java:1
- Orphaned file drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchyInflater.java:1
- Orphaned file fbcore/src/main/java/com/facebook/datasource/AbstractDataSource.java:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DiskCacheReadProducer.java:1
- Orphaned file animated-base/src/main/java/com/facebook/imagepipeline/animated/impl/AnimatedImageCompositor.java:1
- Orphaned file fbcore/src/main/java/com/facebook/common/statfs/StatFsHelper.java:1
- Orphaned file run_comparison.py:1
- Orphaned file drawee/src/main/java/com/facebook/drawee/drawable/RoundedCornersDrawable.java:1
- Orphaned file animated-gif-lite/src/main/java/com/facebook/animated/giflite/decoder/GifMetadataDecoder.java:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/decoder/ProgressiveJpegParser.java:1
- Orphaned file native-imagetranscoder/src/main/java/com/facebook/imagepipeline/nativecode/NativeJpegTranscoder.java:1
- Orphaned file imagepipeline-base/src/main/java/com/facebook/cache/disk/DiskCacheConfig.java:1
- Orphaned file imagepipeline-base/src/main/java/com/facebook/imagepipeline/transcoder/JpegTranscoderUtils.kt:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalExifThumbnailProducer.java:1
- Orphaned file fbcore/src/main/java/com/facebook/datasource/FirstAvailableDataSourceSupplier.java:1
- Orphaned file animated-base/src/main/java/com/facebook/imagepipeline/animated/factory/AnimatedImageDecoderBase.kt:1
- Orphaned file imagepipeline-base/src/main/java/com/facebook/imageutils/BitmapUtil.kt:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/producers/BitmapProbeProducer.java:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalContentUriThumbnailFetchProducer.java:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/producers/LocalVideoThumbnailProducer.java:1
- Orphaned file imagepipeline/src/main/java/com/facebook/imagepipeline/listener/RequestLoggingListener.kt:1
- Orphaned file imagepipeline-base/src/main/java/com/facebook/cache/disk/DiskStorage.java:1
- README/code drift docs/_docs/animations.md:12
- README/code drift docs/_docs/animations.md:16
- README/code drift docs/_docs/building-from-source.md:8
- README/code drift docs/_docs/caching.md:12
- README/code drift docs/_docs/caching.md:20
- README/code drift docs/_docs/caching.md:36
- README/code drift docs/_docs/caching.md:102
- README/code drift docs/_docs/closeable-references.md:10
- README/code drift docs/_docs/concepts.md:16
- README/code drift docs/_docs/concepts.md:18
- README/code drift docs/_docs/concepts.md:34
- README/code drift docs/_docs/concepts.md:38
- README/code drift docs/_docs/configure-image-pipeline.md:65
- README/code drift docs/_docs/datasources-datasubscribers.md:95
- README/code drift docs/_docs/datasources-datasubscribers.md:149
- README/code drift docs/_docs/drawee-branches.md:20
- README/code drift docs/_docs/drawee-branches.md:28
- README/code drift docs/_docs/drawee-branches.md:81
- README/code drift docs/_docs/faq.md:52
- README/code drift docs/_docs/faq.md:52
- README/code drift docs/_docs/faq.md:56
- README/code drift docs/_docs/faq.md:60
- README/code drift docs/_docs/gotchas.md:22
- README/code drift docs/_docs/image-requests.md:8
- README/code drift docs/_docs/image-requests.md:32
- Duplicated predicate fbcore/src/main/java/com/facebook/datasource/FirstAvailableDataSourceSupplier.java:92
- Duplicated predicate drawee/src/main/java/com/facebook/drawee/generic/RoundingParams.java:302
- Duplicated predicate imagepipeline/src/main/java/com/facebook/imagepipeline/producers/DiskCacheReadProducer.java:205
- Duplicated predicate imagepipeline/src/main/java/com/facebook/imagepipeline/postprocessors/BlurPostProcessor.kt:41
- Duplicated predicate vito/core/src/main/java/com/facebook/fresco/vito/drawable/BitmapDrawableFactory.kt:65
- Duplicated predicate imagepipeline/src/main/java/com/facebook/imagepipeline/datasource/BaseBitmapDataSubscriber.kt:48
- Duplicated predicate vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/KFrescoController.kt:268
- Duplicated predicate vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/ImageFetchSubscriber.kt:135
- Duplicated predicate vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/BitmapPreparingImageFetchSubscriber.kt:93
- Duplicated predicate imagepipeline-base/src/main/java/com/facebook/imageutils/BitmapUtil.kt:76
- Duplicated predicate animated-base/src/main/java/com/facebook/fresco/animation/bitmap/cache/AnimationFrameCacheKey.kt:35
- Duplicated predicate drawee/src/main/java/com/facebook/drawee/drawable/MatrixDrawable.kt:102
- Duplicated predicate vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/DebugDataProvider.kt:157
- Duplicated predicate vito/core-impl/src/main/java/com/facebook/fresco/vito/core/impl/DebugDataProvider.kt:155
- Fat interface: LoggingDelegate (16 abstract methods) fbcore/src/main/java/com/facebook/common/logging/LoggingDelegate.java:14
- Fat interface: ZoomableController (16 abstract methods) samples/zoomable/src/main/java/com/facebook/samples/zoomable/ZoomableController.java:18
- Fat interface: AnimatedDrawableBackend (20 abstract methods) animated-base/src/main/java/com/facebook/imagepipeline/animated/base/AnimatedDrawableBackend.java:22
- Off-boarding risk: anonymized user #1
- Off-boarding risk: anonymized user #2
- Further sole-owners (lower concentration)
- Projects may be oversized for their cohesion
- REDACTED
- Further orphaned files (smaller)
- REDACTED
- REDACTED
- REDACTED
- No ADRs
- No architecture diagram/doc
- Large public API surface
- Logging is not universal
- No SAST
- No release approval gate
- No changelog
Minor — 1 finding(s)
- Off the main sequence: :ui-common
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-44231e2468e94cef80fc1b91f2758921/history.json --exit-code 0 --source . | 3 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-44231e2468e94cef80fc1b91f2758921/tree.json --exit-code 0 --source . | 2 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off . | 14 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 0 | — |
| D31 · IaC & Container Security | trivy | — | trivy: not applicable — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan. | 0 | — |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. semgrep could not parse 34 file(s) — `animated-base/src/main/java/com/facebook/imagepipeline/animated/factory/AnimatedImageDecoderBase.kt`, `animated-drawable/src/main/java/com/facebook/fresco/animation/drawable/AnimatedDrawable2.kt`, `animated-gif-lite/src/main/java/com/facebook/animated/giflite/drawable/GifAnimationBackend.kt`, `drawee/src/main/java/com/facebook/drawee/components/DeferredReleaser.kt`, `drawee/src/main/java/com/facebook/drawee/drawable/ArrayDrawable.kt`, … (+29 more) — so the PII/GDPR sweep did not cover the unparsed regions of them; rows reported elsewhere in those files are real. | 0 | — |
| D37 · Vulnerability-disclosure Policy | disclosure | — | disclosure: not applicable — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |
| D43 · Malicious Dependencies | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 0 | — |