| If your app primarily requires: - native UI elements (labels, text fields, images, listviews, etc) - images in any standard format (png, jpeg, etc) - network requests that doesn't fetch more than a few 100kb of data at a time - simple touch interaction (single item tap/drag/swipe/slide) - read/write to internal storage - play audio ...then you're fine and fragmentation is most likely a non-issue. OTOH, if you require - openGL or 3D graphics calls - read/write to removable storage - video streaming, HLS streaming, or even local video file playback - downloads/network fetches of larger amounts of files/data - multi-touch UX - rear and/or front or any specific camera access - actually any hardware sensor/broadcaster/receiver access (gyro, accel, flashlight, bluetooth) - OS manipulation (custom keyboard, replace default telephony/texting, modify native modals such as share view, register with the OS as a share-target, etc) ...then enjoy lopping off a chunk of your userbase (which you may have to specify manually, although Google helps with this) or struggling to write lots of OS detection switch statements with custom logic for handling each of these things. Working on an app that does 4+ of the things from the latter list, Android fragmentation has been and will continue to be a problem, even if it isn't really at any given point. If we just want apps which move blobs of text back and forth between views and across the network, then yes fragmentation is not an issue. |