Slashdot Mirror

Android Wear 2.0 now supports similar "complications" for adding third-party app customisations to watch faces etc, if that's what you're referring to.

For clarity, I am currently downloading a video onto my MicroSD card from my Android app. So yes, "SD Card" is generalized to "external storage". I have no idea what the consumerist.com write-up means by "The feature doesn’t support any and all Android devices that have a microSD slot, either".

Fixed the quote for you.

I guess what this means is that there are some devices that can't use SD. I don't know what the constraints are... maybe it only works on devices with sufficiently-good hardware DRM (there are various levels, and Netflix does adjust its behavior based on what your hardware has), or maybe it only works if the SD card is configured as adopted storage (which is encrypted for security, making it also unusable for sharing Netflix videos). Or maybe The Verge is just wrong and it does work on all devices. Or something else.

ActiveX "applets" are/were full Windows programs, which could do anything any other application could do.

Which is why for a time they were widely used.

Android Instant Apps don't have access to storage, to other applications, etc.

If that were wholly true they would not be very useful...

Instant apps have some access to the system, with restrictions. In addition to the standard Android permissions apps have to obey, they have some other limitations - a subset:

* Can't access external storage - but they can access private local storage. That to me is a potential hole, especially if the full app can get at that later.

* No access to long term ID's like SSAID, or IMEI - but can access AdvertisingID.

* Foreground services are available while instant app is running.

* Cannot use explicit intents to access other apps.

So while there are many restrictions, there are also areas where security issues may allow an instant app to break from the sandbox. Being pretty new there are bound to be some gaps.

I personally have reservations about something like Instant Apps really being any more useful than applets were. We'll see though.

I don't know about you, but I sure as hell do.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

The documents you are citing appear to date back to Android 3.2 and are obviously out of date in regards to current handset specs.

Well, the second link comes directly from the first, so it's hardly my fault if Google's documentation is out of date. More proof that they don't care about Android any more.

Go on PhoneArena.com or GSMArena.com and do a search of Android handsets and sizes.

Well, what I find is current Android phones with smaller screens than the original iPhone. Anyway, you are confusing released models with actual sales numbers across those models.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

The documents you are citing appear to date back to Android 3.2 and are obviously out of date in regards to current handset specs.

Well, the second link comes directly from the first, so it's hardly my fault if Google's documentation is out of date. More proof that they don't care about Android any more.

Go on PhoneArena.com or GSMArena.com and do a search of Android handsets and sizes.

Well, what I find is current Android phones with smaller screens than the original iPhone. Anyway, you are confusing released models with actual sales numbers across those models.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

The documents you are citing appear to date back to Android 3.2 and are obviously out of date in regards to current handset specs. Average screen densities and diagonal measurements have grown quite a bit the last few years as manufactures try to one-up each other on numbers for marketing purposes.

Go on PhoneArena.com or GSMArena.com and do a search of Android handsets and sizes. As someone who has just recently bought I new phone, I can tell you from first-hand experience that the vast majority of Android phones are 5" or larger. Smaller-screened ones I've found are generally low-cost phones meant for sale as BYO or MVNO devices, and many were older leftovers as they were selling with Android 4.x or 5.0 (and are non-upgradeable). You might want to look at this previous comment I made on this.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

The documents you are citing appear to date back to Android 3.2 and are obviously out of date in regards to current handset specs. Average screen densities and diagonal measurements have grown quite a bit the last few years as manufactures try to one-up each other on numbers for marketing purposes.

Go on PhoneArena.com or GSMArena.com and do a search of Android handsets and sizes. As someone who has just recently bought I new phone, I can tell you from first-hand experience that the vast majority of Android phones are 5" or larger. Smaller-screened ones I've found are generally low-cost phones meant for sale as BYO or MVNO devices, and many were older leftovers as they were selling with Android 4.x or 5.0 (and are non-upgradeable). You might want to look at this previous comment I made on this.

Phablets, or smartphones and tablets ranging in size from 5 inches to 6.9 inches, continued to grow in popularity.

Need to adjust that definition. 90% of Android phones now have screen of 5" or larger. It seems it's only once you hit 5.7" or above people really start throwing around the term "phablet" now.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

