search

ungoogled-software / ungoogled-chromium

Google Chromium, sans integration with Google
BSD 3-Clause "New" or "Revised" License
19.62k stars 803 forks source link

Add Android support #56

Closed emersion closed 4 years ago

emersion commented 7 years ago

I don't know how much Chromium for desktop and Chromium for Android share code, but it would be cool to have an ungoogled Android version.

Eloston commented 7 years ago

It's possible, but it will take a lot of work if you don't want to use Google binaries.

I think Debian is working on building and packaging the Android development tools. Maybe it'll be easier to build for Android using Debian instead of building everything from source.

seba2282 commented 7 years ago

I have question. If it will be, can you add extensions too supported and converted from chrome and mozilla ? It will be the best product and please delete function with login. The same please for windows and finaly as exe file installer :)

Eloston commented 7 years ago

can you add extensions too

This won't be trivial because I don't think there is any UI infrastructure to support extensions on Android.

please delete function with login

There is no login function feature in ungoogled-chromium as far as I can tell. What exactly do you mean?

The same please for windows and finaly as exe file installer

This should go into a separate issue report. This one is only for adding Android support.

GeitHub commented 7 years ago

Very interested in helping with this in any way that I can. The Replicant (FSF-approved de-blobbed Android distro) devs have released a (somewhat dated) ungoogled version of the Android SDK (NDK too?) that can be used with Eclipse. Perhaps it could be used?

Also, if this is attempted & is successful the earlier request here about adding extensions might not be as difficult as one might imagine. Yandex Alpha browser (closed source) has extensions implemented without any added UI elements in the statusbar, it simply adds access to the chrome://extensions page. This is a separate issue though, but it's worth mentioning because it'd surely bring a lot of eyes to the project (and hopefully more devs!).

Eloston commented 7 years ago

The Replicant (FSF-approved de-blobbed Android distro) devs have released a (somewhat dated) ungoogled version of the Android SDK (NDK too?) that can be used with Eclipse. Perhaps it could be used?

I have no experience building the Android version of Chromium, so I wouldn't know the answer to that.

Yandex Alpha browser (closed source) has extensions implemented without any added UI elements in the statusbar, it simply adds access to the chrome://extensions page

Interesting, but how are you supposed to access the popup menu? I know the Android version of Firefox uses a separate tab to display popups, but I don't know if this feature is implemented in Chromium or how difficult it would be to implement. Anyway, that is a bit off topic.

I think the first objective will be to figure out how to build an Android version without using Google's binaries. Once we get an idea of how the procedure works, we can start adding in patches, domain substitution, and source cleaning.

Any info or help for reaching that first objective is much appreciated. I would like to work on this myself, but I barely have time to respond to comments on here and make small changes to buildlib.

usernamenotexist commented 7 years ago

ANDROID? USE ORFOX AND ORBOT.

magicgoose commented 7 years ago

The Replicant (FSF-approved de-blobbed Android distro) devs have released a (somewhat dated) ungoogled version of the Android SDK (NDK too?)

I think there's no big deal in using official ("googled") Android SDK, as long as one is not using closed-source google libraries — stuff like Google Play Services (ungoogled chromium doesn't need them anyway), etc. The build product still will not be googled in that case.

Eloston commented 7 years ago

@magicgoose We can do this initially, but it should be switched in the long run. "ungoogling" also includes not using Google binaries.

avently commented 7 years ago

any news @Eloston ?

Eloston commented 7 years ago

@avently I am not working on this right now. Someone else has offered to take on the task. See #157.

avently commented 7 years ago

@Eloston Seems like @nopjmp is not working on this. Can you add Android support to your to-do list? Really waiting Ungoogled for Android.

Eloston commented 7 years ago

@avently I am not interested in developing Android support.

zt3phan commented 7 years ago

Is anyone currently working on Android support at all?

magicgoose commented 7 years ago

@zt3phan I think they would say if they did.

zt3phan commented 7 years ago

@magicgoose Point taken,hade to ask thou. Very eager to get an android port.

Eloston commented 7 years ago

@zt3phan What @magicgoose has said is correct.

To be honest, I might be interested in this if Debian's Android SDK and NDK packages are mature enough and Chromium on Android starts to support extensions.

