Android

Japan is an important market for Google. According to data from StatCounter, Google currently ranks second with a market share of 5.81%, far behind the Apple iPhone with a gigantic 62.46%, but just ahead of Samsung and Xiaomi. However, smartphones from the Pixel 7 series have been banned from retail sales there due to a patent dispute with South Korean mobile phone company Pantech.

As MLex reports, a district court in Tokyo has ruled that Google has infringed a standards essential patent relating to the LTE modem in Pixel smartphones. Such patents are required for manufacturing products, which is why they must be licensed under fair, reasonable and non-discriminatory conditions. According to Pantech, Google has been using the exact method described in the patent to handle communication between Pixel smartphones and cell towers, but did not license the patent.

The court stressed that preliminary injunctions for standard essential patents (SEP) are only possible if the defendant has not attempted to obtain a license for the respective patent. Google had delayed negotiations and insisted on conditions such as a confidentiality clause, which Pantech argued was completely unnecessary. Google also refused to propose a "reasonable" royalty rate during the proceedings, claiming that calculating it would be "too complex".

After Google refused to provide the court with data on the sales figures of Pixel smartphones in Japan, the sales ban on the Pixel 7 series was imposed. Pantech has already filed a lawsuit to halt sales of the Pixel 8 and Pixel 9 as well as the corresponding Pro models. If Google is unable to reach an agreement with Pantech, the company may be forced to withdraw from the Japanese market

From their release notes:

    Change MozJPEG title by #1963
    Updated Bilaterial Blur filter
    Fix colors of icon containers by #1941
    Split open source libraries info to separate screens
    Added liquid glass like switch type
    Added ability to save image as static GIF by #1960
    Improve UI and Animations
    Update Turkish by @mikropsoft

https://kevinboone.me/lineageos-degoogled.html

In an earlier article I wrote about my attempts to remove all trace of Google from my life. Part of that process, which is still ongoing, was to install Lineage OS on all my Android cellphones and tablets, replacing the original, vendor firmware. Doing this removes the egregious Google Play Services although, of course, this severely limits my ability to run Android apps. That’s a sacrifice I’m willing to make, although not without some regrets.

I’ve subsequently learned that hard-core de-Googlers eschew Lineage OS, because it remains too close to the stock configuration of the Android Open-Source Project (AOSP) on which it is based. There are certainly smartphone ROMs, like GrapheneOS, that are even more Google-free.

But I’ve grown to like Lineage. I don’t know what kind of future it has, but it works well for me, and it’s easy – as easy as can be expected – to install on all the devices I own. Installing and setting up Lineage is fiddly enough; I don’t want to make my life even more complicated, if I don’t have to.

Those of us who are divorcing Google worry most, I think, about Google’s intrusive data collection. Of course, Google is by no means the only business that engages in such practices – “surveillance capitalism” is big business. But Google presents a unique challenge because, not only does it collect a lot of data, it has a lot of clever ways to process it, and find connections between disparate data elements. Before my Google separation, it always amazed me how Google seemed to know where I was all the time, even with location services disabled on my smartphone. And Google’s advertisers seem to know what I’ve been shopping for, even when I’ve been doing my shopping in person at retail outlets. How Google does this, I don’t know; but I do want to reduce their opportunities to do so.

So I need to know what information my cellphone is sending to Google, even having removed all proprietary Google stuff.

I have to point out that I’m not talking about additional, 3rd-party apps that I might have installed on a Lineage OS device – all apps have the potential to create privacy problems, but I’m free not to use them. Here I’m just thinking about the platform itself.

Note
I run Lineage with no Google apps or services of any kind. If you do run Google services, you have to accept that absolutely everything you do with an Android device will be known to Google. There’s simply no point worrying about the trivial privacy breaches in this article – that would be like taking a cyanide pill and then worrying about your ingrown toenail.

In this article I’ll be describing various data leaks of which Lineage OS has frequently been accused, reporting which ones seem still to be present, and suggesting (well, guessing) how serious they might be.

The captive portal test

“Captive portals” are often found in hotels and entertainment venues. In a captive portal, all Internet traffic gets directed to the venue’s network filter, which ensures that the user has paid for a service or, at least, consented to some usage agreement.

