PWA inside a APK: why is it isolated from Android APIs?

910 views Asked by At

When you put a Progressive Web App inside an APK, to sell on Goolge Play, for example by the use of Bubblewrap and Trusted Web Activity, the PWA can not interact with the Android APIs. Correct? If I have misunderstood this, please correct me and point me towards documentation.

So even though it is an APK, and it comes from a trusted source like Google Play, the code it runs (Javascript) will not be allowed to do the same things a normal Android app can do. What is the rationale behind that? Google has a mission to make PWAs just as capable as native apps, so it makes no sense to me.

For example, I need access to the file system from my PWA. I mean real access, not a neutered access like with the upcoming Native File System API. The user accepts file access at installation, and then my app can do whatever it wants. So I thought I'd just use the Android APIs to get access, but they are off limits. How have you solved this issue in your own PWAs?

1

There are 1 answers

7
andreban On

When you put a Progressive Web App inside an APK, to sell on Goolge Play, for example by the use of Bubblewrap and Trusted Web Activity, the PWA can not interact with the Android APIs. Correct? If I have misunderstood this, please correct me and point me towards documentation.

Yes, that's right, event though it's something frequently reconsidered.

So even though it is an APK, and it comes from a trusted source like Google Play, the code it runs (Javascript) will not be allowed to do the same things a normal Android app can do. What is the rationale behind that? Google has a mission to make PWAs just as capable as native apps, so it makes no sense to me.

The goal is to enable a PWA, which is built for the web and uses standardised Web Platform APIs, to be opened as part of a native app (it can be the single Activity in the app or the app can have other Activities).

Overall, you can think the Web APIs as an abstraction layer on top of the native OS /APIs that allows the application to run in many different Operating Systems without any changes - developers shouldn't have to branch their PWAs to different OSs.

Providing access to native APIs would mean developers would mean two things: 1 - Developers would have to build their own abstraction layer to bridge the gap between OSs. 2 - Parts of the application would stop working in a regular browser tab (eg: when not opened in a Trusted Web Activity or equivalent in other OSs).

Therefore, even though we know there are APIs missing to enable every possible use-case, the preference is for enabling those APIs as Web APIs, via Project Fugu , instead of giving direct access to the native APIs.

I have asked the PM exactly this question recently on the web.dev/live event. Here's the relevant section of the video.

For example, I need access to the file system from my PWA. I mean real access, not a neutered access like with the upcoming Native File System API. The user accepts file access at installation, and then my app can do whatever it wants. So I thought I'd just use the Android APIs to get access, but they are off limits. How have you solved this issue in your own PWAs?

I'm not very familiar with the Native File System API. There's a thread on the WICG Discourse where it may be worth sharing the feedback.

Finally, Trusted Web Activity are not supposed to be a replacement for the Android WebView, and serve a slightly different use-case. When the web content is tightly coupled to the Android app (eg: is only supposed to work inside the app and not being loaded inside the regular browser or in other OSs), developing for the WebView will allow hooking up to all native APIs (at the expense of support for many Web APIs, like push notifications and others).