What is the real DPR of Samsung A05s, A12, A13, A3...

“Real” DPR (window.devicePixelRatio as reported by a modern Android browser)

Samsung model	Native resolution (px)	Typical CSS viewport (px)¹	Calculated / reported DPR
Galaxy A05s	1080 × 2400 (~393 ppi) (Devices FAQ)	≈ 412 × 915	≈ 2.63 (xx-hdpi)²
Galaxy A12	720 × 1600 (~264 ppi)	360 × 800	2.0 (reported by DevTools & window.devicePixelRatio) (Web Mobile First)
Galaxy A13	— 4G/LTE: 1080 × 2408 (~400 ppi) (Devices FAQ) <br>— 5G variant: 720 × 1600 (~270 ppi)	≈ 412 × 915 (4G) / 360 × 800 (5G)	≈ 2.63 (4G) / 2.0 (5G)²
Galaxy A31	1080 × 2400 (~411 ppi)	412 × 915	2.625 (reported) (YesViz)
Galaxy A51	1080 × 2400 (~405 ppi)	412 × 915	2.625 (reported) (YesViz)

---

How these numbers are obtained

• Reported values – For the A31 and A51, sites that measure real-world browser data (YesViz) expose the exact devicePixelRatio of 2.625.
• A12 – WebMobileFirst explicitly states that window.devicePixelRatio returns 2 on the Galaxy A12.
• Computed values (A05s & A13 4G) – Android buckets DPR by DPI (DPR ≈ dpi ÷ 160) (Android Developers). Full-HD Samsung phones in the ~400 ppi range fall in the xx-hdpi bucket, and browsers map their 1080-px physical width to a 411/412-px CSS width, yielding 1080 ÷ 412 ≈ 2.63.
• Two DPRs for the A13 – Samsung sells both an FHD+ (4 G/LTE) and an HD+ (5 G) A13. FHD+ follows the 2.63 pattern; the HD+ model matches the A12 at DPR = 2.0.

¹ CSS viewport widths shown are those Chrome reports on stock settings (no “Display size” or “Screen zoom” tweaks).
² Because these are derived from standard Android scaling rules rather than direct measurements, treat them as very accurate approximations; small firmware tweaks or custom display-zoom settings can nudge the figure (e.g. 2.6 vs 2.63).

With these numbers you can write precise media-queries such as:

css
@media (-webkit-device-pixel-ratio:2.625), (min-resolution:384dpi) { … }   /* A05s, A13-4G, A31, A51 */
@media (-webkit-device-pixel-ratio:2)     , (min-resolution:320dpi) { … }   /* A12, A13-5G */

This should give you crisp assets on each handset without over-fetching unnecessarily dense resources.

Short answer: Start from the smallest useful viewport (≈360 px) and enhance upward.
That forces you to break the old “fixed-1200” assumptions up-front, keeps the CSS clean, and makes every later breakpoint additive instead of subtractive.

---

Why “mobile-first then scale up” usually beats “desktop-first scaling down”

Topic	Mobile-first (build for phone portrait first)	Desktop-first (your proposed order)
CSS complexity	Base layer contains only what all screens share; extra rules are added in media queries.	You ship 1200 px styles to every device, then override/remove them in ever-smaller breakpoints—bloat and specificity fights.
Fail-safe	If you miss a rule, content is still readable (a single column).	Miss an override and 360-px users get a broken layout.
Performance	Smaller CSS, fewer images, no unnecessary JS gated by size.	Phones download desktop assets they never use.
Testing cadence	You tackle the hardest constraint first; nothing worse will appear later.	Each new breakpoint can surface deeper structural issues you have to refactor again.
Framework help	Angular CDK BreakpointObserver & Angular Material presets (HandsetPortrait, TabletLandscape, …) are already mobile-first.(Angular University)	You end up fighting the default breakpoints.

Google’s web-dev team also recommends treating mobile as a focusing constraint and progressively enhancing upward.(web.dev)

---

Concrete plan for your device list

<details> <summary>Target CSS viewports</summary>

Device	Portrait w×h	Landscape w×h
Galaxy A05s / A31 / A51 / A13 (4G)	412×915	915×412
Galaxy A12 / A13 (5G)	360×800	800×360
Honor Pad X9a LTE	669×1115	1115×669

</details>

1. Add the baseline mobile viewport meta tag

   html
   <meta name="viewport" content="width=device-width, initial-scale=1">

   Without it, browsers still pretend the page is ~980 px wide.(web.dev)

2. Strip out hard-coded widths

   • Replace min-width:1200px containers with max-width plus fluid units (%, rem, clamp()).
   • Use CSS Grid/Flexbox for flow—no absolute positioning.

3. Define core breakpoints (width, not orientation)

   Alias	Width range	Covers
   xs	0 – 599 px	Phone portrait (360-412)
   sm	600 – 959 px	Phone landscape & small tablet portrait (669)
   md	960 – 1279 px	Tablet landscape (1115) & small desktops
   lg	≥1280 px	Your original desktop design

   In SCSS you can keep them in mixins or consume Angular CDK’s constants:

   ts
   const HANDSET_PORTRAIT = Breakpoints.HandsetPortrait;

4. Build the layout once per breakpoint, smallest → largest

   • Start with a single-column flow (xs).
   • At sm allow 2-column patterns.
   • At md widen gutters, maybe 3 columns.
   • At lg fall back to the existing 1200-px grid.