He got that idea from that damn message he quoted and is right in front of you now. And he's right - nobody should be calling a 5.2" phone (a very common size, but small by today's standards) a phablet.

Phablets, or smartphones and tablets ranging in size from 5 inches to 6.9 inches, continued to grow in popularity.

Need to adjust that definition. 90% of Android phones now have screen of 5" or larger. It seems it's only once you hit 5.7" or above people really start throwing around the term "phablet" now.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

He got that idea from that damn message he quoted and is right in front of you now. And he's right - nobody should be calling a 5.2" phone (a very common size, but small by today's standards) a phablet.

Phablets, or smartphones and tablets ranging in size from 5 inches to 6.9 inches, continued to grow in popularity.

Need to adjust that definition. 90% of Android phones now have screen of 5" or larger. It seems it's only once you hit 5.7" or above people really start throwing around the term "phablet" now.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

Phablets, or smartphones and tablets ranging in size from 5 inches to 6.9 inches, continued to grow in popularity.

Need to adjust that definition. 90% of Android phones now have screen of 5" or larger. It seems it's only once you hit 5.7" or above people really start throwing around the term "phablet" now.

Where did you get that idea? According to Google's own statistics, 90% of all screens are "small" or "normal" with "normal" ending somewhere below 5" on their vague "definition" chart. https://developer.android.com/about/dashboards/index.html . https://developer.android.com/guide/practices/screens_support.html#range

Android is not open source.

https://source.android.com/sou...
Maybe what you meant was: the software running on my phone isn't open source.

You have to be a major OEM (Samsung, HTC, etc.) and pay big, big money to get Android source code, as well as agree to bundle in (and pay separately for) other shit like Google's Play store and dozens of Google services and apps.

False. We were a company of ~10 people when we started building a product on Android (custom hardware), starting with AOSP. We now have 4 soon to be 5 hardware devices running Android. We're not "Google certified" nor do we license or run Google apps.

The only way to get a free and open and usable Android experience is to do so illegally - use AOSP and inject Google's apps and services

What you really meant was: "The only way to get the GOOGLE experience ...". Sort of like saying "The only way to get HBO with my free basic cable is to do so illegally."

Not only is AOSP bare and useless

Getting AOSP up on your hardware isn't hard*. It is however more than flashing some pre-built binary. It's a development task, not an end user task. You know Linux is open source as well, but does anyone provide a dist of it that runs on your phone? Who are you mad at about that?

* Making it stable and performing is hard.

They're literally the same thing. Apple's "secure enclave" uses the ARM A7's TrustZone/SecurCore tech, which is basically an independent CPU in the same die. There's nothing magical about it - Android's been supporting it for eons now: https://source.android.com/sec...

Sorry, still incorrect. Although Android is (gradually) getting better, slowly, it still is hit and miss, depending on which SoC your device OEM decides to use.

The only thing I was incorrect about is that I was under the impression that the SE was a separate component, rather than being implemented on-die in the Axx SoC. Other than that, my assertion that iOS' Security is more robust than Android's, stands.

Tomorrow may be different; but we're living in today...

They're literally the same thing. Apple's "secure enclave" uses the ARM A7's TrustZone/SecurCore tech, which is basically an independent CPU in the same die. There's nothing magical about it - Android's been supporting it for eons now: https://source.android.com/sec...

Why is it so hard to get a SIMPLE display server and app store done right?

Dunno, but we're talking about operating systems with support for mobile device needs, not simple display servers. If you want a device that can pick up DHCP and start a VNC client, those are also available. It would suck to try to use one as a phone, though.

I bet people will enjoy it when it finally makes its way into the hands of the public in several years' time. Right now, only 0.4% of Android users are on Android 7. For comparison, 1.2% of Android users are still on Android 2.3, released exactly 6 years ago today, and 24% of Android users are still on Android 4.4, released over three years ago.

I actually think this is a real problem and a good hack to show the problem. The Tesla app's cryptographic keys must be stored on the device. That obviously allows an attacker with root access to obtain them. It's a reasonable security measure to add some form of obfuscation to make reverse engineering more difficult. It looks like Android already has the capability to do obfuscation in the SDK with ProGuard.

