The DeviceInfo page is divided into multiple sections, which will be explained here.
Device and ROM properties
Product Info gives you a general overview over the device, like its manufacturer, the device name, and CPU architecture.
Sensors lists up which sensors (like Gyroscope, Accelerometer, Proximity
sensor) are available in your device – usually together with the corresponding
manufacturer. If you are not interested in this section, you can rutn it off
MK_DEVICEINFO_SENSORS=0 in your config.
OS details lists some information about the Android system running on your device – line Android version, Kernel and build. And while you might be disappointed finding out your device is not running the latest Android version, almost more important is to check the Security Patch Level. This better shows a date not too far in the past.
This part might be interesting to developers – but will look rather cryptic and
„useless“ to non-developers. If you belong to the latter group and want to get
rid of this section, you can do so setting
A raw hint though: apps can „require features“. If your device doesn't meet
those, such an app would show up as being incompatible with your device, and you
cannot install it. If you are interested in cross-checking, you'll need the APK
file of the app and run
aapt d badging MyApp.apk | grep uses-feature. Results
showing up as
uses-feature-not-required: are optional and will not cause
incompatibility when not met – but
uses-feature: entries are mandatory.
This section can be toggled by the
MK_DEVICEINFO_STATUS config setting.
Battery Status should be pretty much self-explaining – telling you whether the device is currently charged (and if so, by what source), giving details on charging level, voltage, temperature and more. It also lets you know what type of battery your device is using, e.g. Li-ion or Li-Po. Several details are listed here. Picking some core values which might need explanation (I couldn't find details on all, though):
- Max charging current: Highest current for charging (µA)
- Max charging voltage: Highest voltage for charging (µV)
- Charge counter: Battery capacity in microampere-hours (µAh)
(This is an equivalent to battery level if you know your battery's capacity, but has a finer resolution (~1 min in comparison to ~10 min for battery level))
- scale: maximum value for „level“ (usually „100“ with level in percent)
- voltage: current voltage in mV (not µV this time)
- temperature: don't get shocked, it's just centi-degrees (tenths of °C)
Radio Status gives you details on your device's mobile radio. The Baseband Processor is what enables your device to communicate with the mobile network (think of it as a kind of „network card“) – and it has its own software on a separate partition (which in turn you can think of as the corresponding „network driver“). The RIL, or spelled out completely Radio Interface Layer, is what lets the Baseband Processor (or rather its software) communicate with the Android kernel.
Following the general Baseband information are details on each SIM slot available in your device: Signal Strength (linked to an article on Android.SE explaining it), Service State (which network the SIM is connected to, whether the network was selected manually or automatically, details on connectivity. Again, entries should hopefully be understood without much explanation.
If your device is „SIM-less“ (e.g. a WiFi only tablet), you won't be interested
in this section. It can be turned off using the
MK_RADIO=0 option in the config.
Provider Info tells you what network provider the SIM was obtained from – including information on its country. The provider code is a combination of its MCC (first 3 digits) and the providers MNC (Mobile Network Code, last 2 digits).
Networking details hopefully gives you some details on your device's WiFi. Some devices are a bit reluctant to hand them out it seems.
This section gives you some information on your device's storage, including
some disk statistics. If your configuration has
MK_PARTINFO=1, you will also
find details on your device's partitions here:
Depending on manufacturer, device, ROM and possible other modifications, Android
devices offers different ways to identify partitions – with varying relyability
and details. By default, Adebar tries to figure the best available source
automatically; alternatively you can specify the source to use via the
PARTITION_SRC (e.g. in the rare case I didn't yet
encounter where Adebar made a sub-optimal choice). In the order of reliability
and best details provided, possible values for this variable are:
auto: let Adebar detect the best source itself (default)
dumchar: use details from
/proc/dumchar_info. This is only available on MediaTek (MTK) devices.
mtd: use details from
/proc/mtd, augmented by
/proc/mountswhen needed and possible.
emmc: use details from
/proc/emmc, augmented by
/proc/mountswhen needed and possible.
emmc: use details from
byname: use details from
/dev/block/platform/*/by-name, matched against
parts: use details from
/proc/partitionsand cross-check with
The generated DeviceInfo document will tell you which source was used.
Finally, storage details will show you some Disk statistics: how much space does your device offer, how much is used and by what. Basically what you can find on-device in Settings › Storage.
This section tries to sum up some SafetyNet related data. It's by far not complete (as it's not easy for a Shell program like Adebar to test that in depth), but at least gives you some basic indicators on whether SafetyNet might be triggered on your device – e.g. because you unlocked your bootloader.
General implication: with SafetyNet triggered, some applications will refuse to work. Just like that. Some of them you shouldn't use on a smartphone anyway (like banking apps, Google Pay or other financial applications – not at last because of their „tracking features“, but also for general security reasons in case your device gets lost/stolen). Others include DRM related apps like Netflix – or several games. I haven't yet heard about any FOSS app caring about this, though. So think what you want if this really is about safety – and if so, whose.
Want further details? HowtoGeek might help you out with SafetyNet Explained: Why Android Pay and Other Apps Don’t Work on Rooted Devices. For details on what is checked (and not covered by Adebar's simple checks), see e.g. Inside SafetyNet (caution, it's behind Cloudflare).
This will give you a list of accounts on your device. Usually this includes your Google Account (unless you run Google-free – congrats in that case!); but also Threema or big GDPR-violators like WhatsApp/Facebook (are you nuts?) will show up here when configured.
Android Backup Manager
Last in this list: the setup of Android's Backup Services. Even there on devices running pure LineageOS with no GApps installed (though then usually the introduction will be „Backup Manager is disabled“.
The first lines tell you the status of the backup manager: whether backup/auto-restore are enabled. This is followed by available backup destinations (internally called „transports“), which usually are three: LocalTransport („debug-only private cache“), D2dTransport (device-to-device transport), and the GMS BackupTransportService (Backup to Google Drive) – with the latter two requiring a Google Account to be configured on the device, and the last being the default (in the DeviceInfo generated by Adebar, the default is marked bold).
After that you'll be informed of the current status of the backups themselves:
when the last backup was started (a Unix
0 if no backup had been taken yet), and if anything was ever
backed up from the device at all. Further a summary on the backup queues will
be shown: how many requests from participants (key/value backup) are pending,
and how many apps are waiting to be backed up (full backup queue).
That is followed by a list of „Backup Participants“. A participant is an app that itself can request a backup to be initiated.
Additional details on backups, like the current backup queue, can be obtained
adb shell dumpsys backup (or from the
dumpsys_backup file if you
created a dummy device, see Dummy-Devices for details). An explanation of
the output from
dumpsys backup you can e.g. find in my answer at