zt3phan commented 7 years ago

Eloston: I just shared tour github-link on fb as i know a few good dev's. Hope you'll get support! Would be great, as it surely get's to work on LineageOS too, as it's a built on CyanogenMod (aosp)...

Eloston commented 7 years ago

@zt3phan Okay, sounds good.

avently commented 6 years ago

I tried to build Chromium for Android with enable_extensions=true with Clang. I got tens of errors during build time. I fixed it and when the process had come to end, bad thing happened. One of the last stage is linking: SOLINK ./libchrome.so. And i got hundreds of errors like: ../../chrome/browser/prefs/browser_prefs.cc:0: error: undefined reference to 'ComponentToolbarActionsFactory::kMediaRouterActionId'

All errors were "undefined reference to ". i don't know C++ or C so i don't know how to fix it. Maybe someone can repeat what Yandex team did. We are waiting you:)

Eloston commented 6 years ago

@avently It's not as easy as switching on a flag. You'll need to at least create the UI in Android (which will probably involve a mixture of Java and C++).

avently commented 6 years ago

@Eloston I think chrome://extensions page should be available. It will be enough to test extensions.

ilikenwf commented 6 years ago

Have you considered presenting this item to the Copperhead OS guys? It aligns with what they're doing perfectly.

Eloston commented 6 years ago

@ilikenwf Nope, I haven't. I don't know anything about Copperhead OS. Are you suggesting that someone there would like to work on adding Android support ungoogled-chromium? Or are they interested in cetain features (e.g. transmissions to Google, but not binary pruning)?

On a related note, this project seems to aligns very well with what F-Droid wants (i.e. minimal binary dependencies in source tree, and no connectivity to non-free services). In fact, Brave browser didn't get into F-Droid because of the binary blobs and JARs. Getting a Chromium browser into F-Droid would be pretty nice, but I believe it'll be a much larger task than adding Windows support.

ilikenwf commented 6 years ago

@Eloston I know for a fact that they are interested in preventing transmissions to Google; removal of binaries and the other patches may also fit within their scope of interest as the goal of their work is to create a hardened Android that is totally free out of the box from Google's tendrils. I think right now that they use a prebuilt of their own for Chromium...but they already maintain SOME patches (any of use to us?) ...maybe open an issue there suggesting collaboration?

https://github.com/CopperheadOS/chromium_patches https://copperhead.co/android/docs/building#chromium-and-webview

I also believe it would be a shoe-in to get included in F-Droid.

Eloston commented 6 years ago

@ilikenwf Based on a quick look, their patches would be useful to include. If they were to include patches from us however, it's possible only a small subset would apply due to the architectural differences between Chromium's Desktop and Android implementations.

Additionally, ungoogled-chromium is pretty aggressive with its GN flags (e.g. disabling Safe Browsing). It doesn't seem like Copperhead OS developers went through the trouble of fixing unsupported GN settings.

ilikenwf commented 6 years ago

@Eloston nice, if nothing else more patches for us here. I may alert them to ungoogled-chromium's existence, at least, as it would be nice at the least to have Android chromium builds that don't talk to the mothership. Don't you currently just do a find and replace at build time?

ilikenwf commented 6 years ago

@Eloston :+1:

Hello ilikenwf,

Thank you for supporting Copperhead, it truly means a lot to us.

You are absolutely right, the less Google in your devices, the better your privacy and security.

Thank you for the good link. I've forwarded it to our developers who will decide whether we can use any of the code in our own projects.

Good looking out!

Thank you,

And then a second one:

Us again.

Thought it might be of interest to you what work we have done ourselves on Chromium

https://github.com/CopperheadOS/chromium_patches https://copperhead.co/android/docs/usage_guide#default-connections-made-by-copperheados

Have a great day, Copperhead

Eloston commented 6 years ago

@ilikenwf

Don't you currently just do a find and replace at build time?

The process's a bit more involved than that. It's explained in DESIGN.md.

csagan5 commented 6 years ago