Actually Android is Linux - it uses the Linux kernel. But yeah, I really don't understand the EU on this. Google already releases the source code for Android If anyone has a problem with Android being "closed" or restrictive, they just need to grab the source and compile their own version. Or install a version someone else has already compiled. If that's too difficult or not to their liking, then the EU should just hire someone to make an EU version. Google has already done 99% of the work, the EU just has to do the last 1% to create their own Google-free version. Just like Amazon has done with Fire OS.

Google places no restrictions on Android - it is free (as in beer) open source. The only restriction they place is on the Google App suite (gmail, maps, calendar, etc). If you want the suite, then the Google Play store must be on the device. Unlike a competitor whose name is a fruit, you can have other stores if you want (I have both Play and the Amazon app store). If you installed Cyanogenmod, then the Google apps suite is the gapps file you downloaded and installed afterwards. It's not a necessary step if you want to use another app store, or just use Android with directly downloaded apps.

Short of decoupling that app suite from the Play store (which would destroy Google's revenue model, since their apps are otherwise free), there's not much else Google can do to make Android any more open and free than it already is. This is kinda like if Microsoft gave Windows away for free and released its source code as open source so anyone could make their own version (which could run all Windows programs). And they also gave away the Office suite for free with the only stipulation being that you had to also install the Microsoft Store if you wanted the Office suite. You can still get your software from other stores if you want, and there are competing office suites you can use instead of Office. Then the EU filed an anti-trust suit against Microsoft because 80% of people opted to use the Office suite.

version today
https://developer.android.com/...

There are three settings:

Off On, GPS only On, also uses wifi and cell networks by querying Google's database

The third one obviously sends some data to Google.

Yeah but look at the API docs. I am pretty sure they moved the location services inside of the Google Play APIs making it impossible to get location services without Play. In fact, I just looked it up and verified that. You literally cannot use location services now without it submitting the data to Google.

Ford added Carplay and Android Auto as at least an option to pretty much all of its 2017 models. That's better than most manufacturers at this point.

See the current lists yourself:
https://www.android.com/auto/
http://www.apple.com/ios/carpl...

The problem with ARM goes way beyond CPU compatibility, which is the point made by Linus

And by me in the last paragraph of the posting to which you responded.

There are the CPU issues, such as "what version of VFP does the processor have, if any?" and "does the processor have Advanced SIMD?". The NDK has an API that can be used to get the answer to those questions (and to similar questions for x86 and MIPS), and there are the "rest of the platform" issues. The former may affect applications, but the latter don't, so the VM isn't needed to handle the latter, nor are fat binaries.

Apple gets away with multi-platform (fat) binaries simply because their ecosystem is way more constrained.

Again, the "rest of the platform" issues aren't relevant here, other than perhaps screen size (iPhone vs. iPad). I'm not sure what processors Apple's used have in the way of floating-point or SIMD support, so I'm not sure what flavors of "fat" are needed other than "ARMv6 vs. ARMv7 vs. ARMv8-A 64-bit".

Google Play Services is just a library. It doesn't access locations itself, but offers an interface for retrieving location information. Apps still have to have location permission themselves to get location information through Google Play Services (See the description of the api here, particularly the "Specify App Permissions" section).

Where "best" means speed (? that one always seemed weirdest for handhelds, but maybe because I've never had a slow one)

"Speed" means not having to wait several seconds for the UI to unfreeze. Lag like this is typical of Nexus 7 (2012) tablets upgraded to Android 5 "Lollipop", especially if you don't clear the cache often. I think what's happening is that Android 5 loses all the RAM efficiency gained in the Project Svelte focus of 4.4 "KitKat", and apps end up terminated more often to reclaim memory. A bunch of applications saving state to the N7's relatively slow-to-write NAND storage in reaction to an onTrimMemory signal causes other applications to be blocked on storage access.

Ah, the browser tab

Until you close your browser. Or until your browser purges the document from RAM.

Android tablets run the Android operating system. Netbooks made since Windows- and X11/Linux-based netbooks were discontinued at the end of 2012 run either Android or Chrome OS. These mobile operating systems, unlike desktop operating systems, don't regularly use a swap file. Instead, when the device is about to run out of RAM, running applications are given a chance to release memory to the OS before being terminated by the OOM killer. Web browsers on mobile operating systems will react to a "trim memory" event by purging a document loaded in another tab with the intent of reloading it later from the network once the user switches back to that tab. This reloading doesn't work if you happen to be offline when you switch back.

Ah, the browser tab

Until you close your browser. Or until your browser purges the document from RAM.

Android tablets run the Android operating system. Netbooks made since Windows- and X11/Linux-based netbooks were discontinued at the end of 2012 run either Android or Chrome OS. These mobile operating systems, unlike desktop operating systems, don't regularly use a swap file. Instead, when the device is about to run out of RAM, running applications are given a chance to release memory to the OS before being terminated by the OOM killer. Web browsers on mobile operating systems will react to a "trim memory" event by purging a document loaded in another tab with the intent of reloading it later from the network once the user switches back to that tab. This reloading doesn't work if you happen to be offline when you switch back.

If Google designed Android so that they could push out forced updates to the OS, carriers and manufacturers who wanted it Their Own Way would simply take the FOSS version of Android and compile it Their Own Way, like Amazon does. That's the trade-off here. You can make it closed source giving you complete control over the OS and updates (what Apple and Microsoft do) and force carriers and manufacturers to bend to your will. Or you can make it FOSS, but attempts to wield control over updates risks carriers and manufacturers jumping ship and forking their own version. You can't have your cake and eat it too.

Google Sheets, Docs, Photos, Plus, etc. are not FOSS. So the carriers and manufacturers (and users) don't have a choice - take it as-is or leave it.

This is the dangerous thing about all these anti-trust lawsuits against Android. Google already makes Android available as FOSS, so anyone can roll their own version of Android without paying Google a dime. If you hate Google but want Android, you can just grab the source and compile your own version. No other company making an OS with significant market share does this. I don't know how much more anti-trust you can get. Google only requires you to install their apps if you want access to the Play store. There are other Android stores out there (Amazon's probably being the biggest, Microsoft for all their complaining about Android is notable in not having one). The EU is playing with fire. If they succeed in their lawsuit, Google may just say "Screw it. We're giving the damn thing away as FOSS and they're still unhappy with it. If they're going to treat us as if we were charging money for it, we'll just make it closed-source and start charging money for it."

From an anti-trust perspective, about the only complaint I have with Android is that Google puts all non-Play stores into a catch-all "unknown sources" category. You can either allow them all, or block them all. They need to change it so you can authorize select stores, while still blocking all others (and side-loading). If there's any monopoly behavior, it's in the store, not the OS. Hell, even Apple could take the Android source code and produce their own version if they wanted.

Android is Open Source and not a company, yeah there is a difference.

https://source.android.com/

To be clear, the issue is a hardware issue in Qualcomm chipsets rather than with Android itself, although the effect is the same. Samsung has some non-Qualcomm chipsets (Exonos) used on some of their phones and those are apparently not affected.

I'm the Google engineer responsible for Keystore.

What you're talking about is a different (and more serious) issue, related to "hardware-backed" keys. The just-published paper is about a weakness in a software-only legacy method that was put in place to provide minimal protection of keys on devices that lacked any reasonable option for device encryption. It's something that I've been meaning to remove completely. It is applied only when apps specifically request it with KeyPairGeneratorSpec.setEncryptionRequired. Based on a scan of the Google Play store, almost no apps request it, and it was formally deprecated in Android Marshmallow. Even if it didn't contain an error in its cryptographic construction, it provides very little security, because you have to root the device to get at the encrypted keys, and once you've done that you have all sorts of options to get at the plaintext.

The primary value in the Android Keystore is in hardware-backed keys: Keys that are generated and used only in the Trusted Execution Environment. Because those keys are (barring issues like the aforementioned Qualcomm TEE bug) never available to the Linux kernel or Android system, no break of the system security can enable extraction of the key material, which keeps the keys bound to the device. Moreover, in a major overhaul of Keystore in Marshmallow, Android Keystore gained the ability to enforce various other access controls to the keys; most of this enforcement is also done in the TEE, reducing the ability of an attacker who roots the device to use Keystore as a key oracle.

There is also some value in Android Keystore on devices without a TEE. Specifically, using Keystore keys rather than keys managed directly by the app moves the key material out of the app's process space, which means that any attack which manages to exploit some security defect in the app and gain access to the app's data can't get a copy of the key material. To do that, the attacker has to get root -- and, assuming "setEncryptionRequired" was used, also break this weak and (in the opinion of the Android security team) unnecessary encryption.

So, yeah. This encryption is broken. But it's unnecessary, deprecated and slated for removal anyway, so it doesn't matter. Which is exactly what I told the researcher when he reported the bug.

The Qualcomm TEE bug, on the other hand, is an issue. It's a fixed issue, but there's this old and very hard-to-fix problem that Android devices don't get security patches the way they should. Nexus devices are patched.

For devices that get regular updates the Qualcomm TrustZone bug has already been fixed. It went out in the January 2016 updates: https://source.android.com/sec.... Check the patchlevel date on your device.

Of course the other part, that someone who can compel Qualcomm to sign TrustZone software images that intentionally compromise security, is still the case, and likely will be for some time. That's a threat model that hadn't been considered important until recently, and it's one that's not easy to mitigate. That's not restricted to Qualcomm, either. In every device with a trusted execution environment, there's some organization who holds the signing keys needed to load firmware in that environment, generally (but not always) the SoC vendor.

Can't this hole be closed by designing the trusted firmware so it requires that the passcode be entered before it will accept a firmware update?

For devices that get regular updates the Qualcomm TrustZone bug has already been fixed. It went out in the January 2016 updates: https://source.android.com/sec.... Check the patchlevel date on your device.

Of course the other part, that someone who can compel Qualcomm to sign TrustZone software images that intentionally compromise security, is still the case, and likely will be for some time. That's a threat model that hadn't been considered important until recently, and it's one that's not easy to mitigate. That's not restricted to Qualcomm, either. In every device with a trusted execution environment, there's some organization who holds the signing keys needed to load firmware in that environment, generally (but not always) the SoC vendor.

https://developer.android.com/...

Aren't the Android VR guys aware there's already a feature on Android called DayDream? It's their way of doing screensavers. It's exposed through the DreamService: https://developer.android.com/...

A is for Apps and n is for niggers. https://www.android.com/versio...

Nothing is tastier than rancid NIGGERCOCK!

That is ok, you are obviously and childishly biased for Apple, so it all balances out. I gave my reasoning behind what I said, you just insulted me, that is the difference between a zealot, and someone who actually looks at things from a neutral standpoint. I have supported (as an IT person) all of Apple's products, and no, the Apple TV is nothing special when put up against a Tivo, or even the old Android TVs, which can still be bought, so no, not discontinued.

https://www.android.com/tv/

The difference is, Android made the jump from a device, to part of the tv. Most of the smart TVs are Android, you don't see Apple TV being built into TVs, do you?

The IDE for Android used to be Eclipse, but Google ended that.

Isn't this it?

The documentation for the hardware-backed keystore is at: https://source.android.com/sec...

The Lollipop changes... that I'm not sure about. I'm sure it's in the release notes somewhere, but I'd have to go Googling for it, and I'm sure you can do that as well as I can.

Probably just by launching; market://details?id=<package_name>. If the phone has "unknown sources" turned on, you could save the apk to the sdcard and launch the file url. Perhaps using a content provider to stream the apk directly from your assets folder.

Yay. 2.3% of Android phones are covered.

https://developer.android.com/...

Well, given that is about 1/3 of all androids in the wild, everyone should be checking.

https://developer.android.com/...

Also, other places say all versions of Android 2.2 & above are affected, which is ~95%

http://www.wired.co.uk/news/ar...

Uhhhhhhhhhhhh...

Android 4.3 introduced support for this kind of hardware secure key storage. There is some detail here: http://nelenkov.blogspot.co.uk... [blogspot.co.uk]

Better link, reflecting the massive improvements in M: https://source.android.com/sec...

Note that until L there was no relationship between disk encryption and the hardware-backed keystore. In L we added a dependency on the keystore, though I think it's still not quite where it should be (even in M). We'll continue improving it, obviously.

Are you saying that Android on Qualcomm SoCs that have secure storage don't use it?

They don't use it for this, exactly. The usey bits of it for master keys used to derive keys that are used for this. I don't believe there's any equivalent of a TPM that in QC SoCs that requires presentation of a certain hash (or sequences of hashes) in a PCM or similar to unlock a key in secure storage.

Because if they do use it then what you say about being able to update the bootloader, boot image, system image etc, is all irrelevant. Go ahead, replace any of them, the SoC isn't going to give up the master key unless you present it with the right hash, and there is nothing you can do to reduce the delay between attempts or the maximum number of attempts per power cycle.

Yeah, that would be awesome wouldn't it? Unfortunately, no. The secure storage you're talking about is just storage. The software that manages it runs on the main CPU, is loaded from flash, etc. Various ARM features are used to keep this all completely walled off from Android and the Linux kernel, and largely even from the trusted OS and applications that use it. But they're still all loaded from flash.

This is why TPM on computers is secure. Obviously you can boot any OS image you like, or flash the BIOS any time you like. It doesn't matter, the TPM has its own processor and isn't giving up that key until you give it the right hash.

Right. To really do this you need a separate secure processor that has its own storage and its own code... ideally code that physically cannot be updated, though that assumes the code is perfect, which is never true so some tradeoffs have to be made. Apple has done this, I believe, though I don't know the details, with their Secure Enclave chip. Samsung has done something with KNOX. Nexus has no equivalent, and neither do most Android devices.

One interesting side note: Since Intel doesn't have any equivalent of the ARM TrustZone, the typical implementation of the hardware-backed keystore on Intel devices is to actually use a TPM chip. That has some nice properties, though TPMs are fixed-function devices and so cannot implement the access controls added to the hardware-backed keystore feature set in M.

As you can see in this diagram, the .apk file only contains .dex files, resources (compiled and uncompiled), and the AndroidManifest.xml file. No .class files (which means no java byte code) to be seen. Not for Dalvik. not for Art.

And you can't just blindly write java source and expect it to work. No AWT or Swing classes, for example.

Anybody can spend all of 3 minutes making a free outlook account and signing up for the Windows 10 Insider program so yes Virginia Win 10 and Edge can be had for absolutely, free...just like Google's OSes and browser.

In fact one could argue there is pretty much zero difference between MSFT and Google now, as both give away their OS and then proceed to datamine the shit out of you while tying everything to their services...hmm...where have I seen that before? Why I just don't know where I could have seen such a thing.

You are telling me that OSX supports an android development environment?

Yes. (Source: SDK download page via Google android studio os x.) However, the stated system requirements include a display at least 1280x800, which in theory rules out the cheap 1366x768 monitor you may have connected to a Mac mini.

I "went Apple" from BSD when Apple went Darwin so I have been in the Apple ecosystem for a while.

Darwin's userland is based on that of FreeBSD. So you went from *BSD to *BSD. (Neither of which, incidentally, is dying.)

By the way, I appreciate both your politeness and candor. Respect.

Thank you. And I appreciate your openness to a mentality other than the "you'll need to switch to the desktop ecosystem that the market has chosen for you; them's the breaks" or "I didn't need to switch ecosystems because I chose a Mac in the first place; sucks to be you" mentality that some other Slashdot users routinely express.

In ART, the apk is already in dex format (done by the build tools). On device, they are recompiled to the oat format. This last step is also what's done again in the optimization step, since as libs change, the dex needs to be "relinked" to the zygote image. See here.

Emulation - Find out how it works and create a way to emulate it.

Newer Android devices contain a secure keystore that can't be emulated quite so easily, as the device key in the Trusted Execution Environment won't chain back to a manufacturer trusted by Google.

The Android Studio download page is signed with a TLS certificate issued to *.google.com with serial number 04:32:D9:AF:F1:79:D0:7E and SHA-256 fingerprint:

2B:19:E1:D6:9E:D1:CC:37:A1:F7:29:7F:6D:77:19:8A:
DB:FD:3D:B5:D4:CD:B1:E9:20:49:18:2E:60:60:34:44

It links to a 1.2 GB file, also behind an HTTPS URI. How is HTTPS insufficient to specify the publisher?