Coder maakt app die HiLight op Pixel 11 Pro programmeerbaar en dus nuttig maakt

Een van de opvallendste nieuwe functies van de Pixel 11 is de HiLight, de gekleurde ring die in het camera-eiland zit en op kan lichten bij verschillende acties. Het probleem is alleen, zoals we in onze review ook al opmerkten, dat HiLight weinig doet. Het was dus wachten op de eerste nuttige functie, en die is er nu. Een programmeur (of beter, een vibe-coder) heeft een appje gebouwd om zelf de HiLight te bedienen.

HiLight appDhananjay Bhosale heeft een tooltje gemaakt dat HiLight Studio heet. De broncode daarvan staat op GitHub onder een MIT-licentie en de app is buiten de Play Store om te downloaden – uiteraard op eigen risico. Dat eigen risico moet je serieus nemen, want Bhosale noemt zichzelf een vibe-coder. Desondanks lijkt zijn app wel de eerste te zijn die de HiLight functioneel gebruikt.

Met Bhosales app is het mogelijk per app in te stellen wat de HiLight moet doen. In screenshots toont hij hoe de app in verschillende kleuren kan knipperen bij notificaties van verschillende diensten. Je kunt ook patronen of andere effecten voor het licht instellen en die live afspelen.

Het was wachten tot iemand de functie voor het eerst zou benutten. Google heeft de Pixel 11 nog maar net aangekondigd. De Pixel 11 Pro-modellen bevatten die HiLight, maar we schreven in onze review al dat de functie extreem beperkt is. Die kan feitelijk maar twee soorten notificaties weergeven en daarmee is het vooral een gemiste kans. Behalve dus als je bereid bent wat moeite te doen voor een mogelijk interessante app.

Door Tijs Hofmans

Nieuwscoördinator

21-08-2026 • 17:50

21

Submitter: CLB

Reacties (21)

Sorteer op:

Weergave:

Vind dit opzich wel een leuke functie, mis de notification LEDs toch wel een beetje
Ik ben het met je eens. Zelf gebruik ik oadNotify op mijn Pixel 8a omdat ik geen notificaties hebben erg onhandig vond. Werkt voor mij super maar ik vind het gebrek aan notificatie LEDs een slechte ontwikkeling
Ik heb de app al draaiende maar al eigen aanpassingen gemaakt. Want als tweaker was het nog beperkt het draait naast een ADB help process anders werkt het niet
Misschien ligt het aan mij, maar ik heb werkelijk nooit mijn telefoon met het scherm naar beneden liggen. Een notificatie led aan de achterzijde klinkt dan ook nutteloos in mijn geval. Als ik even rondkijk op kantoor heeft eigenlijk iedereen zn telefoon met scherm naar boven op het bureau liggen.
Het ligt aan jou, of aan mij.

De mijne ligt altijd ondersteboven. Ik bepaal zelf wanneer ik het ding aandacht geef.

(M.a.w.: ook notificatieleds zouden bij mij weinig aan gaan…)
Dat eigen risico moet je serieus nemen, want Bhosale noemt zichzelf een vibe-coder.
Waarom vergroot dat het risico? Ook voor dat vibecoden een ding was moest je opletten dat appa niet om vreemde permissies vroegen, daar veranderd nu niets aan.
Een programmeur heeft kennis van hoe software werkt. Dus dan is er een kans dat er goed is nagedacht over risico's in de software en permissies.

Maar een vibecoder heeft daar geen kennis van, dus dan weet je zeker dat er niet over is nagedacht.
AI denkt daar tegenwoordig zelf over na.
Ik kan even niet peilen of je nu serieus bent of niet...

Het is al herhaaldelijk aangetoond dat blind vertrouwen op AI om precies dat te doen wat de prompt engineer bedoelt geen goed idee is. Ook veilige code schrijven valt hier onder.

Een filmpje welke ik toevallig vanmiddag nog tegen kwam waar verschillende voorbeelden de revue passeren: YouTube: im shocked more people aren't talking about this
Ik ben serieus, waar ik in het begin AI nog vaak aan zo'n dingen moest herinneren, is dit tegenwoordig ingebakken bij Claude. En wellicht ook wel bij de andere coding AI's. Bij Anthropic zitten ze ook niet stil, ze weten wat er nodig is bij software bouwen en ze voegen daar ook steeds meer functionaliteit aan toe zodat de AI het zelfstandig kan.
Een programmeur heeft kennis van hoe software werkt.
Maar niet hoe in een experimentele zelfgebouwde build de hardware op de lange termijn omgaat met de toegepaste aansturing, of hoe andere applicaties last hebben van jouw eigen gemaakte code.