5. Responsive images & typography

   • img {max-width:100%; height:auto;} plus srcset or the sizes attribute.
   • font-size:clamp(1rem, 0.9vw + .8rem, 1.25rem);

6. Progressively enhance interactions

   • Keep JavaScript free of layout logic where you can; when you must, subscribe to BreakpointObserver instead of window.resize.
   • Hide/stack navigation elements at xs using <mat-sidenav> or a simple “hamburger”.

7. Test & automate

   • Use Chrome DevTools’ device list to emulate the exact 360/412/669/915/1115 widths.
   • Add viewport-specific unit tests or visual regression tests (e.g. Percy).

---

If you must deliver incrementally

You can still deliver landscape-tablet support first without inverting the strategy:

1. Refactor to be fluid below 1280 px but keep a temporary max-width:1115px wrapper so nothing breaks.
2. Release.
3. Remove that wrapper and finish sm + xs layers.

This way the codebase stays mobile-first, while product sees value early.

---

Key take-aways

• Mobile-first == less CSS, fewer surprises, better UX.
• Use width-based breakpoints, not orientation; the devices you listed already span all necessary widths.
• Angular offers built-in helpers (BreakpointObserver, Angular Material layout classes) that align with mobile-first thinking.(Angular University)
• An iterative rollout is fine—just be sure each iteration extends a single responsive code path instead of forking multiple ones.

Below is a concrete way to ship value to product owners early and avoid painting yourself into a “desktop-first” corner.
Think of it as mobile-first architecture with width-gated “on-ramps” that you open one slice at a time.

---

0 Lay the foundation (one sprint)

Goal	Why now?	Typical tasks
Introduce a fluid base layer that already works at any width (but is visually optimised only for ≥ 1200 px for the moment).	Lets you remove the fixed-width assumption without exposing half-finished UIs to users.	* Add the viewport meta tag.<br>* Replace width:1200px wrappers with max-width:var(--page-max,1200px); margin:auto;.<br>* Convert fixed grids to CSS Grid/Flex flow (grid-template-columns:repeat(auto-fill,minmax(300px,1fr))).<br>* Move all presentational units to %, rem, clamp().<br>* Create a single _breakpoints.scss (or Angular CDK constants) and only use min-width queries going forward.

Release toggle
Add a build flag or a simple html[data-lab="responsive"] attribute so QA (and you) can exercise the new CSS before users see it.

---

1 Landscape tablet slice (≈ 1115 px)

1. Set --page-max:1115px in a tablet-landscape override file and verify that all components still look acceptable.
2. Fix what breaks – usually overly wide tables, jumbo typography, or inflexible nav bars.
3. Automated tests – Visual diff tests at 1115 × 669 and 1366 × 768.

Ship it. End-users with a Honor Pad X9a in landscape now get a polished experience; other viewports still fall back to the big-screen UI.

---

2 Portrait tablet & small-desktop slice (960 – 1114 px)

• Remove the 1115-max wrapper and lower the variable: --page-max:960px.
• Introduce a first @media (min-width:960px) layer for multi-column sidebars or cards.
• Fine-tune navigation: hamburger vs. permanent drawer.
• Performance pass: ensure hero images have an intermediate srcset so you’re not sending 360 KB to a 960-px screen.

Ship it. Honor Pad portrait looks great and the previous slice continues to work because the 960-px styles are additive.

---

3 Phone landscape slice (600 – 959 px)

• Shrink typography scale a notch (e.g. clamp(0.9rem,0.8vw+0.8rem,1.1rem)).
• Two-column grid becomes one column; cards stack.
• Replace any hover-only affordances with touch-friendly alternatives (e.g. explicit “⋮” menus).
• Audit tap-targets: ≥ 48 × 48 CSS px.

---

4 Phone portrait slice (≤ 599 px)

• Remove any temporary min-width:600px hacks you might have leaned on.
• Navigation: bottom bar or off-canvas drawer.
• Condense data-dense widgets (tables → stacked lists, charts → sparklines).
• Add performance budgets: < 100 KiB critical CSS/JS, < 2 s 3-G TTI.

---

Why this still counts as mobile-first

• Base layer is zero-assumption and already works on a 360-px phone the moment you rip off the wrapper.
• Each iteration adds style rules (min-width) instead of undoing old ones (max-width)—no specificity wars.
• No dead CSS: when you drop --page-max from 1115 → 960 → none, you’re revealing work you already tested instead of creating new branches.

---

Practical tips to keep momentum

Tactic	How it helps
Feature flag or env-specific build (RELEASE_RESPONSIVE=true)	Lets PO/QA preview every slice without confusing external users.
Storybook with viewport add-on	Component-level snapshots at 360 / 600 / 960 / 1115 / 1440 keep regressions obvious.
Use Angular CDK BreakpointObserver only for behaviour (not layout)	Keeps CSS and TS concerns separate; avoid “DOM patching on resize” antipattern.
Keep one CSS file per slice while developing (_xs.scss, _sm.scss…) then merge**	Easy code-review diffs; later you tree-shake with PostCSS.
Pareto refactor: 20 % of components cause 80 % of the layout pain (nav, data tables, modals). Tackle them first in each slice.
Delete legacy code on the spot	Remove the 1200-px wrapper as soon as the next slice is stable; tech-debt doesn’t pile up.

---

Bottom line

Delivering slice-by-slice is perfectly fine as long as each slice is an additive layer on a mobile-first foundation.
You get fast wins for the tablet stakeholder, continuous user-visible progress, and a clean codebase that won’t explode in specificity overrides six months from now.