Android performs a captive portal test every time the device enables a network connection. This test is a simple HTTP or HTTPS request on some publicly-accessible webserver. The request is expected to return a success (2XX) code if the server is reachable. In a captive portal, the service-providing organization will capture the HTTP(S) request, and return a redirection code to its own webserver. This server will provide a web page with further instructions.

By default Lineage OS uses Google’s webservers for the captive portal test. This means that Google knows every time a device raises a network connection.

Is this a problem? Google doesn’t get to find out anything except the IP number of the device, some limited information about the type of device, and the time of day. I’ve looked at the source code, and I don’t see any information other than this being sent – the code just uses the standard Java HTTP support to make the request. It’s plausible that, with a wide-area connection, the carrier might add additional information to the request, and Google might be able to infer your location from the IP number.

If you consider this to be too much of a risk, you can change the captive portal connectivity checker. Lineage provides no simple interface for this, but you can do it at the command line (e.g., by running a terminal app, or adb shell). You don’t need to root the phone to do this.

$ settings put global captive_portal_http_url http://my_server 
$ settings put global captive_portal_https_url https://my_server 

Unless you want to disable the captive portal check completely, you’ll need to identify a public webserver that can provide the appropriate response. There are many such servers; some Android replacements that focus more on de-Googling, like GrapheneOS, default to using one of these rather than Google. Even then, they usually have Google’s servers as a fall-back, because an outage of the conectivity check server could otherwise cause serious disruption.

On the whole, I regard this (captive portal check) a relatively harmless breach of privacy. It isn’t telling Google anything they’re not going to find out about in other ways.

DNS

Every time you use a hostname to identify a remote server, there’s going to be a DNS lookup. This lookup translates the hostname into a numeric ID for use with the TCP/IP protocol.

Internet service providers and mobile carriers operate DNS servers, but so does Google. DNS is potentially a privacy problem because the DNS server gets to learn every site you visit. It won’t see the actual URL of a web request – just the hostname. Still, that’s enough information to be concerned about. But it’s worth thinking about who the “you” is in “every site you visit”. To track you, personally, as an individual, the DNS server needs a way to relate your IP number to something that identifies you. There’s no definitive way for Google (or anybody) to do that; but there are statistical methods that can be very effective. They are particularly effective if you happen to use Google’s other services, because these will link a small number of personal Google accounts to an IP number.

Is this a problem for Lineage OS? While it might have been in the past, I don’t think Lineage now uses Google’s DNS, except perhaps as a fallback. Both WiFi and carrier Internet connections are initiated using protocols that can supply a DNS server. On my Lineage devices, I’m sure that these are the DNS servers that are being used. Still, there are references to Google’s DNS server – 8.8.8.8 – in the AOSP source code. So I can’t prove that Google’s DNS will never be used.

If you want, you can supply your own DNS server in the network configuration in the Settings app. But, unless you run your own DNS in the public Internet, you’ll be putting your trust in one mega-corporation or another. I suspect most are less worrying than Google, but perhaps not by much.

By the way – Lineage OS supports encrypted DNS. While that will prevent third-parties from snooping on your DNS traffic – including your mobile carrier or ISP – this won’t protect you from snooping at the DNS server itself. So encrypted DNS is no protection against Google, if you’re using Google’s DNS.

Assisted GPS

It takes a long time for a mobile device to get a robust fix on GPS satellites – a minute in good conditions, or several minutes in a weak signal area. Assisted GPS (A-GPS) primes the satellite fix using environmental data. This data might including a coarse location from a cellular network. With A-GPS, a satellite fix might take only a few seconds.

A-GPS data is processed by a remote server, that has the storage capacity to handle the large amounts of data involved. The main operator of such servers is, again, Google.

What can Google learn about a device using Assisted GPS? As in any Internet operation, it will find the device’s IP number, and it might find the coarse location. The Internet traffic associated with A-GPS can be encrypted but this, again, won’t protect it from Google. To determine the location of a specific individual, Google has to be able to relate the IP number to the individual. As discussed above, that can be done with a reasonable degree of confidence.

On recent Lineage versions, A-GPS is disabled by default. If enabled, it uses Google’s servers – so far as I know there are no widely-available alternatives. I just keep it disabled, and live with the disadvantage of longer GPS start-up times.

Time synchronization, NTP

At one time, Lineage OS used Googles’ time servers to set the time on the device. So far as I know, this is no longer the case – a general pool of NTP servers is used. Even if that were not the case, I can’t worry too much about leaking time synchronizing data.