Zeker op nieuw terrein is het ook voor een die-hard ‘ik tik alles zelf’ ontwikkelaar gewoon trial-and-error om te kijken hoe e.e.a. werkt, en ook als gebruiker neem je dan net zo goed een risico.
Omdat je niet weet wat je doet en de software zo onbedoelde functies kan hebben. Nu zal t hier wel meevallen, maar er kunnen beveiligingsrisico's inzitten, backdoors of zaken die andere software beschadigen.

Stel dat het een netwerkfunctie heeft en random poorten opent of de lokale firewall om zeep helpt.

Wie garandeerd dat een AI het netjes doet...? Daarom dus.

En als iemand er wèl bewust een potje van maakt, dan kan je de persoon erop aanspreken/bannen van een platform. Dat risico neemt men liever niet.
En zonder vibe coder maar met een programmeur? Wie garandeert het dan? Genoeg apps die weinig op hebben met veiligheid. Daarvoor worden mensen niet verbannen van Github.
Je kan een electricien vragen je meterkast opnieuw in te richten, niemand garandeerd dat hij het goed doet maar je kan er enigsinds op vertrouwen. Of je vraagt je buurman die het even voor je doet, die zoekt het wel op met AI, heb je dan nog steeds vertrouwen in je meterkast?

Zelfde geld voor een programmeur, menig programmeur zeker seniors hebben vele jaren ervaring en kennis op gedaan omdat ze het allemaal zelf moeten leren, cursussen doen en experimenteren. Een vibecoder (zoals hier beschreven), heeft code gegenereerd met AI, hij kan het zelf niet lezen hij kan alleen vertellen aan AI wat hij wilt, en waar het nog niet goed werkt. Daar zit een wereld van verschil tussen, dat is niet alleen mijn mening, dat begint inmiddels de mening van menig IT bedrijven te worden omdat ze merken dat AI ook een enorme hoeveelheid niet onderhoudbare code aan het maken is.

Vele grote partijen die met veel geluid aankondigde dat ze AI zwaar gingen inzetten zijn inmiddels al ten dele gekeerd omdat het uiteindelijke resultaat vaak resulteerde in slechte code die niet onderhoudbaar is en nog steeds veel bugs heeft. AI is leuk als extra tool, het kan je op weg helpen, het kan meedenken in oplossings richtingen, maar je moet het nog steeds zelf kunnen. AI vervangt niet, het ondersteund... een vibecoder gebruikt het niet als ondersteuning maar als vervanging (al verving het niets).

[Reactie gewijzigd door ronaldmathies op 21 augustus 2026 23:23]

Een elektricien die er op wordt aangesproken is wat anders dan anonieme git repositories waar ook een flinke amateur achter kan zitten. Ik heb trouwens genoeg meterkast werk van ‘elektriciens’ gezien wat helemaal niet veilig is en ik als amateur beter kan.

Daarnaast kan ook een goede programmeur natuurlijk het vibecoden doen en het AI werk goed nagekeken hebben.
Zijn de API's daarvoor in de SDK? Of is de pixel laag over AOSP ge-reversed engineered om dit te kunnen doen?
edit:
Het lijkt de service manager met de bestaande methodes aan te roepen in de broncode

[Reactie gewijzigd door Koen Hendriks op 21 augustus 2026 17:56]

Is shizuku, dus niet helemaal plug& play
Hij noemt zich dan één, maar op de github word nergens gerept over AI gebruik. Dat vind ik dan wel minder. Zou handig zijn om een afweging te kunnen maken als je het dan toch over veiligheid hebt.
ik vind het juist fijn eigenlijk als ik werk, werk ik dan wil ik niet afgeleid worden door mijn telefoon.

Met het scherm omhoog ben ik snel afgeleid.
Nu omgedraaid heb ik ingesteld dat als ik een appje krijg dit een groen lampje geeft, maar als mijn vrouw een appje stuurt dit paars is. Hierdoor zie ik meteen of ik hem dan moet omdraaien of juist niet.
Hierdoor zie ik meteen of ik hem dan moet omdraaien of juist niet.
Is dat dan bij groen of bij paars? :+
Verdwenen de notificatie leds niet omdat er oled schermen kwamen? Als in een oled scherm hoeft alleen maar een paar pixels aan te zetten om een gekleurd stipje aan te zetten. Als je die ook nog wat rond laat dansen gaat het ook niet inbranden.

Op dit item kan niet meer gereageerd worden.