I build Bromite, which uses some of the patches from ungoogled-chromium, Iridium and others I wrote. The project is specifically targeting android although does not go as far as blocking all connections to Google servers (see https://github.com/bromite/bromite/issues/8).

I assume the procedure of building ungoogled-chromium would be very similar; I offer my help if I can be of support for this issue.

I have tried getting this to build for F-Droid, with little success so far: https://gitlab.com/fdroid/rfp/issues/378 Their VM-based approach is too complicated/bloated in my opinion.

Eloston commented 6 years ago

@csagan5 Yes, we'd welcome help with this issue. We can start out with a straight-forward build without binary pruning or domain substitution, but eventually I'd like to work up to something like the other platforms where all binaries are provided externally (i.e. not from Google).

D0ve commented 6 years ago

Any knews about - 'Debian's Android SDK and NDK packages and Chromium on Android extensions support' ? Could it possible compile the browser builds with Debian Android SDK? And about extensions..., Yandex did this support somehow..., there's a key to compile with-to supoort extensions on android, but popuping a lots paths errors to solve...

Eloston commented 6 years ago

@D0ve There are no updates on my end for building Chromium for Android with Debian packages. I don't know enough right now to determine if this is practical, or even feasible.

Yandex did this support somehow

Are you saying Yandex supports extensions on Android? Do you have a direct link to the changes they made to accomplish this?

D0ve commented 6 years ago

https://habrahabr.ru/company/yandex/blog/309014/ translated https://translate.google.com/translate?hl=&sl=auto&tl=en&u=https%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fyandex%2Fblog%2F309014%2F&sandbox=1 As they wrote, they used enable_extensions flag when compilling, but got a lots of errors.... and did fix it all. Imho need some reverse engineering or look inside to compilled build to see what they did to support extensions on browser for Android.

avently commented 6 years ago

I tried to compile with extensions support. I fixed tens of errors until "linking" stage. It was pretty easy. Just commented and uncommented some lines of code from log Then I got ~thousand errors on the linking stage. Every time I had fixed error and tried to rebuild the rebuilding process had taking 1 hour on my old harware (just linking libchrome.so). So maybe would be a good idea to build separate libs (not just one). Maybe it will be faster, I didn't check it. I don't really understand how chromium code works that's why I couldn't build it with extensions. I think you can do it.

Eloston commented 6 years ago

I am not against adding extension support. However, if I am to work on this, getting the build process closer to the goals would be a higher priority for me than adding extension support (since it aligns more with ungoogled-chromium's objectives and would allow publication on F-Droid). Regardless of my stance, I don't mind if someone else here wants to work on this and submit a PR with the patches and config necessary to make this possible. However, you may want to consider contributing to a project like Bromite (by @csagan5) for the time being, since it's further along in Android support than ungoogled-chromium is.

If you wish to discuss extension support more, let's move this to a separate issue to not diverge from the main topic here.

csagan5 commented 6 years ago

For extensions, see also Brave, the source code is on Github. But I agree it is better discussed in another issue.</offtopic>

To go back on topic: the F-Droid guys were nice, however I am afraid even if we build there with their VM and toolchain, we still have the problem of SDK/NDK (and the other binaries downloaded by gclient), in the sense that even when Chromium builds completely through fdroid tools, this might still be an open problem because you are letting a third-party (Google) binary in the build process (see DDC).

Regarding the binaries downloaded by gclient: they are basically more recent versions of the upstreams, with specific patches/improvements from the Chromium team. One version might work, another might not. The differences should not be too big so in theory one could also track what are the patches and build even those tools (although that's some work...).

Eloston commented 6 years ago

@csagan5

To go back on topic: the F-Droid guys were nice, however I am afraid even if we build there with their VM and toolchain, we still have the problem of SDK/NDK (and the other binaries downloaded by gclient), in the sense that even when Chromium builds completely through fdroid tools, this might still be an open problem because you are letting a third-party (Google) binary in the build process (see DDC).

I was hoping to use Debian packages to solve this issue (since they've been diligent in this area). I'm not sure if that's even possible right now, but we can theoretically bootstrap whatever Debian can't provide.

This is why I proposed working towards the idealistic build process in steps; we start with the regular build process and then replace components a piece at a time. Eventually, we would have a build with no dependency on depot tools or other Google binaries (like all currently supported platforms).

csagan5 commented 6 years ago

Premise: Chromium has lots of dependencies. These are not git submodules, but repositories* checked out in Chromium's src working copy.

Agree with the ideal build process, also because IMO all build processes should be arranged like:

  1. get the source code of main repo and all dependencies at the right version/commit
  2. get all the right tools (binary or compiled in place, although Chromium goes for binaries AFAIK)
  3. perform build (build can be done without any network access, thanks to previous steps)

(1) and (2) are relatively complex, that's why depot_tools is there and its use-case overlaps/conflicts with F-Droid's own srclibs feature for example. It was a bit painful but I had managed to convert DEPS to srclibs for F-Droid. gclient also runs "hooks" (corresponding to (2) in list above) which further prepare the code within the repositories, no idea what these hooks do in detail but I see they're python mostly.

So, in conclusion: if we rip out depot_tools, are we not going to end up writing something similar? Perhaps we should keep that, it is all python anyway.

The problem, as far as I can see, is with the binaries/blobs being downloaded. That is for sure not something that would make it in a Debian repository or F-Droid (if the criteria for inclusion are respected, and they should).

* = not necessarily git repositories, although I see everything is git nowadays?

Eloston commented 6 years ago

@csagan5 Yes, the features of depot_tools are either duplicated or replaced in some manner.

Additionally, depot_tools also uses its own distribution of Python and possibly other binaries, which isn't acceptable by the ideal standards.

Based on my knowledge of Android applications, I imagine that only the JDK and a handful of Android tools and libraries can be provided by Debian right now; some other version-sensitive tools and JARs will have to be built from source. Ideally, we would download the source code and write GN files to implement this.

Also a quick note about extra deps and git repositories: Most git browsers I've seen these days (including Google's git browser) include a feature to download an archive (usually tar or zip) at a specific commit. If we come across some code that has no archive option, we could extend extra_deps to use git.

csagan5 commented 6 years ago

From my POV, I advise against replacing depot_tools, mostly because of the extra work involved with no benefits.

Additionally, depot_tools also uses its own distribution of Python and possibly other binaries

I was not aware of the custom python distro, but I think that is not necessary. Any recent python would do, no custom python features are being used. As for other binaries, I have seen no others used by depot_tools itself (just in the hooks).

But regarding the rest you mentioned: yes it would be extremely useful to start individuating them and the possible FOSS replacements (it is a moving target).

Most git browsers I've seen these days (including Google's git browser) include a feature to download an archive (usually tar or zip) at a specific commit.

I find it more useful to use git because you can download the incremental changes, otherwise this becomes a 20GB-per-time download job. Build nodes (like the Debian/F-Droid ones) do care about this aspect.

Eloston commented 6 years ago

@csagan5 So I did a quick investigation, and I think we only need to download components in DEPS that have a condition of only checkout_android if we use the chromium-browser-official tar archive.

Fortunately, I recall DEPS being implemented as Python code, and a quick skim through it confirms that this is so. So, I wrote a script to print out the dependencies and hooks needed only by Android. The output of the script follows (on the version 65 DEPS file):

***Dependencies:
src/third_party/android_ndk
src/third_party/android_protobuf/src
src/third_party/android_tools (Contains additional deps file: DEPS)
src/third_party/apache-portable-runtime/src
src/third_party/auto/src
src/third_party/custom_tabs_client/src
src/third_party/elfutils/src
src/third_party/errorprone/lib
src/third_party/findbugs
src/third_party/gvr-android-sdk/src
src/third_party/jsr-305/src
src/third_party/junit/src
src/third_party/leakcanary/src
src/third_party/mockito/src
src/third_party/netty-tcnative/src
src/third_party/netty4/src
src/third_party/requests/src
src/third_party/robolectric/robolectric
src/third_party/ub-uiautomator/lib
***Hooks:
Android CIPD Ensure
doclava
gvr_static_shim_android_arm
gvr_static_shim_android_arm64
sdkextras
vr_controller_test_api
vr_test_apks

I think this is a manageable number of hooks and dependencies to workaround, so I don't see a good reason to keep depot_tools in the long run if it's going to make it harder to track what binaries it uses. Additionally, some of these dependencies are only for unit testing and compile time debugging like findbugs, roboelectric, and ub-uiautomator.

I have also confirmed that GN has built-in functionality for Java code, which should make compiling certain JARs from source relatively straight-forward.

Eloston commented 6 years ago

@csagan5 I forgot to mention that the chromium-browser-official archive is is only 544 MB as of 65.0.3325.181. If we're going to use the Debian or F-Droid SDK and NDK, I am having troubles seeing this add up to 20 GB. Is 20 GB the size of a regular gclient checkout (i.e. including .git directories)?

csagan5 commented 6 years ago

@Eloston 20GB (it is more, actually) is the size of everything checked out, including SDK/NDK and everything else downloaded/checked out by gclient. It includes all .git directories, not much git garbage as I ran git gc --prune=all few weeks ago.

In short, everything that exists under src/ in the builder filesystem. See bottom of this post.

Yes, I would love to get rid of as much deps as possible (I only exclude nacl at the moment). Although if massive patches are needed for the build system (ninja/gn), then it'd become again a moving target and painful to support. I am aware of the small size of the chromium-browser-official, but I doubt that on Android we can get away with something similar? I suspect that if you sum up the size of the zips that you would fetch for each dependency, you would still get a big number. This would be completely fine to replace the binaries downloaded by gclient, no binary patching happens for them anyway (AFAIK).

Anyway, feel free to ignore me on this. I'd be glad to get through experimentation a slimmer build and possibly using more FOSS tools rather than the Chromium default ones. After few months building for Android I kinda gave up on this (without really trying, but just from the "feeling" of it).

I report below some partial listings from ncdu. The out directory contains intermediates + final products, which one would ideally want to keep for faster incremental builds (but these do not count in terms of dependencies download estimation, obviously).

   23.2 GiB [##########] /third_party                                                                                                                                                         
   22.6 GiB [######### ] /out
    8.8 GiB [###       ] /.git
  972.2 MiB [          ] /v8
  686.0 MiB [          ] /chrome
  427.8 MiB [          ] /native_client
  393.5 MiB [          ] /build
  392.1 MiB [          ] /.cipd
  156.3 MiB [          ] /tools
  127.8 MiB [          ] /components
  120.3 MiB [          ] /buildtools
   81.8 MiB [          ] /content
   78.4 MiB [          ] /media
   68.2 MiB [          ] /net
   67.5 MiB [          ] /ui
   41.4 MiB [          ] /native_client_sdk
   40.6 MiB [          ] /ios
   18.7 MiB [          ] /extensions
   18.3 MiB [          ] /base
   17.4 MiB [          ] /remoting
   16.6 MiB [          ] /ash
   14.4 MiB [          ] /ppapi
   12.9 MiB [          ] /gpu
   11.5 MiB [          ] /services
   11.1 MiB [          ] /cc
    8.4 MiB [          ] /testing
    8.2 MiB [          ] /chromeos
    8.0 MiB [          ] /device
    7.2 MiB [          ] /mojo
    6.4 MiB [          ] /android_webview
    5.9 MiB [          ] /headless
    5.9 MiB [          ] /docs
    5.1 MiB [          ] /courgette
    4.5 MiB [          ] /chromecast
    3.7 MiB [          ] /sandbox
    3.1 MiB [          ] /storage
    2.2 MiB [          ] /google_apis
    1.1 MiB [          ] /skia
    1.0 MiB [          ] /ipc
  896.0 KiB [          ] /url
  892.0 KiB [          ] /printing
  784.0 KiB [          ] /pdf
[...]

Drilling down into third_party:

    9.9 GiB [##########] /android_tools
    3.7 GiB [###       ] /android_ndk
    1.4 GiB [#         ] /WebKit
  756.1 MiB [          ] /catapult
  736.7 MiB [          ] /skia
  494.3 MiB [          ] /gvr-android-sdk
  474.6 MiB [          ] /icu
  400.6 MiB [          ] /instrumented_libraries
  397.3 MiB [          ] /deqp
  307.2 MiB [          ] /boringssl
  294.6 MiB [          ] /hunspell_dictionaries
  276.2 MiB [          ] /webrtc
  270.8 MiB [          ] /ffmpeg
  241.5 MiB [          ] /angle
  230.2 MiB [          ] /llvm-build
  202.5 MiB [          ] /swiftshader
  190.7 MiB [          ] /liblouis
  165.8 MiB [          ] /libaom
  161.4 MiB [          ] /pdfium
  154.9 MiB [          ] /webgl
  151.8 MiB [          ] /sqlite
  148.8 MiB [          ] /vulkan-validation-layers
  126.3 MiB [          ] /node
  124.9 MiB [          ] /chromite
  122.7 MiB [          ] /libvpx
  112.5 MiB [          ] /android_protobuf
  110.1 MiB [          ] /openh264
  102.4 MiB [          ] /depot_tools
  102.2 MiB [          ] /sfntly
   79.4 MiB [          ] /libphonenumber
[...]

In android_tools:

    4.9 GiB [##########] /.git
    3.8 GiB [#######   ] /ndk
    1.2 GiB [##        ] /sdk
   12.0 KiB [          ]  LICENSE
[...]

And in android_ndk:

    1.6 GiB [##########] /toolchains
    1.0 GiB [######    ] /.git
  579.5 MiB [###       ] /platforms
  454.3 MiB [##        ] /sources
   79.3 MiB [          ] /prebuilt
   35.3 MiB [          ] /simpleperf
   12.8 MiB [          ] /sysroot
    6.4 MiB [          ] /shader-tools
    1.0 MiB [          ] /build
[...]
Eloston commented 6 years ago

@csagan5

Although if massive patches are needed for the build system (ninja/gn), then it'd become again a moving target and painful to support.

I'm hoping that the Android-specific dependencies don't change too often or significantly (especially those in third_party), so this will mostly be a one-time effort.

I suspect that if you sum up the size of the zips that you would fetch for each dependency, you would still get a big number I report below some partial listings from ncdu

It looks like most of the size is due to the Android SDK and NDK, and .git directories. I don't see many of the other deps taking that much space.

If you're really worried about the size, it should be relatively straight-forward to get the total size of these other deps by modifying my script from earlier: If the server supports it, query the HTTP headers for the sizes; otherwise, download them.

But before we worry too much about that, I think we need to see how to use our own Android SDK and NDK; either from Debian's SDK and NDK installer packages, or from F-Droid's own system.

thermatk commented 6 years ago

Hey there! To build with standard SDK/NDK instead of patched prebuilts, seems like you just have to provide paths in gn args, for instance:

default_android_sdk_root = "/opt/android-sdk"
default_android_ndk_root = "/opt/ndk-r16b"

And more vars here: https://chromium.googlesource.com/chromium/src/+/master/build/config/android/config.gni

thermatk commented 6 years ago

Even better, I successfully build with standard SDK and NDK by replacing the bundled with symlinks

nikolowry commented 6 years ago

Any advice on integrating ungoogled-chromium with the CAF Browser (Chromium Browser for Snapdragon), https://www.codeaurora.org/project/chromium-browser-for-snapdragon?

I know they aren't actively maintaining their fork anymore, but I've been doing custom builds with the latest release tag (it's mirrored/imported via a bot). Their instructions for v55 are for the most part still working and valid.

Eloston commented 6 years ago

@nikolowry I don't know a lot about CAF, but I'm betting they made pretty extensive changes that will be nontrivial to update to the latest version of Chromium.

Either way, this isn't really on-topic. If you're looking for results now, you're better off looking into a project like Bromite which has working Android builds and is more experimental than ungoogled-chromium (from my perspective).

csagan5 commented 6 years ago

@nikolowry those patches are effectively scattered around ~500 commits, see my comment here; by doing the changes that way, the CodeAurora devs made it impossible to easily maintain/port the patches.

Also, I am not really sure that ungoogled-chromium would benefit from them; there is a night mode, always-incognito mode, and integration with Web Defender and Secure Connect.

(sorry for the off-topic)

trymeouteh commented 5 years ago

I would love this for testing my website on my Andriod device and not need to use Google's Chrome anymore. And please make this andriod version of Ungoogled Chrome available on the F-Driod store.

Also not only that it would not be worthwile to make a Ungoogled Chromium for iOS since iOS does not allow Chromium, Firefox, or any other browser engine to run on iOS except for the Safari Webkit.