WebView

I believe that WebView is the most troubling source of privacy concerns for Lineage OS, and the one whose ramifications are the least well-understood.

WebView is a component of Android that renders web pages. Of course, a web browser will do this, but many Android apps and services have a need to render pages without actually being a browser. The ‘captive portal’ support I described above is an example: the device needs to render a page for user to log in or purchase Internet access, even if no web browser is installed.

Lineage OS uses the WebView implementation from the AOSP, which is based on Chromium. Chromium is Google Chrome without the proprietary Google stuff, and it’s undoubtedly less of a privacy concern than Chrome would be. But Chromium, even though it’s open-source, is still primarily a Google product.

There are many known instances where Chromium will provide some user data to Google servers. For example, we know that Chromium downloads lists of ‘unsafe’ websites to support its ‘safe browsing’ feature. This will happen however Chromium is used. When used as a regular web browser, Chromium might send data to Google for its ‘hot word’ detection, for example.

When Chromium is only used to provide a WebView implementation, I’m not convinced that these minor privacy breaches are significant. It’s worth bearing in mind that the Jelly browser that is shipped with Lineage OS is just a wrapper around the Chromium WebView – if you use this browser, you’ll have the same privacy concerns as if you use Chromium itself.

There are a number of Google-free WebView implementations, like Chromite. GrapheneOS uses a WebView implementation called Vanadium, which is essentially a de-Googled Chromium. Installing one of these implementations on Lineage OS is not straightforward, or so it seems to me.

I don’t use Jelly or Chromium itself as a web browser – I install a browser that is not based on Google code, like Firefox. This limits my exposure to Chromium to occasions where WebView is used other than as a browser. In my normal usage, I don’t think there are many of those occasions, so I’m not too worried about WebView.

Nevertheless, it remains a slight concern and, if I could replace it without a lot of effort, I would.

Are we in tinfoil hat territory now?

I don’t like Google knowing so much about me, but I don’t believe Google’s data collection is directly harmful to me. My disapproval of Google’s activities (and I know Google is not the only culprit) is mainly one of principle. I don’t want to be a source of revenue for Google, or to legitimize their behaviour by my own inaction. I don’t want Google to make the Internet more of a hellscape that it currently is.

But I’m not paranoid. I don’t think Google is out to get me, or is in league with people who are. My rejection of Google falls short of doing things that will make my life hugely more difficult.

I am aware, all the same, that I have one foot in tinfoil hat country.

I know a few people – some in my own family – who eschew smartphones because they create time-wasting distractions. I certainly know people who don’t give smartphones to their kids, because of the well-known risks that social media poses to their mental health. But almost nobody avoids Google because they believe, as I do, that the surveillance economy is detrimental to society in the long term. Even those few who do believe this are mostly not willing to take action, because they believe (or convince themselves) that the benefits of a connected world outweigh the costs of a total lack of privacy. For me that’s like understanding the risks of climate change, and yet choosing to run two or three gas-guzzling cars because it’s a half-mile walk to the shops.

The few people who do believe as I do, and are willing to act on their beliefs, tend to be people who also believe that they’re being monitored by the CIA, or that Covid vaccines are implanting mind-control receivers. That’s not a gang that I want to run with.

On the whole, I’m satisfied that Lineage OS, as I use it, is preventing nearly all of Google’s data collection. I don’t install or use any Google services, I don’t enable A-GPS, I don’t use Chromium or the built-in browser. I could eliminate more arcane aspects of data collection – like the Internet connectivity check – if I wanted to take the trouble.

I don’t think that taking reasonable precautions to avoid becoming part of Google’s data collection economy makes me a tinfoil-hatter. Nevertheless, I would probably use GrapheneOS instead, if I had devices that supported it. Ironically, if I wanted to use GrapheneOS, I’d have to buy Google-branded mobile devices, which is an irony that really stings.

For a while I've disliked how high the minimum volume on Android is sometimes. Been searching on ways to fix it and most of the solutions I found required proprietary apps. But then I found this blog post from 2019 which was a pretty good solution to the volume thing. This involves modifying the files that define the volume curve (root is needed).

The relevant part is this:

On a recent-ish version of Android, the two files you want to mess with are:

