1xBet Android hosted APK variants, versions, sizes, SDK declarations and SHA-256 reference
Seven hosted 1xBet Android APK files were recorded on 6 November 2026. They group into three version names and three distinct byte lengths, and every one has a different SHA-256 hash. Equal metadata in some rows cannot tell their bytes apart.
That gap matters when more than one copy sits in your downloads folder. A hash comparison is the only field in this reference that identifies one exact file.
What the 1xBet Android APK inventory contains
The review read hosted Android APK variants without changing anything. It did not test installation, account access, gameplay, payments, or download routing. Seven entries recorded the bytes available at that moment.
Every measured file declared the package org.xbet.client1. Each also declared minSdkVersion 24 and targetSdkVersion 37. Those values came from the manifests inside the files, not from devices that ran them.
| SHA-256 | Version name | Version code | Bytes | Declared ABIs |
|---|---|---|---|---|
16441e294c09d80faabc87310c2ecf9374d0c21bfbee670d2af5dfe667852b83 | 1xbet-prod-v259.1.2 | 25901002 | 46,539,343 | arm64-v8a, armeabi-v7a |
1936c31823c9c48a0c854e79b09c77fdfb26f53672bc5b63f073ba3a0d773fb5 | 1xbet-prod-v257.0.74 | 25700074 | 47,119,379 | arm64-v8a, armeabi-v7a, x86, x86_64 |
4ab8df48440e101a69fb36e248af791140877a6a40979baea33bdb45e918987a | 1xbet-prod-v257.0.74 | 25700074 | 47,119,379 | arm64-v8a, armeabi-v7a, x86, x86_64 |
4c0ed50a57466b9fc957d3cfe7a29cbfed316b3f2f735f75fe49c1dd8079c8a4 | 1xbet-prod-v256.3.0 | 25603000 | 48,335,266 | arm64-v8a, armeabi-v7a, x86, x86_64 |
4c1fc1249bf54173feadd22f49ac90c937d6cc1f904450f62899708b06c85de0 | 1xbet-prod-v259.1.2 | 25901002 | 46,539,343 | arm64-v8a, armeabi-v7a |
923bf6ab46686a130565bfc7550b0e5256a757a3c90cd2fa8fa3ef9e70980c0e | 1xbet-prod-v256.3.0 | 25603000 | 48,335,266 | arm64-v8a, armeabi-v7a, x86, x86_64 |
ba018a25a37957013a0cdfaf4632d2bfbd2c31b86697c25b690f1d96d46344ab | 1xbet-prod-v259.1.2 | 25901002 | 46,539,343 | arm64-v8a, armeabi-v7a |
The smallest measured length was 46,539,343 bytes. The largest was 48,335,266 bytes. That figure is the APK file length, which is not the space the app occupies after installation.
Three version names covered seven distinct files
The reference holds three observed version names, and each one appeared under two or more hashes. A version label therefore selects a group rather than a single file.
| Version name | Version code | Distinct hashes | Observed lengths | ABI group |
|---|---|---|---|---|
| 1xbet-prod-v256.3.0 | 25603000 | 2 | 48,335,266 bytes | ARM plus x86, x86_64 |
| 1xbet-prod-v257.0.74 | 25700074 | 2 | 47,119,379 bytes | ARM plus x86, x86_64 |
| 1xbet-prod-v259.1.2 | 25901002 | 3 | 46,539,343 bytes | ARM only |
The clearest collision involves 1xbet-prod-v257.0.74. Both measured files measure 47,119,379 bytes and declare the same four ABIs. Only the hash separates them.
The three 1xbet-prod-v259.1.2 entries share one length of 46,539,343 bytes and the same two ARM labels. Each still matches a different row.
Why matching names and sizes can mislead you
File length is a coarse filter, not an identifier. Two compressed packages can hold different data while occupying the same number of bytes, and a rename changes nothing inside the file.
- Version name marks the observed release label but does not pick one file.
- File length splits the seven entries into three version groups, yet files inside one group share a length.
- ABI list splits the ARM-only group from the four-label group, and still leaves collisions inside each group.
- SHA-256 produces one long value per set of bytes, so it resolves every collision.
Consider two saved copies that both appear as 1xbet-prod-v259.1.2, both 46,539,343 bytes, both listing two ARM ABIs. Metadata alone cannot say which of the three recorded entries each copy matches.
Verifying a SHA-256 on macOS
The shasum tool with -a 256 produces a SHA-256 digest of a local file. Keep the path simple and free of unusual shell characters.
shasum -a 256 ./1xbet.apk
The output prints a 64-character hexadecimal digest followed by the input filename. Locate that digest in the inventory table and compare it character by character.
For example, a computed value of 4ab8df48440e101a69fb36e248af791140877a6a40979baea33bdb45e918987a matches the measured 1xbet-prod-v257.0.74 row with 47,119,379 bytes. The match confirms identical bytes and nothing more.
Verifying a SHA-256 in PowerShell
Get-FileHash computes a file hash and defaults to SHA256. Naming the algorithm explicitly makes the intent clear in any log.
Get-FileHash -Path .\1xbet.apk -Algorithm SHA256
The result object lists the algorithm, the hash value, and the path. Compare the Hash value against the reference.
- Open a terminal in the folder holding the copy you want to check.
- Run the command with the path to that local file.
- Copy the hexadecimal hash without stray spaces or line breaks.
- Compare it with the matching SHA-256 value in the seven-row table.
- Note the version name, byte length, and ABI labels from that same row.
This procedure touches only a local copy. It leaves Android security settings alone, and it never treats a filename as evidence, since a file named 1xbet.apk may hold bytes from any measured variant.
Reading the 1xBet SDK and ABI declarations
Manifest fields answer narrow technical questions about a build. They say nothing about which phones successfully ran it.
| Declaration | Observed value | What it records |
|---|---|---|
| Package | org.xbet.client1 | The application package identifier declared by all seven files. |
| minSdkVersion | 24 | The minimum Android API level the app declares. |
| targetSdkVersion | 37 | The Android API level the app targets. |
| ABI labels | arm64-v8a, armeabi-v7a, x86, x86_64 | CPU instruction sets and binary interface conventions listed in the files. |
API level 24 corresponds to Android 7.0, as stated in the Android uses-sdk documentation. A minimum declaration expresses a compatibility requirement rather than a tested result.
The targetSdkVersion 37 value names the targeted API level. It does not create a minimum requirement either, and it does not imply that any particular device ran the build.
All seven files list arm64-v8a and armeabi-v7a. Four of them, both v256.3.0 entries and both v257.0.74 entries, also list x86 and x86_64. The three v259.1.2 files list the two ARM labels alone.
arm64-v8amarks 64-bit ARM conventions.armeabi-v7amarks 32-bit ARM conventions.x86marks 32-bit x86 conventions.x86_64marks 64-bit x86 conventions.
Android's ABI guide describes these labels in full. A label list shows what a package carries, not how it behaves on any handset.
Converting APK length into familiar units
Some file managers show decimal megabytes, while others use binary units. The reference keeps exact bytes so both readings stay reproducible.
Decimal megabytes divide the byte count by 1,000,000. Mebibytes divide it by 1,048,576. The smallest file, 46,539,343 bytes, therefore shows one number in a decimal tool and a slightly smaller one in a binary tool.
Neither conversion alters the file. Installers may also extract and reorganise package contents, so installed storage often differs from the length of the downloaded APK.
Using the reference carefully
A hash match carries most weight when you record the hash, version name, and length from one specific row together. Keep those facts linked, because several entries share a version and some share a length.
Treat the list as a dated snapshot of seven hosted variants seen on 6 November 2026. It is not a complete catalogue of every file that could surface later, and a hash absent from the table is simply an unrecorded variant.
The Microsoft Get-FileHash documentation covers the command and its file-content basis. The hash settles byte identity inside this inventory. It does not certify where a file came from, whether it is safe, or whether it installs on a given device.