• /vendor/etc/audio_policy_volumes.xml, which defines what type of audio stream (media, phone calls, earbuds, bluetooth, etc.) uses what type of audio curve.

• /vendor/etc/default_volume_tables.xml, which defines the default audio curves referenced in the previous file.

If you've never modified files on Android, I highly recommend plugging your device to a computer, enabling USB debugging and connecting through adb. You will likely need to remount the filesystem, as it's in read-only mode by default:

$ adb shell  
$ su  
$ mount -o remount,rw /system  

I don't really care about anything else than media volume, so here is the curve I ended up with. It goes very low and gives you more control at low volume, while still being quite loud at maximum volume. You will need to experiment with your device though, as DACs are all different.

<reference name="DEFAULT_MEDIA_VOLUME_CURVE">  
<!-- Default Media reference Volume Curve -->  
    <point>1,-9000</point>  
    <point>10,-8000</point>  
    <point>20,-7000</point>  
    <point>30,-6000</point>  
    <point>40,-4000</point>  
    <point>60,-3000</point>  
    <point>100,-2000</point>  
</reference>  

For reference, the scale goes from -9600 to 0, 0 being the loudest sound your device can produce.

As all things Android, if you are not building your own images, this will get erased next time you update your device. Don't forget to backup the files you modify, as audio curves are easy to screw up!

In my case I only needed to modify /vendor/etc/default_volume_tables.xml.

On my device the curve from the post was a bit too low (first three volume steps were almost unhearable) so after messing around with it I found a more sane one for mine. Gonna leave that here too in case it's useful:

<reference name="DEFAULT_MEDIA_VOLUME_CURVE">  
<!-- Default Media reference Volume Curve -->  
	<point>1,-8000</point>  
	<point>5,-7500</point>  
	<point>10,-7000</point>  
	<point>20,-6000</point>  
	<point>40,-4000</point>  
	<point>60,-3000</point>  
	<point>100,-2000</point>  
</reference>  

(Again, this can be different for each device)

Have a great day :D

cross-posted from: https://lemmy.world/post/31808224

Please see the cross-post as it is updated.

What is the best degoogled tablet for an artist

what is the best tablet for iodeOS, GrapheneOS and LineageOS

• with smooth stylus support that is as good as apple pen
  • palm rejection
  • pressure sensitive stylus
  • works well for krita / excalidraw / xournalapp
  • latency
• at least 16GB RAM and 256GB storage

For iodeOS, it doesn't seem to support any tablet device officially

• iodéOS official supported devices - iodé

For GrapheneOS, the only choice is google pixel tablet (or maybe pixel fold). However

• pixel tablet have latency issue
  • based on Google Pixel Tablet Review - YouTube
• pixel fold does not support stylus
  • workaround This Stylus Pen works with the Google Pixel Fold - YouTube
• Can someone share their GrapheneOS pixel tablet experience on krita / excalidraw / xournalapp?

For LineageOS

• What tablet+stylus+LineageOS has the best performance?
• What tablet+stylus+LineageOS has the best balance between price and performance?
• Can someone share their stylus experience on krita / excalidraw / xournalapp?

Sincere thanks

cross-posted from: https://lemmy.world/post/31808224

Please see the cross-post as it is updated.

Example: https://eprel.ec.europa.eu/screen/product/smartphonestablets20231669/2322840

Pros:

Large, bright, high-RR cover display.

Nearly creaseless internal display, great in all metrics too.

IP48-rated dust and water resistance, nice color options.

Very fast charging as clamshells go.

Class-leading speakers.

Clean and full-featured Hello UI, Moto AI, wide-ranging cover screen functionality.

Overall solid camera system, telephotos are hard to find in this form factor.

Cons:

Unremarkable battery life.

No ultrawide camera.

Essentially no upgrades over the 2024 model.

Heavy thermal throttling.

No way to use the zoom camera via the cover screen.

Original question by @Psyhackological@lemmy.ml

I use basic Google Pixel Camera app that forces me to have Google Photos installed so I can view my photos. My workaround is just going to the gallery directly. I don't use GrapheneOS's camera as I've seen worse quality when comparing two. I heard of modded Google Camera's for specific devices. Any suggestions?

App was installed from Fdroid, but I'm curious why it can browse any folders and see all files. Going into App settings, the Permissions is greyed out. Usually Android will prompt if I want an app to allow access to files (full/limited/none) but not for this app.